eal: replace blacklist/whitelist options

Replace -w / --pci-whitelist with -a / --allow options
and --pci-blacklist with --block.
The -b short option remains unchanged.

Allow the old options for now, but print a nag
warning since old options are deprecated.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
This commit is contained in:
Stephen Hemminger 2020-11-10 14:55:40 -08:00 committed by Thomas Monjalon
parent a65a34a85e
commit db27370b57
57 changed files with 264 additions and 246 deletions

View File

@ -61,7 +61,7 @@ do_recursive_call(void)
{ "test_main_lcore_flag", no_action },
{ "test_invalid_n_flag", no_action },
{ "test_no_hpet_flag", no_action },
{ "test_whitelist_flag", no_action },
{ "test_allow_flag", no_action },
{ "test_invalid_b_flag", no_action },
{ "test_invalid_vdev_flag", no_action },
{ "test_invalid_r_flag", no_action },

View File

@ -30,7 +30,7 @@
#define no_hpet "--no-hpet"
#define no_huge "--no-huge"
#define no_shconf "--no-shconf"
#define pci_whitelist "--pci-whitelist"
#define allow "--allow"
#define vdev "--vdev"
#define memtest "memtest"
#define memtest1 "memtest1"
@ -223,12 +223,12 @@ get_number_of_sockets(void)
#endif
/*
* Test that the app doesn't run with invalid whitelist option.
* Test that the app doesn't run with invalid allow option.
* Final tests ensures it does run with valid options as sanity check (one
* test for with Domain+BDF, second for just with BDF)
*/
static int
test_whitelist_flag(void)
test_allow_flag(void)
{
unsigned i;
#ifdef RTE_EXEC_ENV_FREEBSD
@ -245,45 +245,45 @@ test_whitelist_flag(void)
const char *wlinval[][7] = {
{prgname, prefix, mp_flag,
pci_whitelist, "error", "", ""},
allow, "error", "", ""},
{prgname, prefix, mp_flag,
pci_whitelist, "0:0:0", "", ""},
allow, "0:0:0", "", ""},
{prgname, prefix, mp_flag,
pci_whitelist, "0:error:0.1", "", ""},
allow, "0:error:0.1", "", ""},
{prgname, prefix, mp_flag,
pci_whitelist, "0:0:0.1error", "", ""},
allow, "0:0:0.1error", "", ""},
{prgname, prefix, mp_flag,
pci_whitelist, "error0:0:0.1", "", ""},
allow, "error0:0:0.1", "", ""},
{prgname, prefix, mp_flag,
pci_whitelist, "0:0:0.1.2", "", ""},
allow, "0:0:0.1.2", "", ""},
};
/* Test with valid whitelist option */
/* Test with valid allow option */
const char *wlval1[] = {prgname, prefix, mp_flag,
pci_whitelist, "00FF:09:0B.3"};
allow, "00FF:09:0B.3"};
const char *wlval2[] = {prgname, prefix, mp_flag,
pci_whitelist, "09:0B.3", pci_whitelist, "0a:0b.1"};
allow, "09:0B.3", allow, "0a:0b.1"};
const char *wlval3[] = {prgname, prefix, mp_flag,
pci_whitelist, "09:0B.3,type=test",
pci_whitelist, "08:00.1,type=normal",
allow, "09:0B.3,type=test",
allow, "08:00.1,type=normal",
};
for (i = 0; i < RTE_DIM(wlinval); i++) {
if (launch_proc(wlinval[i]) == 0) {
printf("Error - process did run ok with invalid "
"whitelist parameter\n");
"allow parameter\n");
return -1;
}
}
if (launch_proc(wlval1) != 0 ) {
printf("Error - process did not run ok with valid whitelist\n");
printf("Error - process did not run ok with valid allow\n");
return -1;
}
if (launch_proc(wlval2) != 0 ) {
printf("Error - process did not run ok with valid whitelist value set\n");
printf("Error - process did not run ok with valid allow value set\n");
return -1;
}
if (launch_proc(wlval3) != 0 ) {
printf("Error - process did not run ok with valid whitelist + args\n");
printf("Error - process did not run ok with valid allow + args\n");
return -1;
}
@ -291,7 +291,7 @@ test_whitelist_flag(void)
}
/*
* Test that the app doesn't run with invalid blacklist option.
* Test that the app doesn't run with invalid blocklist option.
* Final test ensures it does run with valid options as sanity check
*/
static int
@ -317,7 +317,7 @@ test_invalid_b_flag(void)
{prgname, prefix, mp_flag, "-b", "error0:0:0.1"},
{prgname, prefix, mp_flag, "-b", "0:0:0.1.2"},
};
/* Test with valid blacklist option */
/* Test with valid blocklist option */
const char *blval[] = {prgname, prefix, mp_flag,
"-b", "FF:09:0B.3"};
@ -326,12 +326,12 @@ test_invalid_b_flag(void)
for (i = 0; i != RTE_DIM(blinval); i++) {
if (launch_proc(blinval[i]) == 0) {
printf("Error - process did run ok with invalid "
"blacklist parameter\n");
"blocklist parameter\n");
return -1;
}
}
if (launch_proc(blval) != 0) {
printf("Error - process did not run ok with valid blacklist value\n");
printf("Error - process did not run ok with valid blocklist value\n");
return -1;
}
return 0;
@ -419,7 +419,7 @@ test_invalid_r_flag(void)
{prgname, prefix, mp_flag, "-r", "-1"},
{prgname, prefix, mp_flag, "-r", "17"},
};
/* Test with valid blacklist option */
/* Test with valid blocklist option */
const char *rval[] = {prgname, prefix, mp_flag, "-r", "16"};
int i;
@ -1492,9 +1492,9 @@ test_eal_flags(void)
return ret;
}
ret = test_whitelist_flag();
ret = test_allow_flag();
if (ret < 0) {
printf("Error in test_invalid_whitelist_flag()\n");
printf("Error in test_allow_flag()\n");
return ret;
}
@ -1546,7 +1546,8 @@ REGISTER_TEST_COMMAND(eal_flags_main_opt_autotest, test_main_lcore_flag);
REGISTER_TEST_COMMAND(eal_flags_n_opt_autotest, test_invalid_n_flag);
REGISTER_TEST_COMMAND(eal_flags_hpet_autotest, test_no_hpet_flag);
REGISTER_TEST_COMMAND(eal_flags_no_huge_autotest, test_no_huge_flag);
REGISTER_TEST_COMMAND(eal_flags_w_opt_autotest, test_whitelist_flag);
REGISTER_TEST_COMMAND(eal_flags_w_opt_autotest, test_allow_flag); /* for legacy CI */
REGISTER_TEST_COMMAND(eal_flags_a_opt_autotest, test_allow_flag);
REGISTER_TEST_COMMAND(eal_flags_b_opt_autotest, test_invalid_b_flag);
REGISTER_TEST_COMMAND(eal_flags_vdev_opt_autotest, test_invalid_vdev_flag);
REGISTER_TEST_COMMAND(eal_flags_r_opt_autotest, test_invalid_r_flag);

View File

@ -28,5 +28,5 @@ fi
(sleep 1 && echo stop) |
$testpmd -c $coremask --no-huge -m 20 \
$libs -w 0:0.0 --vdev net_null1 --vdev net_null2 $eal_options -- \
$libs -a 0:0.0 --vdev net_null1 --vdev net_null2 $eal_options -- \
--no-mlockall --total-num-mbufs=2048 $testpmd_options -ia

View File

@ -241,4 +241,4 @@ Specifically for the BBDEV ACC100 PMD, the command below can be used:
.. code-block:: console
./pf_bb_config ACC100 -c acc100/acc100_config_vf_5g.cfg
./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64 -b 32 -l 1 -v ./ldpc_dec_default.data
./test-bbdev.py -e="-c 0xff0 -a${VF_PCI_ADDR}" -c validation -n 64 -b 32 -l 1 -v ./ldpc_dec_default.data

View File

@ -304,4 +304,4 @@ Specifically for the BBDEV FPGA 5GNR FEC PMD, the command below can be used:
.. code-block:: console
./pf_bb_config FPGA_5GNR -c fpga_5gnr/fpga_5gnr_config_vf.cfg
./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64 -b 32 -l 1 -v ./ldpc_dec_default.data
./test-bbdev.py -e="-c 0xff0 -a${VF_PCI_ADDR}" -c validation -n 64 -b 32 -l 1 -v ./ldpc_dec_default.data

