X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fguides%2Fprog_guide%2Fmulti_proc_support.rst;h=4ca3f2c229bc6e2509543d2f2cc177eb81fada22;hb=e0e45bdc1e813dd4570434786b6aa660be69649f;hp=6562f0d78498a21707e103e017eec2e4282a5bd0;hpb=4a22e6ee3d2f8be8afd5b374a8916e232ab7fe97;p=dpdk.git diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst index 6562f0d784..4ca3f2c229 100644 --- 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,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. +.. 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: -* --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 @@ -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: @@ -90,7 +94,7 @@ and point to the same objects, in both processes. 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 @@ -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. -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*. @@ -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. -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. @@ -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, -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:: @@ -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 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:: @@ -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.