X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fmulti_proc_support.rst;h=905967945d1df786fdb879a8a4130af36d6d0aeb;hb=cd8c7c7ce241d2ea7c059a9df07caa9411ef19ed;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..905967945d 100644 --- a/doc/guides/prog_guide/multi_proc_support.rst +++ b/doc/guides/prog_guide/multi_proc_support.rst @@ -1,32 +1,5 @@ -.. BSD LICENSE - Copyright(c) 2010-2014 Intel Corporation. All rights reserved. - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - * Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - * Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - * Neither the name of Intel Corporation nor the names of its - contributors may be used to endorse or promote products derived - from this software without specific prior written permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2010-2014 Intel Corporation. .. _Multi-process_Support: @@ -35,7 +8,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 +25,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,18 +57,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 +79,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 +102,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 +114,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 +126,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 +150,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 +175,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