X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fmulti_proc_support.rst;h=9a9dca7fe489fa1c6e733015540de2fba7971827;hb=c5acbb5ea20e452e4d123a7562d1c46a72b8938a;hp=deaae47de85efc0c1b58a0a98351099fb82c0e5a;hpb=48624fd96e7c4a9603e383baa193909fea392232;p=dpdk.git diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst index deaae47de8..9a9dca7fe4 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). @@ -55,9 +55,9 @@ after a primary process has already configured the hugepage shared memory for th 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,18 +80,17 @@ 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. -.. _pg_figure_16: +.. _figure_multi_process_memory: -**Figure 16. Memory Sharing in the DPDK Multi-process Sample Application** +.. figure:: img/multi_process_memory.* -.. image42_png has been replaced + Memory Sharing in the DPDK Multi-process Sample Application -|multi_process_memory| -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 @@ -103,8 +102,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*. @@ -126,7 +125,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. @@ -138,7 +137,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:: @@ -150,7 +149,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:: @@ -174,7 +173,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. @@ -199,5 +198,3 @@ instead of the functions which do the hashing internally, such as rte_hash_add() which means that only the first, primary DPDK process instance can open and mmap /dev/hpet. If the number of required DPDK processes exceeds that of the number of available HPET comparators, the TSC (which is the default timer in this release) must be used as a time source across all processes instead of the HPET. - -.. |multi_process_memory| image:: img/multi_process_memory.svg