doc: fix DDP usage in testpmd

[dpdk.git] / doc / guides / prog_guide / multi_proc_support.rst

diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1680d6b..4ca3f2c 100644 (file)
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -35,7 +35,7 @@ Multi-process Support
 
 In the DPDK, multi-process support is designed to allow a group of DPDK processes
 to work together in a simple transparent manner to perform packet processing,
-or other workloads, on Intel® architecture hardware.
+or other workloads.
 To support this functionality,
 a number of additions have been made to the core DPDK Environment Abstraction Layer (EAL).
 
@@ -52,6 +52,10 @@ Standalone DPDK processes are primary processes,
 while secondary processes can only run alongside a primary process or
 after a primary process has already configured the hugepage shared memory for them.
 
+.. note::
+
+    Secondary processes should run alongside primary process with same DPDK version.
+
 To support these two process types, and other multi-process setups described later,
 two additional command-line parameters are available to the EAL:
 
@@ -80,7 +84,7 @@ and point to the same objects, in both processes.
 
 .. note::
 
-    Refer to Section 23.3 "Multi-process Limitations" for details of
+    Refer to `Multi-process Limitations`_ for details of
     how Linux kernel Address-Space Layout Randomization (ASLR) can affect memory sharing.
 
 .. _figure_multi_process_memory:
@@ -173,7 +177,7 @@ Some of these are documented below:
     so it is recommended that it be disabled only when absolutely necessary,
     and only when the implications of this change have been understood.
 
-*   All DPDK processes running as a single application and using shared memory must have distinct coremask arguments.
+*   All DPDK processes running as a single application and using shared memory must have distinct coremask/corelist arguments.
     It is not possible to have a primary and secondary instance, or two secondary instances,
     using any of the same logical cores.
     Attempting to do so can cause corruption of memory pool caches, among other issues.