View File

@ -323,4 +323,4 @@ Specifically for the BBDEV FPGA LTE FEC PMD, the command below can be used:
.. code-block:: console
./pf_bb_config FPGA_LTE -c fpga_lte/fpga_lte_config_vf.cfg
./test-bbdev.py -e="-c 0xff0 -w${VF_PCI_ADDR}" -c validation -n 64 -b 32 -l 1 -v ./turbo_dec_default.data
./test-bbdev.py -e="-c 0xff0 -a${VF_PCI_ADDR}" -c validation -n 64 -b 32 -l 1 -v ./turbo_dec_default.data

View File

@ -134,10 +134,10 @@ Supported DPAA2 SoCs
* LS2088A/LS2048A
* LS1088A/LS1048A
Whitelisting & Blacklisting
---------------------------
Allowing & Blocking
-------------------
For blacklisting a DPAA2 SEC device, following commands can be used.
The DPAA2 SEC device can be blocked with the following:
.. code-block:: console

View File

@ -82,10 +82,10 @@ Supported DPAA SoCs
* LS1046A/LS1026A
* LS1043A/LS1023A
Whitelisting & Blacklisting
---------------------------
Allowing & Blocking
-------------------
For blacklisting a DPAA device, following commands can be used.
For blocking a DPAA device, following commands can be used.
.. code-block:: console

View File

@ -127,7 +127,7 @@ Limitations
optimisations in the GEN3 device. And if a GCM session is initialised on a
GEN3 device, then attached to an op sent to a GEN1/GEN2 device, it will not be
enqueued to the device and will be marked as failed. The simplest way to
mitigate this is to use the bdf whitelist to avoid mixing devices of different
mitigate this is to use the PCI allowlist to avoid mixing devices of different
generations in the same process if planning to use for GCM.
* The mixed algo feature on GEN2 is not supported by all kernel drivers. Check
the notes under the Available Kernel Drivers table below for specific details.
@ -237,7 +237,7 @@ adjusted to the number of VFs which the QAT common code will need to handle.
QAT VF may expose two crypto devices, sym and asym, it may happen that the
number of devices will be bigger than MAX_DEVS and the process will show an error
during PMD initialisation. To avoid this problem RTE_CRYPTO_MAX_DEVS may be
increased or -w, pci-whitelist domain:bus:devid:func option may be used.
increased or -a, allow domain:bus:devid:func option may be used.
QAT compression PMD needs intermediate buffers to support Deflate compression
@ -275,7 +275,7 @@ return 0 (thereby avoiding an MMIO) if the device is congested and number of pac
possible to enqueue is smaller.
To use this feature the user must set the parameter on process start as a device additional parameter::
-w 03:01.1,qat_sym_enq_threshold=32,qat_comp_enq_threshold=16
-a 03:01.1,qat_sym_enq_threshold=32,qat_comp_enq_threshold=16
All parameters can be used with the same device regardless of order. Parameters are separated
by comma. When the same parameter is used more than once first occurrence of the parameter
@ -638,19 +638,19 @@ Testing
QAT SYM crypto PMD can be tested by running the test application::
cd ./<build_dir>/app/test
./dpdk-test -l1 -n1 -w <your qat bdf>
./dpdk-test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_autotest
QAT ASYM crypto PMD can be tested by running the test application::
cd ./<build_dir>/app/test
./dpdk-test -l1 -n1 -w <your qat bdf>
./dpdk-test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_asym_autotest
QAT compression PMD can be tested by running the test application::
cd ./<build_dir>/app/test
./dpdk-test -l1 -n1 -w <your qat bdf>
./dpdk-test -l1 -n1 -a <your qat bdf>
RTE>>compressdev_autotest

View File

@ -55,7 +55,7 @@ Runtime Config Options
upper limit for in-flight events.
For example::
-w 0002:0e:00.0,xae_cnt=16384
-a 0002:0e:00.0,xae_cnt=16384
- ``Force legacy mode``
@ -63,7 +63,7 @@ Runtime Config Options
single workslot mode in SSO and disable the default dual workslot mode.
For example::
-w 0002:0e:00.0,single_ws=1
-a 0002:0e:00.0,single_ws=1
- ``Event Group QoS support``
@ -78,7 +78,7 @@ Runtime Config Options
default.
For example::
-w 0002:0e:00.0,qos=[1-50-50-50]
-a 0002:0e:00.0,qos=[1-50-50-50]
- ``Selftest``
@ -87,7 +87,7 @@ Runtime Config Options
The tests are run once the vdev creation is successfully complete.
For example::
-w 0002:0e:00.0,selftest=1
-a 0002:0e:00.0,selftest=1
- ``TIM disable NPA``
@ -96,7 +96,7 @@ Runtime Config Options
parameter disables NPA and uses software mempool to manage chunks
For example::
-w 0002:0e:00.0,tim_disable_npa=1
-a 0002:0e:00.0,tim_disable_npa=1
- ``TIM modify chunk slots``
@ -107,7 +107,7 @@ Runtime Config Options
to SSO. The default value is 255 and the max value is 4095.
For example::
-w 0002:0e:00.0,tim_chnk_slots=1023
-a 0002:0e:00.0,tim_chnk_slots=1023
- ``TIM enable arm/cancel statistics``
@ -115,7 +115,7 @@ Runtime Config Options
event timer adapter.
For example::
-w 0002:0e:00.0,tim_stats_ena=1
-a 0002:0e:00.0,tim_stats_ena=1
- ``TIM limit max rings reserved``
@ -125,7 +125,7 @@ Runtime Config Options
rings.
For example::
-w 0002:0e:00.0,tim_rings_lmt=5
-a 0002:0e:00.0,tim_rings_lmt=5
- ``TIM ring control internal parameters``
@ -135,7 +135,7 @@ Runtime Config Options
default values.
For Example::
-w 0002:0e:00.0,tim_ring_ctl=[2-1023-1-0]
-a 0002:0e:00.0,tim_ring_ctl=[2-1023-1-0]
- ``Lock NPA contexts in NDC``
@ -145,7 +145,7 @@ Runtime Config Options
For example::
-w 0002:0e:00.0,npa_lock_mask=0xf
-a 0002:0e:00.0,npa_lock_mask=0xf
Debugging Options
-----------------

View File

@ -67,7 +67,7 @@ DPDK application. Some of the EAL options for FreeBSD are as follows:
is a list of cores to use instead of a core mask.
* ``-b <domain:bus:devid.func>``:
Blacklisting of ports; prevent EAL from using specified PCI device
Blocklisting of ports; prevent EAL from using specified PCI device
(multiple ``-b`` options are allowed).
* ``--use-device``:

View File

@ -53,7 +53,7 @@ The EAL options are as follows:
Number of memory channels per processor socket.
* ``-b <domain:bus:devid.func>``:
Blacklisting of ports; prevent EAL from using specified PCI device
Blocklisting of ports; prevent EAL from using specified PCI device
(multiple ``-b`` options are allowed).
* ``--use-device``:

View File

@ -44,20 +44,20 @@ Lcore-related options
Device-related options
~~~~~~~~~~~~~~~~~~~~~~
* ``-b, --pci-blacklist <[domain:]bus:devid.func>``
* ``-b, --block <[domain:]bus:devid.func>``
Blacklist a PCI device to prevent EAL from using it. Multiple -b options are
allowed.
Skip probing a PCI device to prevent EAL from using it.
Multiple -b options are allowed.
.. Note::
PCI blacklist cannot be used with ``-w`` option.
Block list cannot be used with the allow list ``-a`` option.
* ``-w, --pci-whitelist <[domain:]bus:devid.func>``
* ``-a, --allow <[domain:]bus:devid.func>``
Add a PCI device in white list.
Add a PCI device in to the list of devices to probe.
.. Note::
PCI whitelist cannot be used with ``-b`` option.
Allow list cannot be used with the block list ``-b`` option.
* ``--vdev <device arguments>``

View File

