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:
parent
a65a34a85e
commit
db27370b57
@ -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 },
|
||||
|
@ -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);
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
||||
|
@ -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
|
||||
-----------------
|
||||
|
@ -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``:
|
||||
|
@ -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``:
|
||||
|
@ -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>``
|
||||
|
||||
|
@ -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).
|
||||
|
@ -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
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
@ -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
|
||||
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
-----------
|
||||
|
@ -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**
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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,
|
||||
|
@ -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::
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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::
|
||||
|
||||
|
@ -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::
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
-----------
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
~~~~~~~~~~~~~~
|
||||
|
@ -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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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``.
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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,
|
||||
|
||||
|
@ -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::
|
||||
|
@ -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>``
|
||||
|
||||
|
@ -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
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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
|
||||
|
@ -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)
|
||||
|
@ -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,
|
||||
|
@ -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)
|
||||
|
@ -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)
|
||||
|
@ -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"
|
||||
|
@ -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
|
||||
};
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user