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 6562f0d..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,
 
 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).
 
 To support this functionality,
 a number of additions have been made to the core DPDK Environment Abstraction Layer (EAL).
 


@@ -52,12 +52,16 @@ 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.
 
 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:
 
 To support these two process types, and other multi-process setups described later,
 two additional command-line parameters are available to the EAL:
 

-*   --proc-type: for specifying a given process instance as the primary or secondary DPDK instance
+*   ``--proc-type:`` for specifying a given process instance as the primary or secondary DPDK instance

 
 

-*   --file-prefix: to allow processes that do not want to co-operate to have different memory regions
+*   ``--file-prefix:`` to allow processes that do not want to co-operate to have different memory regions

 
 A number of example applications are provided that demonstrate how multiple DPDK processes can be used together.
 These are more fully documented in the "Multi- process Sample Application" chapter
 
 A number of example applications are provided that demonstrate how multiple DPDK processes can be used together.
 These are more fully documented in the "Multi- process Sample Application" chapter


@@ -80,7 +84,7 @@ and point to the same objects, in both processes.
 
 .. note::
 
 
 .. 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:
     how Linux kernel Address-Space Layout Randomization (ASLR) can affect memory sharing.
 
 .. _figure_multi_process_memory:


@@ -90,7 +94,7 @@ and point to the same objects, in both processes.
    Memory Sharing in the DPDK Multi-process Sample Application
 
 
    Memory Sharing in the DPDK Multi-process Sample Application
 
 

-The EAL also supports an auto-detection mode (set by EAL --proc-type=auto flag ),
+The EAL also supports an auto-detection mode (set by EAL ``--proc-type=auto`` flag ),

 whereby an DPDK process is started as a secondary instance if a primary instance is already running.
 
 Deployment Models
 whereby an DPDK process is started as a secondary instance if a primary instance is already running.
 
 Deployment Models


@@ -102,8 +106,8 @@ Symmetric/Peer Processes
 DPDK multi-process support can be used to create a set of peer processes where each process performs the same workload.
 This model is equivalent to having multiple threads each running the same main-loop function,
 as is done in most of the supplied DPDK sample applications.
 DPDK multi-process support can be used to create a set of peer processes where each process performs the same workload.
 This model is equivalent to having multiple threads each running the same main-loop function,
 as is done in most of the supplied DPDK sample applications.

-In this model, the first of the processes spawned should be spawned using the --proc-type=primary EAL flag,
-while all subsequent instances should be spawned using the --proc-type=secondary flag.
+In this model, the first of the processes spawned should be spawned using the ``--proc-type=primary`` EAL flag,
+while all subsequent instances should be spawned using the ``--proc-type=secondary`` flag.

 
 The simple_mp and symmetric_mp sample applications demonstrate this usage model.
 They are described in the "Multi-process Sample Application" chapter in the *DPDK Sample Application's User Guide*.
 
 The simple_mp and symmetric_mp sample applications demonstrate this usage model.
 They are described in the "Multi-process Sample Application" chapter in the *DPDK Sample Application's User Guide*.


@@ -125,7 +129,7 @@ Running Multiple Independent DPDK Applications
 In addition to the above scenarios involving multiple DPDK processes working together,
 it is possible to run multiple DPDK processes side-by-side,
 where those processes are all working independently.
 In addition to the above scenarios involving multiple DPDK processes working together,
 it is possible to run multiple DPDK processes side-by-side,
 where those processes are all working independently.

-Support for this usage scenario is provided using the --file-prefix parameter to the EAL.
+Support for this usage scenario is provided using the ``--file-prefix`` parameter to the EAL.

 
 By default, the EAL creates hugepage files on each hugetlbfs filesystem using the rtemap_X filename,
 where X is in the range 0 to the maximum number of hugepages -1.
 
 By default, the EAL creates hugepage files on each hugetlbfs filesystem using the rtemap_X filename,
 where X is in the range 0 to the maximum number of hugepages -1.


@@ -137,7 +141,7 @@ The rte part of the filenames of each of the above is configurable using the fil
 In addition to specifying the file-prefix parameter,
 any DPDK applications that are to be run side-by-side must explicitly limit their memory use.
 This is done by passing the -m flag to each process to specify how much hugepage memory, in megabytes,
 In addition to specifying the file-prefix parameter,
 any DPDK applications that are to be run side-by-side must explicitly limit their memory use.
 This is done by passing the -m flag to each process to specify how much hugepage memory, in megabytes,

-each process can use (or passing --socket-mem to specify how much hugepage memory on each socket each process can use).
+each process can use (or passing ``--socket-mem`` to specify how much hugepage memory on each socket each process can use).

 
 .. note::
 
 
 .. note::
 


@@ -149,7 +153,7 @@ Running Multiple Independent Groups of DPDK Applications
 
 In the same way that it is possible to run independent DPDK applications side- by-side on a single system,
 this can be trivially extended to multi-process groups of DPDK applications running side-by-side.
 
 In the same way that it is possible to run independent DPDK applications side- by-side on a single system,
 this can be trivially extended to multi-process groups of DPDK applications running side-by-side.

-In this case, the secondary processes must use the same --file-prefix parameter
+In this case, the secondary processes must use the same ``--file-prefix`` parameter

 as the primary process whose shared memory they are connecting to.
 
 .. note::
 as the primary process whose shared memory they are connecting to.
 
 .. note::


@@ -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.
 
     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.
     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.