@ -93,11 +93,11 @@ parameter ``--vfio-vf-token``.
3. echo 2 > /sys/bus/pci/devices/0000:86:00.0/sriov_numvfs
4. Start the PF:
<build_dir>/app/dpdk-testpmd -l 22-25 -n 4 -w 86:00.0 \
<build_dir>/app/dpdk-testpmd -l 22-25 -n 4 -a 86:00.0 \
--vfio-vf-token=14d63f20-8445-11ea-8900-1f9ce7d5650d --file-prefix=pf -- -i
5. Start the VF:
<build_dir>/app/dpdk-testpmd -l 26-29 -n 4 -w 86:02.0 \
<build_dir>/app/dpdk-testpmd -l 26-29 -n 4 -a 86:02.0 \
--vfio-vf-token=14d63f20-8445-11ea-8900-1f9ce7d5650d --file-prefix=vf0 -- -i
Also, to use VFIO, both kernel and BIOS must support and be configured to use IO virtualization (such as Intel® VT-d).

View File

@ -42,7 +42,7 @@ Runtime Config Options
for the application.
For example::
-w 0002:02:00.0,max_pools=512
-a 0002:02:00.0,max_pools=512
With the above configuration, the driver will set up only 512 mempools for
the given application to save HW resources.
@ -61,7 +61,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,npa_lock_mask=0xf
-a 0002:02:00.0,npa_lock_mask=0xf
Debugging Options
~~~~~~~~~~~~~~~~~

View File

@ -683,7 +683,7 @@ The feature uses a newly implemented control-plane firmware interface which
optimizes flow insertions and deletions.
This is a tech preview feature, and is disabled by default. It can be enabled
using bnxt devargs. For ex: "-w 0000:0d:00.0,host-based-truflow=1”.
using bnxt devargs. For ex: "-a 0000:0d:00.0,host-based-truflow=1”.
Notes
-----
@ -745,7 +745,7 @@ when the PMD is initialized on a PF or trusted-VF. The user can specify the list
of VF IDs of the VFs for which the representors are needed by using the
``devargs`` option ``representor``.::
-w DBDF,representor=[0,1,4]
-a DBDF,representor=[0,1,4]
Note that currently hot-plugging of representor ports is not supported so all
the required representors must be specified on the creation of the PF or the
@ -770,12 +770,12 @@ same host domain, additional dev args have been added to the PMD.
The sample command line with the new ``devargs`` looks like this::
-w 0000:06:02.0,host-based-truflow=1,representor=[1],rep-based-pf=8,\
-a 0000:06:02.0,host-based-truflow=1,representor=[1],rep-based-pf=8,\
rep-is-pf=1,rep-q-r2f=1,rep-fc-r2f=0,rep-q-f2r=1,rep-fc-f2r=1
.. code-block:: console
testpmd -l1-4 -n2 -w 0008:01:00.0,host-based-truflow=1,\
testpmd -l1-4 -n2 -a 0008:01:00.0,host-based-truflow=1,\
representor=[0], rep-based-pf=8,rep-is-pf=0,rep-q-r2f=1,rep-fc-r2f=1,\
rep-q-f2r=0,rep-fc-f2r=1 --log-level="pmd.*",8 -- -i --rxq=3 --txq=3

View File

@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_net_cxgbe registers
itself as a PCI driver that allocates one Ethernet device per detected
port.
For this reason, one cannot whitelist/blacklist a single port without
whitelisting/blacklisting the other ports on the same device.
For this reason, one cannot allow/block a single port without
allowing/blocking the other ports on the same device.
.. _t5-nics:
@ -96,7 +96,7 @@ be passed as part of EAL arguments. For example,
.. code-block:: console
dpdk-testpmd -w 02:00.4,keep_ovlan=1 -- -i
dpdk-testpmd -a 02:00.4,keep_ovlan=1 -- -i
Common Runtime Options
~~~~~~~~~~~~~~~~~~~~~~
@ -301,7 +301,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
dpdk-testpmd -w 02:00.4,filtermode=0x88 -- -i
dpdk-testpmd -a 02:00.4,filtermode=0x88 -- -i
- ``filtermask`` (default **0**)
@ -328,7 +328,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
dpdk-testpmd -w 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
dpdk-testpmd -a 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
.. _driver-compilation:
@ -760,7 +760,7 @@ devices managed by librte_net_cxgbe in FreeBSD operating system.
.. code-block:: console
./<build_dir>/app/dpdk-testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
./<build_dir>/app/dpdk-testpmd -l 0-3 -n 4 -a 0000:02:00.4 -- -i
Example output:

View File

@ -163,10 +163,10 @@ Manager.
this pool.
Whitelisting & Blacklisting
---------------------------
Allowing & Blocking
-------------------
For blacklisting a DPAA device, following commands can be used.
For blocking a DPAA device, following commands can be used.
.. code-block:: console

View File

@ -503,10 +503,10 @@ which are lower than logging ``level``.
Using ``pmd.net.dpaa2`` as log matching criteria, all PMD logs can be enabled
which are lower than logging ``level``.
Whitelisting & Blacklisting
---------------------------
Allowing & Blocking
-------------------
For blacklisting a DPAA2 device, following commands can be used.
For blocking a DPAA2 device, following commands can be used.
.. code-block:: console
@ -514,18 +514,18 @@ For blacklisting a DPAA2 device, following commands can be used.
Where x is the device object id as configured in resource container.
Running secondary debug app without blacklist
Running secondary debug app without blocklist
---------------------------------------------
dpaa2 hardware imposes limits on some H/W access devices like Management
Control Port and H/W portal. This causes issue in their shared usages in
case of multi-process applications. It can overcome by using
whitelist/blacklist in primary and secondary applications.
allowlist/blocklist in primary and secondary applications.
In order to ease usage of standard debugging apps like dpdk-procinfo, dpaa2
driver reserves extra Management Control Port and H/W portal which can be
used by debug application to debug any existing application without
blacklisting these devices in primary process.
blocking these devices in primary process.
Limitations
-----------

View File

@ -305,7 +305,7 @@ enables overlay offload, it prints the following message on the console.
By default, PMD enables overlay offload if hardware supports it. To disable
it, set ``devargs`` parameter ``disable-overlay=1``. For example::
-w 12:00.0,disable-overlay=1
-a 12:00.0,disable-overlay=1
By default, the NIC uses 4789 as the VXLAN port. The user may change
it through ``rte_eth_dev_udp_tunnel_port_{add,delete}``. However, as
@ -371,7 +371,7 @@ vectorized handler, take the following steps.
PMD consider the vectorized handler when selecting the receive handler.
For example::
-w 12:00.0,enable-avx2-rx=1
-a 12:00.0,enable-avx2-rx=1
As the current implementation is intended for field trials, by default, the
vectorized handler is not considered (``enable-avx2-rx=0``).
@ -420,7 +420,7 @@ DPDK as untagged packets. In this case mbuf->vlan_tci and the PKT_RX_VLAN and
PKT_RX_VLAN_STRIPPED mbuf flags would not be set. This mode is enabled with the
``devargs`` parameter ``ig-vlan-rewrite=untag``. For example::
-w 12:00.0,ig-vlan-rewrite=untag
-a 12:00.0,ig-vlan-rewrite=untag
- **SR-IOV**

View File

