-.. 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:
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).
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
.. 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:
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
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*.
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.
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::
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::
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.