@ -48,7 +48,7 @@ Fail-safe command line parameters
This parameter allows the user to define a sub-device. The ``<iface>`` part of
this parameter must be a valid device definition. It follows the same format
provided to any ``-w`` or ``--vdev`` options.
provided to any ``-a`` or ``--vdev`` options.
Enclosing the device definition within parentheses here allows using
additional sub-device parameters if need be. They will be passed on to the
@ -56,11 +56,11 @@ Fail-safe command line parameters
.. note::
In case where the sub-device is also used as a whitelist device, using ``-w``
In case where the sub-device is also used as an allowed device, using ``-a``
on the EAL command line, the fail-safe PMD will use the device with the
options provided to the EAL instead of its own parameters.
When trying to use a PCI device automatically probed by the blacklist mode,
When trying to use a PCI device automatically probed by the command line,
the name for the fail-safe sub-device must be the full PCI id:
Domain:Bus:Device.Function, *i.e.* ``00:00:00.0`` instead of ``00:00.0``,
as the second form is historically accepted by the DPDK.
@ -111,8 +111,8 @@ This section shows some example of using **testpmd** with a fail-safe PMD.
#. To build a PMD and configure DPDK, refer to the document
:ref:`compiling and testing a PMD for a NIC <pmd_build_and_test>`.
#. Start testpmd. The sub-device ``84:00.0`` should be blacklisted from normal EAL
operations to avoid probing it twice, as the PCI bus is in blacklist mode.
#. Start testpmd. The sub-device ``84:00.0`` should be blocked from normal EAL
operations to avoid probing it twice, as the PCI bus is in blocklist mode.
.. code-block:: console
@ -120,25 +120,25 @@ This section shows some example of using **testpmd** with a fail-safe PMD.
--vdev 'net_failsafe0,mac=de:ad:be:ef:01:02,dev(84:00.0),dev(net_ring0)' \
-b 84:00.0 -b 00:04.0 -- -i
If the sub-device ``84:00.0`` is not blacklisted, it will be probed by the
If the sub-device ``84:00.0`` is not blocked, it will be probed by the
EAL first. When the fail-safe then tries to initialize it the probe operation
fails.
Note that PCI blacklist mode is the default PCI operating mode.
Note that PCI blocklist mode is the default PCI operating mode.
#. Alternatively, it can be used alongside any other device in whitelist mode.
#. Alternatively, it can be used alongside any other device in allow mode.
.. code-block:: console
./<build_dir>/app/dpdk-testpmd -c 0xff -n 4 \
--vdev 'net_failsafe0,mac=de:ad:be:ef:01:02,dev(84:00.0),dev(net_ring0)' \
-w 81:00.0 -- -i
-a 81:00.0 -- -i
#. Start testpmd using a flexible device definition
.. code-block:: console
./<build_dir>/app/dpdk-testpmd -c 0xff -n 4 -w ff:ff.f \
./<build_dir>/app/dpdk-testpmd -c 0xff -n 4 -a ff:ff.f \
--vdev='net_failsafe0,exec(echo 84:00.0)' -- -i
#. Start testpmd, automatically probing the device 84:00.0 and using it with

View File

@ -19,7 +19,7 @@ resource tag) information, rather than the mac and vlan table. Currently this
feature works only on PF.
To enable this feature, the user should pass a devargs parameter to the eal
like "-w 84:00.0,enable_ftag=1", and the application should make sure an
like "-a 84:00.0,enable_ftag=1", and the application should make sure an
appropriate FTAG is inserted for every frame on TX side.
Vector PMD for FM10K

View File

@ -176,7 +176,7 @@ Runtime Config Options
The number of reserved queue per VF is determined by its host PF. If the
PCI address of an i40e PF is aaaa:bb.cc, the number of reserved queues per
VF can be configured with EAL parameter like -w aaaa:bb.cc,queue-num-per-vf=n.
VF can be configured with EAL parameter like -a aaaa:bb.cc,queue-num-per-vf=n.
The value n can be 1, 2, 4, 8 or 16. If no such parameter is configured, the
number of reserved queues per VF is 4 by default. If VF request more than
reserved queues per VF, PF will able to allocate max to 16 queues after a VF
@ -189,7 +189,7 @@ Runtime Config Options
Adapter with both Linux kernel and DPDK PMD. To fix this issue, ``devargs``
parameter ``support-multi-driver`` is introduced, for example::
-w 84:00.0,support-multi-driver=1
-a 84:00.0,support-multi-driver=1
With the above configuration, DPDK PMD will not change global registers, and
will switch PF interrupt from IntN to Int0 to avoid interrupt conflict between
@ -204,7 +204,7 @@ Runtime Config Options
port representors for on initialization of the PF PMD by passing the VF IDs of
the VFs which are required.::
-w DBDF,representor=[0,1,4]
-a DBDF,representor=[0,1,4]
Currently hot-plugging of representor ports is not supported so all required
representors must be specified on the creation of the PF.
@ -216,7 +216,7 @@ Runtime Config Options
since it can get better perf in some real work loading cases. So ``devargs`` param
``use-latest-supported-vec`` is introduced, for example::
-w 84:00.0,use-latest-supported-vec=1
-a 84:00.0,use-latest-supported-vec=1
- ``Enable validation for VF message`` (default ``not enabled``)
@ -226,7 +226,7 @@ Runtime Config Options
Format -- "maximal-message@period-seconds:ignore-seconds"
For example::
-w 84:00.0,vf_msg_cfg=80@120:180
-a 84:00.0,vf_msg_cfg=80@120:180
Vector RX Pre-conditions
~~~~~~~~~~~~~~~~~~~~~~~~
@ -456,7 +456,7 @@ no physical uplink on the associated NIC port.
To enable this feature, the user should pass a ``devargs`` parameter to the
EAL, for example::
-w 84:00.0,enable_floating_veb=1
-a 84:00.0,enable_floating_veb=1
In this configuration the PMD will use the floating VEB feature for all the
VFs created by this PF device.
@ -464,7 +464,7 @@ VFs created by this PF device.
Alternatively, the user can specify which VFs need to connect to this floating
VEB using the ``floating_veb_list`` argument::
-w 84:00.0,enable_floating_veb=1,floating_veb_list=1;3-4
-a 84:00.0,enable_floating_veb=1,floating_veb_list=1;3-4
In this example ``VF1``, ``VF3`` and ``VF4`` connect to the floating VEB,
while other VFs connect to the normal VEB.
@ -800,7 +800,7 @@ See :numref:`figure_intel_perf_test_setup` for the performance test setup.
7. The command line of running l3fwd would be something like the following::
./dpdk-l3fwd -l 18-21 -n 4 -w 82:00.0 -w 85:00.0 \
./dpdk-l3fwd -l 18-21 -n 4 -a 82:00.0 -a 85:00.0 \
-- -p 0x3 --config '(0,0,18),(0,1,19),(1,0,20),(1,1,21)'
This means that the application uses core 18 for port 0, queue pair 0 forwarding, core 19 for port 0, queue pair 1 forwarding,

View File

@ -30,7 +30,7 @@ Runtime Config Options
But if user intend to use the device without OS package, user can take ``devargs``
parameter ``safe-mode-support``, for example::
-w 80:00.0,safe-mode-support=1
-a 80:00.0,safe-mode-support=1
Then the driver will be initialized successfully and the device will enter Safe Mode.
NOTE: In Safe mode, only very limited features are available, features like RSS,
@ -53,7 +53,7 @@ Runtime Config Options
use pipeline mode by setting ``devargs`` parameter ``pipeline-mode-support``,
for example::
-w 80:00.0,pipeline-mode-support=1
-a 80:00.0,pipeline-mode-support=1
- ``Protocol extraction for per queue``
@ -62,8 +62,8 @@ Runtime Config Options
The argument format is::
-w 18:00.0,proto_xtr=<queues:protocol>[<queues:protocol>...]
-w 18:00.0,proto_xtr=<protocol>
-a 18:00.0,proto_xtr=<queues:protocol>[<queues:protocol>...]
-a 18:00.0,proto_xtr=<protocol>
Queues are grouped by ``(`` and ``)`` within the group. The ``-`` character
is used as a range separator and ``,`` is used as a single number separator.
@ -74,14 +74,14 @@ Runtime Config Options
.. code-block:: console
dpdk-testpmd -w 18:00.0,proto_xtr='[(1,2-3,8-9):tcp,10-13:vlan]'
dpdk-testpmd -a 18:00.0,proto_xtr='[(1,2-3,8-9):tcp,10-13:vlan]'
This setting means queues 1, 2-3, 8-9 are TCP extraction, queues 10-13 are
VLAN extraction, other queues run with no protocol extraction.
.. code-block:: console
dpdk-testpmd -w 18:00.0,proto_xtr=vlan,proto_xtr='[(1,2-3,8-9):tcp,10-23:ipv6]'
dpdk-testpmd -a 18:00.0,proto_xtr=vlan,proto_xtr='[(1,2-3,8-9):tcp,10-23:ipv6]'
This setting means queues 1, 2-3, 8-9 are TCP extraction, queues 10-23 are
IPv6 extraction, other queues use the default VLAN extraction.
@ -233,7 +233,7 @@ responses for the same from PF.
#. Bind the VF0, and run testpmd with 'cap=dcf' devarg::
dpdk-testpmd -l 22-25 -n 4 -w 18:01.0,cap=dcf -- -i
dpdk-testpmd -l 22-25 -n 4 -a 18:01.0,cap=dcf -- -i
#. Monitor the VF2 interface network traffic::

View File

@ -89,7 +89,7 @@ be passed as part of EAL arguments. For example,
.. code-block:: console
testpmd -w af:10.0,pflink_fullchk=1 -- -i
testpmd -a af:10.0,pflink_fullchk=1 -- -i
- ``pflink_fullchk`` (default **0**)
@ -277,7 +277,7 @@ option ``representor`` the user can specify which virtual functions to create
port representors for on initialization of the PF PMD by passing the VF IDs of
the VFs which are required.::
-w DBDF,representor=[0,1,4]
-a DBDF,representor=[0,1,4]
Currently hot-plugging of representor ports is not supported so all required
representors must be specified on the creation of the PF.

View File

@ -24,8 +24,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_net_mlx4 registers itself as a
PCI driver that allocates one Ethernet device per detected port.
For this reason, one cannot white/blacklist a single port without also
white/blacklisting the others on the same device.
For this reason, one cannot block (or allow) a single port without also
blocking (or allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_net_mlx4 relies heavily on system calls for control
@ -381,7 +381,7 @@ devices managed by librte_net_mlx4.
eth4
eth5
#. Optionally, retrieve their PCI bus addresses for whitelisting::
#. Optionally, retrieve their PCI bus addresses to be used with the allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@ -389,14 +389,14 @@ devices managed by librte_net_mlx4.
(cd "/sys/class/net/${intf}/device/" && pwd -P);
done;
} |
sed -n 's,.*/\(.*\),-w \1,p'
sed -n 's,.*/\(.*\),-a \1,p'
Example output::
-w 0000:83:00.0
-w 0000:83:00.0
-w 0000:84:00.0
-w 0000:84:00.0
-a 0000:83:00.0
-a 0000:83:00.0
-a 0000:84:00.0
-a 0000:84:00.0
.. note::
@ -409,7 +409,7 @@ devices managed by librte_net_mlx4.
#. Start testpmd with basic parameters::
testpmd -l 8-15 -n 4 -w 0000:83:00.0 -w 0000:84:00.0 -- --rxq=2 --txq=2 -i
testpmd -l 8-15 -n 4 -a 0000:83:00.0 -a 0000:84:00.0 -- --rxq=2 --txq=2 -i
Example output::

View File

@ -1524,7 +1524,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_net_mlx5.
eth32
eth33
#. Optionally, retrieve their PCI bus addresses for whitelisting::
#. Optionally, retrieve their PCI bus addresses for to be used with the allow list::
{
for intf in eth2 eth3 eth4 eth5;
@ -1532,14 +1532,14 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_net_mlx5.
(cd "/sys/class/net/${intf}/device/" && pwd -P);
done;
} |
sed -n 's,.*/\(.*\),-w \1,p'
sed -n 's,.*/\(.*\),-a \1,p'
Example output::
-w 0000:05:00.1
-w 0000:06:00.0
-w 0000:06:00.1
-w 0000:05:00.0
-a 0000:05:00.1
-a 0000:06:00.0
-a 0000:06:00.1
-a 0000:05:00.0
#. Request huge pages::
@ -1547,7 +1547,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_net_mlx5.
#. Start testpmd with basic parameters::
testpmd -l 8-15 -n 4 -w 05:00.0 -w 05:00.1 -w 06:00.0 -w 06:00.1 -- --rxq=2 --txq=2 -i
testpmd -l 8-15 -n 4 -a 05:00.0 -a 05:00.1 -a 06:00.0 -a 06:00.1 -- --rxq=2 --txq=2 -i
Example output::

View File

@ -63,7 +63,7 @@ products) and the device argument `timestamp=1` must be used.
.. code-block:: console
./<build_dir>/app/dpdk-testpmd -w b3:00.0,timestamp=1 <other EAL params> -- <testpmd params>
./<build_dir>/app/dpdk-testpmd -a b3:00.0,timestamp=1 <other EAL params> -- <testpmd params>
When the timestamps are enabled with the *devarg*, a timestamp validity flag is set in the MBUFs
containing received frames and timestamp is inserted into the `rte_mbuf` struct.

View File

@ -63,7 +63,7 @@ for details.
.. code-block:: console
./<build_dir>/app/dpdk-testpmd -c 0x300 -w 0002:02:00.0 -- --portmask=0x1 --nb-cores=1 --port-topology=loop --rxq=1 --txq=1
./<build_dir>/app/dpdk-testpmd -c 0x300 -a 0002:02:00.0 -- --portmask=0x1 --nb-cores=1 --port-topology=loop --rxq=1 --txq=1
EAL: Detected 24 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
@ -116,7 +116,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,reta_size=256
-a 0002:02:00.0,reta_size=256
With the above configuration, reta table of size 256 is populated.
@ -127,7 +127,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,flow_max_priority=10
-a 0002:02:00.0,flow_max_priority=10
With the above configuration, priority level was set to 10 (0-9). Max
priority level supported is 32.
@ -139,7 +139,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,flow_prealloc_size=4
-a 0002:02:00.0,flow_prealloc_size=4
With the above configuration, pre alloc size was set to 4. Max pre alloc
size supported is 32.
@ -151,7 +151,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,max_sqb_count=64
-a 0002:02:00.0,max_sqb_count=64
With the above configuration, each send queue's decscriptor buffer count is
limited to a maximum of 64 buffers.
@ -163,7 +163,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,switch_header="higig2"
-a 0002:02:00.0,switch_header="higig2"
With the above configuration, higig2 will be enabled on that port and the
traffic on this port should be higig2 traffic only. Supported switch header
@ -185,7 +185,7 @@ Runtime Config Options
For example to select the legacy mode(RSS tag adder as XOR)::
-w 0002:02:00.0,tag_as_xor=1
-a 0002:02:00.0,tag_as_xor=1
- ``Max SPI for inbound inline IPsec`` (default ``1``)
@ -194,7 +194,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,ipsec_in_max_spi=128
-a 0002:02:00.0,ipsec_in_max_spi=128
With the above configuration, application can enable inline IPsec processing
on 128 SAs (SPI 0-127).
@ -205,7 +205,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,lock_rx_ctx=1
-a 0002:02:00.0,lock_rx_ctx=1
- ``Lock Tx contexts in NDC cache``
@ -213,7 +213,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,lock_tx_ctx=1
-a 0002:02:00.0,lock_tx_ctx=1
.. note::
@ -229,7 +229,7 @@ Runtime Config Options
For example::
-w 0002:02:00.0,npa_lock_mask=0xf
-a 0002:02:00.0,npa_lock_mask=0xf
.. _otx2_tmapi:

View File

@ -350,7 +350,7 @@ Per-Device Parameters
~~~~~~~~~~~~~~~~~~~~~
The following per-device parameters can be passed via EAL PCI device
whitelist option like "-w 02:00.0,arg1=value1,...".
allow option like "-a 02:00.0,arg1=value1,...".
Case-insensitive 1/y/yes/on or 0/n/no/off may be used to specify
boolean parameters value.

View File

@ -191,7 +191,7 @@ following::
.. Note:
Change the ``-b`` options to blacklist all of your physical ports. The
Change the ``-b`` options to exclude all of your physical ports. The
following command line is all one line.
Also, ``-f themes/black-yellow.theme`` is optional if the default colors

View File

@ -157,7 +157,7 @@ This section provides instructions to configure SR-IOV with Linux OS.
.. code-block:: console
./<build_dir>/app/dpdk-testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
./<build_dir>/app/dpdk-testpmd -l 0-3 -n 4 -a 0002:01:00.2 \
-- -i --no-flush-rx \
--port-topology=loop
@ -377,7 +377,7 @@ This scheme is useful when application would like to insert vlan header without
Example:
.. code-block:: console
-w 0002:01:00.2,skip_data_bytes=8
-a 0002:01:00.2,skip_data_bytes=8
Limitations
-----------

View File

@ -19,7 +19,7 @@ Physical compression devices are discovered during the bus probe of the EAL func
which is executed at DPDK initialization, based on their unique device identifier.
For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
listed using the EAL command line options.
Virtual devices can be created by two mechanisms, either using the EAL command
line options or from within the application using an EAL API directly.

View File

@ -32,7 +32,7 @@ Physical Crypto devices are discovered during the PCI probe/enumeration of the
EAL function which is executed at DPDK initialization, based on
their PCI device identifier, each unique PCI BDF (bus/bridge, device,
function). Specific physical Crypto devices, like other physical devices in DPDK
can be white-listed or black-listed using the EAL command line options.
can be listed using the EAL command line options.
Virtual devices can be created by two mechanisms, either using the EAL command
line options or from within the application using an EAL API directly.

View File

@ -407,12 +407,12 @@ device having emitted a Device Removal Event. In such case, calling
callback. Care must be taken not to close the device from the interrupt handler
context. It is necessary to reschedule such closing operation.
Blacklisting
~~~~~~~~~~~~
Block list
~~~~~~~~~~
The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
The EAL PCI device block list functionality can be used to mark certain NIC ports as unavailable,
so they are ignored by the DPDK.
The ports to be blacklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
The ports to be blocked are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~

View File

@ -30,7 +30,7 @@ after a primary process has already configured the hugepage shared memory for th
Secondary processes should run alongside primary process with same DPDK version.
Secondary processes which requires access to physical devices in Primary process, must
be passed with the same whitelist and blacklist options.
be passed with the same allow and block options.
To support these two process types, and other multi-process setups described later,
two additional command-line parameters are available to the EAL:
@ -131,7 +131,7 @@ can use).
.. note::
Independent DPDK instances running side-by-side on a single machine cannot share any network ports.
Any network ports being used by one process should be blacklisted in every other process.
Any network ports being used by one process should be blocked by every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -374,9 +374,9 @@ parameters to those ports.
this argument allows user to specify which switch ports to enable port
representors for.::
-w DBDF,representor=0
-w DBDF,representor=[0,4,6,9]
-w DBDF,representor=[0-31]
-a DBDF,representor=0
-a DBDF,representor=[0,4,6,9]
-a DBDF,representor=[0-31]
Note: PMDs are not required to support the standard device arguments and users
should consult the relevant PMD documentation to see support devargs.

View File

@ -30,7 +30,7 @@ Physical RegEx devices are discovered during the PCI probe/enumeration of the
EAL function which is executed at DPDK initialization, based on
their PCI device identifier, each unique PCI BDF (bus/bridge, device,
function). Specific physical ReEx devices, like other physical devices in DPDK
can be white-listed or black-listed using the EAL command line options.
can be listed using the EAL command line options.
Device Identification

View File

@ -59,9 +59,9 @@ which can be thought as a software "patch panel" front-end for applications.
::
-w pci:dbdf,representor=0
-w pci:dbdf,representor=[0-3]
-w pci:dbdf,representor=[0,5-11]
-a pci:dbdf,representor=0
-a pci:dbdf,representor=[0-3]
-a pci:dbdf,representor=[0,5-11]
- As virtual devices, they may be more limited than their physical
counterparts, for instance by exposing only a subset of device

View File

@ -28,17 +28,6 @@ Deprecation Notices
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
* eal: The terms blacklist and whitelist to describe devices used
by DPDK will be replaced in the 20.11 relase.
This will apply to command line arguments.
The command line arguments to ``rte_eal_init`` will change from
``-b, --pci-blacklist`` to ``-x, --exclude`` and
``-w, --pci-whitelist`` to ``-i, --include``.
The old command line arguments will continue to be accepted in 20.11
but will cause a runtime warning message. The old arguments will
be removed in a future release.
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.

View File

@ -475,6 +475,12 @@ API Changes
``RTE_LCORE_FOREACH_SLAVE`` is replaced with
``RTE_LCORE_FOREACH_WORKER``.
* eal: The definitions related to including and excluding devices
has been changed from blacklist/whitelist to block/allow list.
There are compatibility macros and command line mapping to accept
the old values but applications and scripts are strongly encouraged
to migrate to the new names.
* eal: The ``rte_logs`` struct and global symbol was made private
and is no longer part of the API.

View File

@ -61,19 +61,19 @@ This means that HW baseband device/s must be bound to a DPDK driver or
a SW baseband device/s (virtual BBdev) must be created (using --vdev).
To run the application in linux environment with the turbo_sw baseband device
using the whitelisted port running on 1 encoding lcore and 1 decoding lcore
using the allow option for pci device running on 1 encoding lcore and 1 decoding lcore
issue the command:
.. code-block:: console
$ ./<build_dir>/examples/dpdk-bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> \
$ ./<build_dir>/examples/dpdk-bbdev --vdev='baseband_turbo_sw' -a <NIC0PCIADDR> \
-c 0x38 --socket-mem=2,2 --file-prefix=bbdev -- -e 0x10 -d 0x20
where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
the parameter -w.
device gets linked to a corresponding ethernet port as allowed by
the parameter -a.
3 cores are allocated to the application, and assigned as:
- core 3 is the main and used to print the stats live on screen,
@ -93,20 +93,20 @@ Using Packet Generator with baseband device sample application
To allow the bbdev sample app to do the loopback, an influx of traffic is required.
This can be done by using DPDK Pktgen to burst traffic on two ethernet ports, and
it will print the transmitted along with the looped-back traffic on Rx ports.
Executing the command below will generate traffic on the two whitelisted ethernet
Executing the command below will generate traffic on the two allowed ethernet
ports.
.. code-block:: console
$ ./pktgen-3.4.0/app/x86_64-native-linux-gcc/pktgen -c 0x3 \
--socket-mem=1,1 --file-prefix=pg -w <NIC1PCIADDR> -- -m 1.0 -P
--socket-mem=1,1 --file-prefix=pg -a <NIC1PCIADDR> -- -m 1.0 -P
where:
* ``-c COREMASK``: A hexadecimal bitmask of cores to run on
* ``--socket-mem``: Memory to allocate on specific sockets (use comma separated values)
* ``--file-prefix``: Prefix for hugepage filenames
* ``-w <NIC1PCIADDR>``: Add a PCI device in white list. The argument format is <[domain:]bus:devid.func>.
* ``-a <NIC1PCIADDR>``: Add a PCI device in allow list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode

View File

@ -46,8 +46,8 @@ these settings is shown below:
.. code-block:: console
./<build_dir>/examples/dpdk-eventdev_pipeline --vdev event_sw0 -- -r1 -t1 /
-e4 -w FF00 -s4 -n0 -c32 -W1000 -D
./<build_dir>/examples/dpdk-eventdev_pipeline --vdev event_sw0 -- -r1 -t1 \
-e4 -a FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application

View File

@ -323,15 +323,15 @@ This means that if the application is using a single core and both hardware
and software crypto devices are detected, hardware devices will be used.
A way to achieve the case where you want to force the use of virtual crypto
devices is to whitelist the Ethernet devices needed and therefore implicitly
blacklisting all hardware crypto devices.
devices is to only use the Ethernet devices needed (via the allow flag)
and therefore implicitly blocking all hardware crypto devices.
For example, something like the following command line:
.. code-block:: console
./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \
-w 81:00.0 -w 81:00.1 -w 81:00.2 -w 81:00.3 \
-a 81:00.0 -a 81:00.1 -a 81:00.2 -a 81:00.3 \
--vdev "crypto_aesni_mb" --vdev "crypto_null" \
-- \
-p 0xf -P -u 0x3 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \
@ -929,13 +929,13 @@ The user must setup the following environment variables:
* ``REMOTE_IFACE``: interface name for the test-port on the DUT.
* ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>')
* ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-a <pci-id>')
Also the user can optionally setup:
* ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)
* ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified
* ``CRYPTO_DEV``: crypto device to be used ('-a <pci-id>'). If none specified
appropriate vdevs will be created by the script
Scripts can be used for multiple test scenarios. To check all available

View File

@ -138,17 +138,19 @@ Following is the sample command:
.. code-block:: console
./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x3 --eventq-sched=ordered
./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered
or
.. code-block:: console
./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x03 --mode=eventdev --eventq-sched=ordered
./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> \
-- -p 0x03 --mode=eventdev --eventq-sched=ordered
In this command:
* -w option whitelist the event device supported by platform. Way to pass this device may vary based on platform.
* -a option allows the event device supported by platform.
The syntax used to indicate this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.

View File

@ -378,7 +378,8 @@ See :doc:`Power Management<../prog_guide/power_man>` chapter in the DPDK Program
.. code-block:: console
./<build_dir>/examples/dpdk-l3fwd-power -l xxx -n 4 -w 0000:xx:00.0 -w 0000:xx:00.1 -- -p 0x3 -P --config="(0,0,xx),(1,0,xx)" --empty-poll="0,0,0" -l 14 -m 9 -h 1
./<build_dir>/examples/dpdk-l3fwd-power -l xxx -n 4 -a 0000:xx:00.0 -a 0000:xx:00.1 \
-- -p 0x3 -P --config="(0,0,xx),(1,0,xx)" --empty-poll="0,0,0" -l 14 -m 9 -h 1
Where,

View File

@ -52,7 +52,7 @@ Take IFCVF driver for example:
.. code-block:: console
./dpdk-vdpa -c 0x2 -n 4 --socket-mem 1024,1024 \
-w 0000:06:00.3,vdpa=1 -w 0000:06:00.4,vdpa=1 \
-a 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::

View File

@ -53,9 +53,9 @@ See the DPDK Getting Started Guides for more information on these options.
One lcore is needed for process admin, tests are run on all other cores.
To run tests on two lcores, three lcores must be passed to the tool.
* ``-w <PCI>``
* ``-a <PCI>``
Add a PCI device in white list.
Add a PCI device in allow list.
* ``--vdev <driver><id>``

View File

@ -65,9 +65,9 @@ See the DPDK Getting Started Guides for more information on these options.
Set the hexadecimal bitmask of the cores to run on. The corelist is a
list cores to use.
* ``-w <PCI>``
* ``-a <PCI>``
Add a PCI device in white list.
Add a PCI device in allow list.
* ``--vdev <driver><id>``
@ -394,7 +394,7 @@ Call application for performance throughput test of single Aesni MB PMD
for cipher encryption aes-cbc and auth generation sha1-hmac,
one million operations, burst size 32, packet size 64::
dpdk-test-crypto-perf -l 6-7 --vdev crypto_aesni_mb -w 0000:00:00.0 --
dpdk-test-crypto-perf -l 6-7 --vdev crypto_aesni_mb -a 0000:00:00.0 --
--ptest throughput --devtype crypto_aesni_mb --optype cipher-then-auth
--cipher-algo aes-cbc --cipher-op encrypt --cipher-key-sz 16 --auth-algo
sha1-hmac --auth-op generate --auth-key-sz 64 --digest-sz 12
@ -404,7 +404,7 @@ Call application for performance latency test of two Aesni MB PMD executed
on two cores for cipher encryption aes-cbc, ten operations in silent mode::
dpdk-test-crypto-perf -l 4-7 --vdev crypto_aesni_mb1
--vdev crypto_aesni_mb2 -w 0000:00:00.0 -- --devtype crypto_aesni_mb
--vdev crypto_aesni_mb2 -a 0000:00:00.0 -- --devtype crypto_aesni_mb
--cipher-algo aes-cbc --cipher-key-sz 16 --cipher-iv-sz 16
--cipher-op encrypt --optype cipher-only --silent
--ptest latency --total-ops 10
@ -414,7 +414,7 @@ for cipher encryption aes-gcm and auth generation aes-gcm,ten operations
in silent mode, test vector provide in file "test_aes_gcm.data"
with packet verification::
dpdk-test-crypto-perf -l 4-7 --vdev crypto_openssl -w 0000:00:00.0 --
dpdk-test-crypto-perf -l 4-7 --vdev crypto_openssl -a 0000:00:00.0 --
--devtype crypto_openssl --aead-algo aes-gcm --aead-key-sz 16
--aead-iv-sz 16 --aead-op encrypt --aead-aad-sz 16 --digest-sz 16
--optype aead --silent --ptest verify --total-ops 10

View File

@ -65,7 +65,7 @@ with a ``--`` separator:
.. code-block:: console
sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --rules-count=1000000
sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --rules-count=1000000
The command line options are:

View File

@ -70,4 +70,4 @@ The data file, will be used as a source data for the RegEx to work on.
The tool has a number of command line options. Here is the sample command line::
./dpdk-test-regex -w 83:00.0 -- --rules rule_file.rof2 --data data_file.txt --job 100
./dpdk-test-regex -a 83:00.0 -- --rules rule_file.rof2 --data data_file.txt --job 100

View File

@ -206,7 +206,7 @@ vmbus_parse(const char *name, void *addr)
/*
* scan for matching device args on command line
* example:
* -w 'vmbus:635a7ae3-091e-4410-ad59-667c4f8c04c3,latency=20'
* -a 'vmbus:635a7ae3-091e-4410-ad59-667c4f8c04c3,latency=20'
*/
struct rte_devargs *
vmbus_devargs_lookup(struct rte_vmbus_device *dev)

View File

@ -5151,21 +5151,21 @@ bnxt_parse_dev_args(struct bnxt *bp, struct rte_devargs *devargs)
/*
* Handler for "truflow" devarg.
* Invoked as for ex: "-w 0000:00:0d.0,host-based-truflow=1"
* Invoked as for ex: "-a 0000:00:0d.0,host-based-truflow=1"
*/
rte_kvargs_process(kvlist, BNXT_DEVARG_TRUFLOW,
bnxt_parse_devarg_truflow, bp);
/*
* Handler for "flow_xstat" devarg.
* Invoked as for ex: "-w 0000:00:0d.0,flow_xstat=1"
* Invoked as for ex: "-a 0000:00:0d.0,flow_xstat=1"
*/
rte_kvargs_process(kvlist, BNXT_DEVARG_FLOW_XSTAT,
bnxt_parse_devarg_flow_xstat, bp);
/*
* Handler for "max_num_kflows" devarg.
* Invoked as for ex: "-w 000:00:0d.0,max_num_kflows=32"
* Invoked as for ex: "-a 000:00:0d.0,max_num_kflows=32"
*/
rte_kvargs_process(kvlist, BNXT_DEVARG_MAX_NUM_KFLOWS,
bnxt_parse_devarg_max_num_kflows, bp);
@ -5569,7 +5569,7 @@ static int bnxt_rep_port_probe(struct rte_pci_device *pci_dev,
if (kvlist) {
/*
* Handler for "rep_is_pf" devarg.
* Invoked as for ex: "-w 000:00:0d.0,
* Invoked as for ex: "-a 000:00:0d.0,
* rep-based-pf=<pf index> rep-is-pf=<VF=0 or PF=1>"
*/
ret = rte_kvargs_process(kvlist, BNXT_DEVARG_REP_IS_PF,
@ -5581,7 +5581,7 @@ static int bnxt_rep_port_probe(struct rte_pci_device *pci_dev,
}
/*
* Handler for "rep_based_pf" devarg.
* Invoked as for ex: "-w 000:00:0d.0,
* Invoked as for ex: "-a 000:00:0d.0,
* rep-based-pf=<pf index> rep-is-pf=<VF=0 or PF=1>"
*/
ret = rte_kvargs_process(kvlist,
@ -5594,7 +5594,7 @@ static int bnxt_rep_port_probe(struct rte_pci_device *pci_dev,
}
/*
* Handler for "rep_based_pf" devarg.
* Invoked as for ex: "-w 000:00:0d.0,
* Invoked as for ex: "-a 000:00:0d.0,
* rep-based-pf=<pf index> rep-is-pf=<VF=0 or PF=1>"
*/
ret = rte_kvargs_process(kvlist, BNXT_DEVARG_REP_Q_R2F,
@ -5606,7 +5606,7 @@ static int bnxt_rep_port_probe(struct rte_pci_device *pci_dev,
}
/*
* Handler for "rep_based_pf" devarg.
* Invoked as for ex: "-w 000:00:0d.0,
* Invoked as for ex: "-a 000:00:0d.0,
* rep-based-pf=<pf index> rep-is-pf=<VF=0 or PF=1>"
*/
ret = rte_kvargs_process(kvlist, BNXT_DEVARG_REP_Q_F2R,
@ -5618,7 +5618,7 @@ static int bnxt_rep_port_probe(struct rte_pci_device *pci_dev,
}
/*
* Handler for "rep_based_pf" devarg.
* Invoked as for ex: "-w 000:00:0d.0,
* Invoked as for ex: "-a 000:00:0d.0,
* rep-based-pf=<pf index> rep-is-pf=<VF=0 or PF=1>"
*/
ret = rte_kvargs_process(kvlist, BNXT_DEVARG_REP_FC_R2F,
@ -5630,7 +5630,7 @@ static int bnxt_rep_port_probe(struct rte_pci_device *pci_dev,
}
/*
* Handler for "rep_based_pf" devarg.
* Invoked as for ex: "-w 000:00:0d.0,
* Invoked as for ex: "-a 000:00:0d.0,
* rep-based-pf=<pf index> rep-is-pf=<VF=0 or PF=1>"
*/
ret = rte_kvargs_process(kvlist, BNXT_DEVARG_REP_FC_F2R,

View File

@ -14,7 +14,7 @@
# SGW_PATH - path to the ipsec-secgw binary to test
# REMOTE_HOST - ip/hostname of the DUT
# REMOTE_IFACE - iface name for the test-port on DUT
# ETH_DEV - ethernet device to be used on SUT by DPDK ('-w <pci-id>')
# ETH_DEV - ethernet device to be used on SUT by DPDK ('-a <pci-id>')
# Also user can optionally setup:
# SGW_LCORE - lcore to run ipsec-secgw on (default value is 0)
# SGW_MODE - run ipsec-secgw in legacy mode or with use of library
@ -29,7 +29,7 @@
# values: cpu-crypto/lookaside-none (unset on default)
# CRYPTO_PRIM_TYPE - run ipsec-secgw with crypto primary type set
# values: cpu-crypto (unset on default)
# CRYPTO_DEV - crypto device to be used ('-w <pci-id>')
# CRYPTO_DEV - crypto device to be used ('-a <pci-id>')
# if none specified appropriate vdevs will be created by the script
# SGW_MULTI_SEG - ipsec-secgw option to enable reassembly support and
# specify size of reassembly table (i.e. SGW_MULTI_SEG=128)

View File

@ -8,10 +8,10 @@
# SGW_PATH - path to the ipsec-secgw binary to test
# REMOTE_HOST - ip/hostname of the DUT
# REMOTE_IFACE - iface name for the test-port on DUT
# ETH_DEV - ethernet device to be used on SUT by DPDK ('-w <pci-id>')
# ETH_DEV - ethernet device to be used on SUT by DPDK ('-a <pci-id>')
# Also user can optionally setup:
# SGW_LCORE - lcore to run ipsec-secgw on (default value is 0)
# CRYPTO_DEV - crypto device to be used ('-w <pci-id>')
# CRYPTO_DEV - crypto device to be used ('-a <pci-id>')
# if none specified appropriate vdevs will be created by the script
# SGW_MULTI_SEG - ipsec-secgw option to enable reassembly support and
# specify size of reassembly table (i.e. SGW_MULTI_SEG=128)

View File

@ -52,7 +52,8 @@
const char
eal_short_options[] =
"b:" /* pci-blacklist */
"a:" /* allow */
"b:" /* block */
"c:" /* coremask */
"s:" /* service coremask */
"d:" /* driver */
@ -63,7 +64,7 @@ eal_short_options[] =
"n:" /* memory channels */
"r:" /* memory ranks */
"v" /* version */
"w:" /* pci-whitelist */
"w:" /* pci-whitelist (deprecated) */
;
const struct option
@ -89,8 +90,8 @@ eal_long_options[] = {
{OPT_NO_PCI, 0, NULL, OPT_NO_PCI_NUM },
{OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM },
{OPT_IN_MEMORY, 0, NULL, OPT_IN_MEMORY_NUM },
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM },
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM },
{OPT_DEV_BLOCK, 1, NULL, OPT_DEV_BLOCK_NUM },
{OPT_DEV_ALLOW, 1, NULL, OPT_DEV_ALLOW_NUM },
{OPT_PROC_TYPE, 1, NULL, OPT_PROC_TYPE_NUM },
{OPT_SOCKET_MEM, 1, NULL, OPT_SOCKET_MEM_NUM },
{OPT_SOCKET_LIMIT, 1, NULL, OPT_SOCKET_LIMIT_NUM },
@ -105,6 +106,11 @@ eal_long_options[] = {
{OPT_TELEMETRY, 0, NULL, OPT_TELEMETRY_NUM },
{OPT_NO_TELEMETRY, 0, NULL, OPT_NO_TELEMETRY_NUM },
{OPT_FORCE_MAX_SIMD_BITWIDTH, 1, NULL, OPT_FORCE_MAX_SIMD_BITWIDTH_NUM},
/* legacy options that will be removed in future */
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM },
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM },
{0, 0, NULL, 0 }
};
@ -1448,28 +1454,31 @@ eal_parse_common_option(int opt, const char *optarg,
struct internal_config *conf)
{
static int b_used;
static int w_used;
static int a_used;
switch (opt) {
/* blacklist */
case OPT_PCI_BLACKLIST_NUM:
fprintf(stderr,
"Option --pci-blacklist is deprecated, use -b, --block instead\n");
/* fallthrough */
case 'b':
if (w_used)
goto bw_used;
if (eal_option_device_add(RTE_DEVTYPE_BLOCKED,
optarg) < 0) {
if (a_used)
goto ba_conflict;
if (eal_option_device_add(RTE_DEVTYPE_BLOCKED, optarg) < 0)
return -1;
}
b_used = 1;
break;
/* whitelist */
case 'w':
fprintf(stderr,
"Option -w, --pci-whitelist is deprecated, use -a, --allow option instead\n");
/* fallthrough */
case 'a':
if (b_used)
goto bw_used;
if (eal_option_device_add(RTE_DEVTYPE_ALLOWED,
optarg) < 0) {
goto ba_conflict;
if (eal_option_device_add(RTE_DEVTYPE_ALLOWED, optarg) < 0)
return -1;
}
w_used = 1;
a_used = 1;
break;
/* coremask */
case 'c': {
@ -1760,9 +1769,10 @@ eal_parse_common_option(int opt, const char *optarg,
}
return 0;
bw_used:
RTE_LOG(ERR, EAL, "Options blacklist (-b) and whitelist (-w) "
"cannot be used at the same time\n");
ba_conflict:
RTE_LOG(ERR, EAL,
"Options allow (-a) and block (-b) can't be used at the same time\n");
return -1;
}
@ -1997,14 +2007,14 @@ eal_common_usage(void)
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
" -r RANKS Force number of memory ranks (don't detect)\n"
" -b, --"OPT_PCI_BLACKLIST" Add a PCI device in black list.\n"
" Prevent EAL from using this PCI device. The argument\n"
" format is <domain:bus:devid.func>.\n"
" -w, --"OPT_PCI_WHITELIST" Add a PCI device in white list.\n"
" Only use the specified PCI devices. The argument format\n"
" is <[domain:]bus:devid.func>. This option can be present\n"
" several times (once per device).\n"
" [NOTE: PCI whitelist cannot be used with -b option]\n"
" -b, --block Add a device to the blocked list.\n"
" Prevent EAL from using this device. The argument\n"
" format for PCI devices is <domain:bus:devid.func>.\n"
" -a, --allow Add a device to the allow list.\n"
" Only use the specified devices. The argument format\n"
" for PCI devices is <[domain:]bus:devid.func>.\n"
" This option can be present several times.\n"
" [NOTE: " OPT_DEV_ALLOW " cannot be used with "OPT_DEV_BLOCK" option]\n"
" --"OPT_VDEV" Add a virtual device.\n"
" The argument format is <driver><id>[,key=val,...]\n"
" (ex: --vdev=net_pcap0,iface=eth2).\n"

View File

@ -13,8 +13,12 @@ enum {
/* long options mapped to a short option */
#define OPT_HELP "help"
OPT_HELP_NUM = 'h',
#define OPT_PCI_BLACKLIST "pci-blacklist"
OPT_PCI_BLACKLIST_NUM = 'b',
#define OPT_DEV_ALLOW "allow"
OPT_DEV_ALLOW_NUM = 'a',
#define OPT_DEV_BLOCK "block"
OPT_DEV_BLOCK_NUM = 'b',
/* legacy option that will be removed in future */
#define OPT_PCI_WHITELIST "pci-whitelist"
OPT_PCI_WHITELIST_NUM = 'w',
@ -89,6 +93,11 @@ enum {
OPT_NO_TELEMETRY_NUM,
#define OPT_FORCE_MAX_SIMD_BITWIDTH "force-max-simd-bitwidth"
OPT_FORCE_MAX_SIMD_BITWIDTH_NUM,
/* legacy option that will be removed in future */
#define OPT_PCI_BLACKLIST "pci-blacklist"
OPT_PCI_BLACKLIST_NUM,
OPT_LONG_MAX_NUM
};