* [dpdk-dev] [PATCH v10 4/7] doc: update documentation to reflect new options
@ 2020-11-10 22:55 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-11-10 22:55 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Replace old option syntax -w with -a and update any wording
around blacklisting.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 18 ++++++------
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 20 ++++++-------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 18 ++++++------
doc/guides/nics/mlx5.rst | 14 +++++-----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 22 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 8 +++---
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 4 +--
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 8 ++++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 3 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 178 insertions(+), 158 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 080768a2e766..83565d71752d 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index da14a68d9cff..bac82421bca2 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 566423948f79..cf16f0350303 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 242d283965f9..485a375c4f2c 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -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
-----------------
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 53f09a52dbb5..1272c1e72b7b 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index ab093c3f4df6..d9a7d8793092 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 3fa77d7458c0..f01cd65603f6 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -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:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index ae1642b15ec3..917482dbe2a5 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index c9deb53349ab..f98c31e4695e 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index c62448768376..163ae3f47b11 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index 27ff306b1a9b..ae9f08ec8d1d 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index a4b288abcf5f..43f74e02abf3 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 828a25988e34..ab0a6ee36e51 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -172,7 +172,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
@@ -185,7 +185,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
@@ -200,7 +200,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.
@@ -212,7 +212,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``)
@@ -222,7 +222,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -452,7 +452,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.
@@ -460,7 +460,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.
@@ -796,7 +796,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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 11c7420ed502..f03103704014 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -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,
@@ -41,7 +41,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -53,7 +53,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -62,8 +74,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 +86,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 +245,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::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index c408ab71385b..10660ce853b4 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -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 (o 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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 59b2bf4036b9..e96aca21eb9a 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -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::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index ecea3ecff074..e987f331048c 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index 18566a2c6665..a4f224424ef5 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index cc5b9f120c97..962e54389fbc 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index 6f9900883495..12d43ce93e28 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..1f30e13b8bf3 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..57fd7425a15d 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 6bbd6ee93922..5da3a9cd05c5 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -644,6 +644,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 7c5a45b72afb..b2af9a0755d6 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index b4fc587a09e2..41ee8b7ee3f4 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 1f37dccf8bb7..faf00c75d135 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -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
@@ -1023,4 +1023,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 7acbd7404e3b..e7875f8dcd7e 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -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.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4a96800ec648..eee5d8185061 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index d7e1dc581328..831f2bf58f99 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index a8bedbab5321..cb9c4f216986 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -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::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 29340d94e801..73cabf0098d3 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 018358ac1719..634009cceea9 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -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:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-08 14:19 0% ` Ananyev, Konstantin
@ 2020-11-10 16:26 0% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2020-11-10 16:26 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: Andrew Rybchenko, Morten Brørup, dev
On Sun, Nov 08, 2020 at 02:19:55PM +0000, Ananyev, Konstantin wrote:
>
>
> > >>
> > >>>>>>>>>>>>>>>>>> Hi Olivier,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> m->nb_seg must be reset on mbuf free
> > >>>> whatever
> > >>>>>> the
> > >>>>>>>> value
> > >>>>>>>>>> of m->next,
> > >>>>>>>>>>>>>>>>>>> because it can happen that m->nb_seg is
> > >> !=
> > >>>> 1.
> > >>>>>> For
> > >>>>>>>>>> instance in this
> > >>>>>>>>>>>>>>>>>>> case:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> m1 = rte_pktmbuf_alloc(mp);
> > >>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m1, 500);
> > >>>>>>>>>>>>>>>>>>> m2 = rte_pktmbuf_alloc(mp);
> > >>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m2, 500);
> > >>>>>>>>>>>>>>>>>>> rte_pktmbuf_chain(m1, m2);
> > >>>>>>>>>>>>>>>>>>> m0 = rte_pktmbuf_alloc(mp);
> > >>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m0, 500);
> > >>>>>>>>>>>>>>>>>>> rte_pktmbuf_chain(m0, m1);
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> As rte_pktmbuf_chain() does not reset
> > >>>> nb_seg in
> > >>>>>> the
> > >>>>>>>>>> initial m1
> > >>>>>>>>>>>>>>>>>>> segment (this is not required), after
> > >> this
> > >>>> code
> > >>>>>> the
> > >>>>>>>>>> mbuf chain
> > >>>>>>>>>>>>>>>>>>> have 3 segments:
> > >>>>>>>>>>>>>>>>>>> - m0: next=m1, nb_seg=3
> > >>>>>>>>>>>>>>>>>>> - m1: next=m2, nb_seg=2
> > >>>>>>>>>>>>>>>>>>> - m2: next=NULL, nb_seg=1
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Freeing this mbuf chain will not
> > >> restore
> > >>>>>> nb_seg=1
> > >>>>>>>> in
> > >>>>>>>>>> the second
> > >>>>>>>>>>>>>>>>>>> segment.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Hmm, not sure why is that?
> > >>>>>>>>>>>>>>>>>> You are talking about freeing m1, right?
> > >>>>>>>>>>>>>>>>>> rte_pktmbuf_prefree_seg(struct rte_mbuf
> > >> *m)
> > >>>>>>>>>>>>>>>>>> {
> > >>>>>>>>>>>>>>>>>> ...
> > >>>>>>>>>>>>>>>>>> if (m->next != NULL) {
> > >>>>>>>>>>>>>>>>>> m->next = NULL;
> > >>>>>>>>>>>>>>>>>> m->nb_segs = 1;
> > >>>>>>>>>>>>>>>>>> }
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> m1->next != NULL, so it will enter the
> > >> if()
> > >>>>>> block,
> > >>>>>>>>>>>>>>>>>> and will reset both next and nb_segs.
> > >>>>>>>>>>>>>>>>>> What I am missing here?
> > >>>>>>>>>>>>>>>>>> Thinking in more generic way, that
> > >> change:
> > >>>>>>>>>>>>>>>>>> - if (m->next != NULL) {
> > >>>>>>>>>>>>>>>>>> - m->next = NULL;
> > >>>>>>>>>>>>>>>>>> - m->nb_segs = 1;
> > >>>>>>>>>>>>>>>>>> - }
> > >>>>>>>>>>>>>>>>>> + m->next = NULL;
> > >>>>>>>>>>>>>>>>>> + m->nb_segs = 1;
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Ah, sorry. I oversimplified the example
> > >> and
> > >>>> now
> > >>>>>> it
> > >>>>>>>> does
> > >>>>>>>>>> not
> > >>>>>>>>>>>>>>>>> show the issue...
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> The full example also adds a split() to
> > >> break
> > >>>> the
> > >>>>>>>> mbuf
> > >>>>>>>>>> chain
> > >>>>>>>>>>>>>>>>> between m1 and m2. The kind of thing that
> > >>>> would
> > >>>>>> be
> > >>>>>>>> done
> > >>>>>>>>>> for
> > >>>>>>>>>>>>>>>>> software TCP segmentation.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If so, may be the right solution is to care
> > >>>> about
> > >>>>>>>> nb_segs
> > >>>>>>>>>>>>>>>> when next is set to NULL on split? Any
> > >> place
> > >>>> when
> > >>>>>> next
> > >>>>>>>> is
> > >>>>>>>>>> set
> > >>>>>>>>>>>>>>>> to NULL. Just to keep the optimization in a
> > >>>> more
> > >>>>>>>> generic
> > >>>>>>>>>> place.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> The problem with that approach is that there
> > >> are
> > >>>>>> already
> > >>>>>>>>>> several
> > >>>>>>>>>>>>>>> existing split() or trim() implementations in
> > >>>>>> different
> > >>>>>>>> DPDK-
> > >>>>>>>>>> based
> > >>>>>>>>>>>>>>> applications. For instance, we have some in
> > >>>>>> 6WINDGate. If
> > >>>>>>>> we
> > >>>>>>>>>> force
> > >>>>>>>>>>>>>>> applications to set nb_seg to 1 when
> > >> resetting
> > >>>> next,
> > >>>>>> it
> > >>>>>>>> has
> > >>>>>>>>>> to be
> > >>>>>>>>>>>>>>> documented because it is not straightforward.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I think it is better to go that way.
> > >>>>>>>>>>>>>> From my perspective it seems natural to reset
> > >>>> nb_seg at
> > >>>>>>>> same
> > >>>>>>>>>> time
> > >>>>>>>>>>>>>> we reset next, otherwise inconsistency will
> > >> occur.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> While it is not explicitly stated for nb_segs, to
> > >> me
> > >>>> it
> > >>>>>> was
> > >>>>>>>> clear
> > >>>>>>>>>> that
> > >>>>>>>>>>>>> nb_segs is only valid in the first segment, like
> > >> for
> > >>>> many
> > >>>>>>>> fields
> > >>>>>>>>>> (port,
> > >>>>>>>>>>>>> ol_flags, vlan, rss, ...).
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> If we say that nb_segs has to be valid in any
> > >>>> segments,
> > >>>>>> it
> > >>>>>>>> means
> > >>>>>>>>>> that
> > >>>>>>>>>>>>> chain() or split() will have to update it in all
> > >>>>>> segments,
> > >>>>>>>> which
> > >>>>>>>>>> is not
> > >>>>>>>>>>>>> efficient.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Why in all?
> > >>>>>>>>>>>> We can state that nb_segs on non-first segment
> > >> should
> > >>>>>> always
> > >>>>>>>> equal
> > >>>>>>>>>> 1.
> > >>>>>>>>>>>> As I understand in that case, both split() and
> > >> chain()
> > >>>> have
> > >>>>>> to
> > >>>>>>>>>> update nb_segs
> > >>>>>>>>>>>> only for head mbufs, rest ones will remain
> > >> untouched.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Well, anyway, I think it's strange to have a
> > >> constraint
> > >>>> on m-
> > >>>>>>>>> nb_segs
> > >>>>>>>>>> for
> > >>>>>>>>>>> non-first segment. We don't have that kind of
> > >> constraints
> > >>>> for
> > >>>>>>>> other
> > >>>>>>>>>> fields.
> > >>>>>>>>>>
> > >>>>>>>>>> True, we don't. But this is one of the fields we
> > >> consider
> > >>>>>> critical
> > >>>>>>>>>> for proper work of mbuf alloc/free mechanism.
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> I am not sure that requiring m->nb_segs == 1 on non-first
> > >>>>>> segments
> > >>>>>>>> will provide any benefits.
> > >>>>>>>>
> > >>>>>>>> It would make this patch unneeded.
> > >>>>>>>> So, for direct, non-segmented mbufs pktmbuf_free() will
> > >> remain
> > >>>>>> write-
> > >>>>>>>> free.
> > >>>>>>>
> > >>>>>>> I see. Then I agree with Konstantin that alternative
> > >> solutions
> > >>>> should
> > >>>>>> be considered.
> > >>>>>>>
> > >>>>>>> The benefit regarding free()'ing non-segmented mbufs - which
> > >> is a
> > >>>>>> very common operation - certainly outweighs the cost of
> > >> requiring
> > >>>>>> split()/chain() operations to set the new head mbuf's nb_segs =
> > >> 1.
> > >>>>>>>
> > >>>>>>> Nonetheless, the bug needs to be fixed somehow.
> > >>>>>>>
> > >>>>>>> If we can't come up with a better solution that doesn't break
> > >> the
> > >>>>>> ABI, we are forced to accept the patch.
> > >>>>>>>
> > >>>>>>> Unless the techboard accepts to break the ABI in order to
> > >> avoid
> > >>>> the
> > >>>>>> performance cost of this patch.
> > >>>>>>
> > >>>>>> Did someone notice a performance drop with this patch?
> > >>>>>> On my side, I don't see any regression on a L3 use case.
> > >>>>>
> > >>>>> I am afraid that the DPDK performance regression tests are based
> > >> on
> > >>>> TX immediately following RX, so cache misses in TX may go by
> > >> unnoticed
> > >>>> because RX warmed up the cache for TX already. And similarly for RX
> > >>>> reusing mbufs that have been warmed up by the preceding free() at
> > >> TX.
> > >>>>>
> > >>>>> Please consider testing the performance difference with the mbuf
> > >>>> being completely cold at TX, and going completely cold again before
> > >>>> being reused for RX.
> > >>>>>
> > >>>>>>
> > >>>>>> Let's sumarize: splitting a mbuf chain and freeing it causes
> > >>>> subsequent
> > >>>>>> mbuf
> > >>>>>> allocation to return a mbuf which is not correctly initialized.
> > >>>> There
> > >>>>>> are 2
> > >>>>>> options to fix it:
> > >>>>>>
> > >>>>>> 1/ change the mbuf free function (this patch)
> > >>>>>>
> > >>>>>> - m->nb_segs would behave like many other field: valid in
> > >> the
> > >>>> first
> > >>>>>> segment, ignored in other segments
> > >>>>>> - may impact performance (suspected)
> > >>>>>>
> > >>>>>> 2/ change all places where a mbuf chain is split, or trimmed
> > >>>>>>
> > >>>>>> - m->nb_segs would have a specific behavior: count the
> > >> number of
> > >>>>>> segments in the first mbuf, should be 1 in the last
> > >> segment,
> > >>>>>> ignored in other ones.
> > >>>>>> - no code change in mbuf library, so no performance impact
> > >>>>>> - need to patch all places where we do a mbuf split or trim.
> > >>>> From
> > >>>>>> afar,
> > >>>>>> I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> > >>>>>> applications
> > >>>>>> may have to be patched (for instance, I already found 3
> > >> places
> > >>>> in
> > >>>>>> 6WIND code base without a deep search).
> > >>>>>>
> > >>>>>> In my opinion, 1/ is better, except we notice a significant
> > >>>>>> performance,
> > >>>>>> because the (implicit) behavior is unchanged.
> > >>>>>>
> > >>>>>> Whatever the solution, some documentation has to be added.
> > >>>>>>
> > >>>>>> Olivier
> > >>>>>>
> > >>>>>
> > >>>>> Unfortunately, I don't think that anything but the first option
> > >> will
> > >>>> go into 20.11 and stable releases of older versions, so I stand by
> > >> my
> > >>>> acknowledgment of the patch.
> > >>>>
> > >>>> If we are affraid about 20.11 performance (it is legitimate, few
> > >> days
> > >>>> before the release), we can target 21.02. After all, everybody
> > >> lives
> > >>>> with this bug since 2017, so there is no urgency. If accepted and
> > >> well
> > >>>> tested, it can be backported in stable branches.
> > >>>
> > >>> +1
> > >>>
> > >>> Good thinking, Olivier!
> > >>
> > >> Looking at the changes once again, it probably can be reworked a bit:
> > >>
> > >> - if (m->next != NULL) {
> > >> - m->next = NULL;
> > >> - m->nb_segs = 1;
> > >> - }
> > >>
> > >> + if (m->next != NULL)
> > >> + m->next = NULL;
> > >> + if (m->nb_segs != 1)
> > >> + m->nb_segs = 1;
> > >>
> > >> That way we add one more condition checking, but I suppose it
> > >> shouldn't be that perf critical.
> > >> That way for direct,non-segmented mbuf it still should be write-free.
> > >> Except cases as you described above: chain(), then split().
> > >>
> > >> Of-course we still need to do perf testing for that approach too.
> > >> So if your preference it to postpone it till 21.02 - that's ok for me.
> > >> Konstantin
> > >
> > > With this suggestion, I cannot imagine any performance drop for direct, non-segmented mbufs: It now reads m->nb_segs, residing in the
> > mbuf's first cache line, but the function already reads m->refcnt in the first cache line; so no cache misses are introduced.
> >
> > +1
>
> I don't expect perf drop with that approach either.
> But some perf testing still needs to be done, just in case 😊
I also agree with your suggestion Konstantin.
Let's postpone it right after 20.11 so we have more time to test.
I'll send a v2.
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks
2020-11-10 13:54 4% ` Kinsella, Ray
@ 2020-11-10 13:57 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-11-10 13:57 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Walsh, Conor, dpdk-dev, Luca Boccassi, Dodji Seketeli, Mcnamara, John
On Tue, Nov 10, 2020 at 2:54 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
> > The Travis script flushes the ABI cache on a libabigail version change.
>
> Why would the libabigail version change in Travis - due do an OS update or the like?
Because in Travis, we compiled our own version of libabigail, the one
in ubuntu 18.04 being buggy (opened some bug, never got any feedback).
I had left automatic flush to test different versions.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks
2020-11-10 12:53 8% ` David Marchand
@ 2020-11-10 13:54 4% ` Kinsella, Ray
2020-11-10 13:57 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2020-11-10 13:54 UTC (permalink / raw)
To: David Marchand
Cc: Walsh, Conor, dpdk-dev, Luca Boccassi, Dodji Seketeli, Mcnamara, John
On 10/11/2020 12:53, David Marchand wrote:
> On Tue, Nov 3, 2020 at 11:07 AM Kinsella, Ray <mdr@ashroe.eu> wrote:
>> Came across an issue with this.
>>
>> Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail
>> is not guaranteed to be 100% compatible with a older versions.
>>
>> That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release,
>> or libabigail version depending on how you look at it.
>
> This is something I had encountered.
>
> The Travis script flushes the ABI cache on a libabigail version change.
Why would the libabigail version change in Travis - due do an OS update or the like?
> When using the test-meson-builds.sh integration, the gen-abi.sh
> devtools script can be called to regenerate the dump files from the
> existing local binaries.
>
>
>>
>> An alter approach suggested by Dodi would be to just archive the binaries somewhere instead,
>> and regenerate the dumps at build time. That _may_ be feasible,
>> but you lose some of the benefit (build time saving) compared to archiving the abi dumps.
>>
>> The most sensible approach to archiving the binaries.
>> is to use DPDK release os packaging for this, installed to a fs sandbox.
>>
>> So the next steps are figuring out, which is the better option between
>> maintaining multiple abi dump archives, one per supported os distro.
>> or looking at what needs to happen with DPDK os packaging.
>>
>> So some work still to do here.
>
> I am still unconvinced about the approach, but I'll wait for your next proposal.
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks
2020-11-03 10:07 9% ` [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks Kinsella, Ray
@ 2020-11-10 12:53 8% ` David Marchand
2020-11-10 13:54 4% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2020-11-10 12:53 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Walsh, Conor, dpdk-dev, Luca Boccassi, Dodji Seketeli, Mcnamara, John
On Tue, Nov 3, 2020 at 11:07 AM Kinsella, Ray <mdr@ashroe.eu> wrote:
> Came across an issue with this.
>
> Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail
> is not guaranteed to be 100% compatible with a older versions.
>
> That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release,
> or libabigail version depending on how you look at it.
This is something I had encountered.
The Travis script flushes the ABI cache on a libabigail version change.
When using the test-meson-builds.sh integration, the gen-abi.sh
devtools script can be called to regenerate the dump files from the
existing local binaries.
>
> An alter approach suggested by Dodi would be to just archive the binaries somewhere instead,
> and regenerate the dumps at build time. That _may_ be feasible,
> but you lose some of the benefit (build time saving) compared to archiving the abi dumps.
>
> The most sensible approach to archiving the binaries.
> is to use DPDK release os packaging for this, installed to a fs sandbox.
>
> So the next steps are figuring out, which is the better option between
> maintaining multiple abi dump archives, one per supported os distro.
> or looking at what needs to happen with DPDK os packaging.
>
> So some work still to do here.
I am still unconvinced about the approach, but I'll wait for your next proposal.
--
David Marchand
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-08 14:16 0% ` Andrew Rybchenko
@ 2020-11-08 14:19 0% ` Ananyev, Konstantin
2020-11-10 16:26 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2020-11-08 14:19 UTC (permalink / raw)
To: Andrew Rybchenko, Morten Brørup, Olivier Matz; +Cc: dev
> >>
> >>>>>>>>>>>>>>>>>> Hi Olivier,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> m->nb_seg must be reset on mbuf free
> >>>> whatever
> >>>>>> the
> >>>>>>>> value
> >>>>>>>>>> of m->next,
> >>>>>>>>>>>>>>>>>>> because it can happen that m->nb_seg is
> >> !=
> >>>> 1.
> >>>>>> For
> >>>>>>>>>> instance in this
> >>>>>>>>>>>>>>>>>>> case:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> m1 = rte_pktmbuf_alloc(mp);
> >>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m1, 500);
> >>>>>>>>>>>>>>>>>>> m2 = rte_pktmbuf_alloc(mp);
> >>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m2, 500);
> >>>>>>>>>>>>>>>>>>> rte_pktmbuf_chain(m1, m2);
> >>>>>>>>>>>>>>>>>>> m0 = rte_pktmbuf_alloc(mp);
> >>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m0, 500);
> >>>>>>>>>>>>>>>>>>> rte_pktmbuf_chain(m0, m1);
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> As rte_pktmbuf_chain() does not reset
> >>>> nb_seg in
> >>>>>> the
> >>>>>>>>>> initial m1
> >>>>>>>>>>>>>>>>>>> segment (this is not required), after
> >> this
> >>>> code
> >>>>>> the
> >>>>>>>>>> mbuf chain
> >>>>>>>>>>>>>>>>>>> have 3 segments:
> >>>>>>>>>>>>>>>>>>> - m0: next=m1, nb_seg=3
> >>>>>>>>>>>>>>>>>>> - m1: next=m2, nb_seg=2
> >>>>>>>>>>>>>>>>>>> - m2: next=NULL, nb_seg=1
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Freeing this mbuf chain will not
> >> restore
> >>>>>> nb_seg=1
> >>>>>>>> in
> >>>>>>>>>> the second
> >>>>>>>>>>>>>>>>>>> segment.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hmm, not sure why is that?
> >>>>>>>>>>>>>>>>>> You are talking about freeing m1, right?
> >>>>>>>>>>>>>>>>>> rte_pktmbuf_prefree_seg(struct rte_mbuf
> >> *m)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> ...
> >>>>>>>>>>>>>>>>>> if (m->next != NULL) {
> >>>>>>>>>>>>>>>>>> m->next = NULL;
> >>>>>>>>>>>>>>>>>> m->nb_segs = 1;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> m1->next != NULL, so it will enter the
> >> if()
> >>>>>> block,
> >>>>>>>>>>>>>>>>>> and will reset both next and nb_segs.
> >>>>>>>>>>>>>>>>>> What I am missing here?
> >>>>>>>>>>>>>>>>>> Thinking in more generic way, that
> >> change:
> >>>>>>>>>>>>>>>>>> - if (m->next != NULL) {
> >>>>>>>>>>>>>>>>>> - m->next = NULL;
> >>>>>>>>>>>>>>>>>> - m->nb_segs = 1;
> >>>>>>>>>>>>>>>>>> - }
> >>>>>>>>>>>>>>>>>> + m->next = NULL;
> >>>>>>>>>>>>>>>>>> + m->nb_segs = 1;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Ah, sorry. I oversimplified the example
> >> and
> >>>> now
> >>>>>> it
> >>>>>>>> does
> >>>>>>>>>> not
> >>>>>>>>>>>>>>>>> show the issue...
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The full example also adds a split() to
> >> break
> >>>> the
> >>>>>>>> mbuf
> >>>>>>>>>> chain
> >>>>>>>>>>>>>>>>> between m1 and m2. The kind of thing that
> >>>> would
> >>>>>> be
> >>>>>>>> done
> >>>>>>>>>> for
> >>>>>>>>>>>>>>>>> software TCP segmentation.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If so, may be the right solution is to care
> >>>> about
> >>>>>>>> nb_segs
> >>>>>>>>>>>>>>>> when next is set to NULL on split? Any
> >> place
> >>>> when
> >>>>>> next
> >>>>>>>> is
> >>>>>>>>>> set
> >>>>>>>>>>>>>>>> to NULL. Just to keep the optimization in a
> >>>> more
> >>>>>>>> generic
> >>>>>>>>>> place.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The problem with that approach is that there
> >> are
> >>>>>> already
> >>>>>>>>>> several
> >>>>>>>>>>>>>>> existing split() or trim() implementations in
> >>>>>> different
> >>>>>>>> DPDK-
> >>>>>>>>>> based
> >>>>>>>>>>>>>>> applications. For instance, we have some in
> >>>>>> 6WINDGate. If
> >>>>>>>> we
> >>>>>>>>>> force
> >>>>>>>>>>>>>>> applications to set nb_seg to 1 when
> >> resetting
> >>>> next,
> >>>>>> it
> >>>>>>>> has
> >>>>>>>>>> to be
> >>>>>>>>>>>>>>> documented because it is not straightforward.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I think it is better to go that way.
> >>>>>>>>>>>>>> From my perspective it seems natural to reset
> >>>> nb_seg at
> >>>>>>>> same
> >>>>>>>>>> time
> >>>>>>>>>>>>>> we reset next, otherwise inconsistency will
> >> occur.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> While it is not explicitly stated for nb_segs, to
> >> me
> >>>> it
> >>>>>> was
> >>>>>>>> clear
> >>>>>>>>>> that
> >>>>>>>>>>>>> nb_segs is only valid in the first segment, like
> >> for
> >>>> many
> >>>>>>>> fields
> >>>>>>>>>> (port,
> >>>>>>>>>>>>> ol_flags, vlan, rss, ...).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If we say that nb_segs has to be valid in any
> >>>> segments,
> >>>>>> it
> >>>>>>>> means
> >>>>>>>>>> that
> >>>>>>>>>>>>> chain() or split() will have to update it in all
> >>>>>> segments,
> >>>>>>>> which
> >>>>>>>>>> is not
> >>>>>>>>>>>>> efficient.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why in all?
> >>>>>>>>>>>> We can state that nb_segs on non-first segment
> >> should
> >>>>>> always
> >>>>>>>> equal
> >>>>>>>>>> 1.
> >>>>>>>>>>>> As I understand in that case, both split() and
> >> chain()
> >>>> have
> >>>>>> to
> >>>>>>>>>> update nb_segs
> >>>>>>>>>>>> only for head mbufs, rest ones will remain
> >> untouched.
> >>>>>>>>>>>
> >>>>>>>>>>> Well, anyway, I think it's strange to have a
> >> constraint
> >>>> on m-
> >>>>>>>>> nb_segs
> >>>>>>>>>> for
> >>>>>>>>>>> non-first segment. We don't have that kind of
> >> constraints
> >>>> for
> >>>>>>>> other
> >>>>>>>>>> fields.
> >>>>>>>>>>
> >>>>>>>>>> True, we don't. But this is one of the fields we
> >> consider
> >>>>>> critical
> >>>>>>>>>> for proper work of mbuf alloc/free mechanism.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I am not sure that requiring m->nb_segs == 1 on non-first
> >>>>>> segments
> >>>>>>>> will provide any benefits.
> >>>>>>>>
> >>>>>>>> It would make this patch unneeded.
> >>>>>>>> So, for direct, non-segmented mbufs pktmbuf_free() will
> >> remain
> >>>>>> write-
> >>>>>>>> free.
> >>>>>>>
> >>>>>>> I see. Then I agree with Konstantin that alternative
> >> solutions
> >>>> should
> >>>>>> be considered.
> >>>>>>>
> >>>>>>> The benefit regarding free()'ing non-segmented mbufs - which
> >> is a
> >>>>>> very common operation - certainly outweighs the cost of
> >> requiring
> >>>>>> split()/chain() operations to set the new head mbuf's nb_segs =
> >> 1.
> >>>>>>>
> >>>>>>> Nonetheless, the bug needs to be fixed somehow.
> >>>>>>>
> >>>>>>> If we can't come up with a better solution that doesn't break
> >> the
> >>>>>> ABI, we are forced to accept the patch.
> >>>>>>>
> >>>>>>> Unless the techboard accepts to break the ABI in order to
> >> avoid
> >>>> the
> >>>>>> performance cost of this patch.
> >>>>>>
> >>>>>> Did someone notice a performance drop with this patch?
> >>>>>> On my side, I don't see any regression on a L3 use case.
> >>>>>
> >>>>> I am afraid that the DPDK performance regression tests are based
> >> on
> >>>> TX immediately following RX, so cache misses in TX may go by
> >> unnoticed
> >>>> because RX warmed up the cache for TX already. And similarly for RX
> >>>> reusing mbufs that have been warmed up by the preceding free() at
> >> TX.
> >>>>>
> >>>>> Please consider testing the performance difference with the mbuf
> >>>> being completely cold at TX, and going completely cold again before
> >>>> being reused for RX.
> >>>>>
> >>>>>>
> >>>>>> Let's sumarize: splitting a mbuf chain and freeing it causes
> >>>> subsequent
> >>>>>> mbuf
> >>>>>> allocation to return a mbuf which is not correctly initialized.
> >>>> There
> >>>>>> are 2
> >>>>>> options to fix it:
> >>>>>>
> >>>>>> 1/ change the mbuf free function (this patch)
> >>>>>>
> >>>>>> - m->nb_segs would behave like many other field: valid in
> >> the
> >>>> first
> >>>>>> segment, ignored in other segments
> >>>>>> - may impact performance (suspected)
> >>>>>>
> >>>>>> 2/ change all places where a mbuf chain is split, or trimmed
> >>>>>>
> >>>>>> - m->nb_segs would have a specific behavior: count the
> >> number of
> >>>>>> segments in the first mbuf, should be 1 in the last
> >> segment,
> >>>>>> ignored in other ones.
> >>>>>> - no code change in mbuf library, so no performance impact
> >>>>>> - need to patch all places where we do a mbuf split or trim.
> >>>> From
> >>>>>> afar,
> >>>>>> I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> >>>>>> applications
> >>>>>> may have to be patched (for instance, I already found 3
> >> places
> >>>> in
> >>>>>> 6WIND code base without a deep search).
> >>>>>>
> >>>>>> In my opinion, 1/ is better, except we notice a significant
> >>>>>> performance,
> >>>>>> because the (implicit) behavior is unchanged.
> >>>>>>
> >>>>>> Whatever the solution, some documentation has to be added.
> >>>>>>
> >>>>>> Olivier
> >>>>>>
> >>>>>
> >>>>> Unfortunately, I don't think that anything but the first option
> >> will
> >>>> go into 20.11 and stable releases of older versions, so I stand by
> >> my
> >>>> acknowledgment of the patch.
> >>>>
> >>>> If we are affraid about 20.11 performance (it is legitimate, few
> >> days
> >>>> before the release), we can target 21.02. After all, everybody
> >> lives
> >>>> with this bug since 2017, so there is no urgency. If accepted and
> >> well
> >>>> tested, it can be backported in stable branches.
> >>>
> >>> +1
> >>>
> >>> Good thinking, Olivier!
> >>
> >> Looking at the changes once again, it probably can be reworked a bit:
> >>
> >> - if (m->next != NULL) {
> >> - m->next = NULL;
> >> - m->nb_segs = 1;
> >> - }
> >>
> >> + if (m->next != NULL)
> >> + m->next = NULL;
> >> + if (m->nb_segs != 1)
> >> + m->nb_segs = 1;
> >>
> >> That way we add one more condition checking, but I suppose it
> >> shouldn't be that perf critical.
> >> That way for direct,non-segmented mbuf it still should be write-free.
> >> Except cases as you described above: chain(), then split().
> >>
> >> Of-course we still need to do perf testing for that approach too.
> >> So if your preference it to postpone it till 21.02 - that's ok for me.
> >> Konstantin
> >
> > With this suggestion, I cannot imagine any performance drop for direct, non-segmented mbufs: It now reads m->nb_segs, residing in the
> mbuf's first cache line, but the function already reads m->refcnt in the first cache line; so no cache misses are introduced.
>
> +1
I don't expect perf drop with that approach either.
But some perf testing still needs to be done, just in case 😊
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 12:23 0% ` Morten Brørup
@ 2020-11-08 14:16 0% ` Andrew Rybchenko
2020-11-08 14:19 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2020-11-08 14:16 UTC (permalink / raw)
To: Morten Brørup, Ananyev, Konstantin, Olivier Matz; +Cc: dev
On 11/6/20 3:23 PM, Morten Brørup wrote:
>> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
>> Sent: Friday, November 6, 2020 12:54 PM
>>
>>>>>>>>>>>>>>>>>> Hi Olivier,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> m->nb_seg must be reset on mbuf free
>>>> whatever
>>>>>> the
>>>>>>>> value
>>>>>>>>>> of m->next,
>>>>>>>>>>>>>>>>>>> because it can happen that m->nb_seg is
>> !=
>>>> 1.
>>>>>> For
>>>>>>>>>> instance in this
>>>>>>>>>>>>>>>>>>> case:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> m1 = rte_pktmbuf_alloc(mp);
>>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m1, 500);
>>>>>>>>>>>>>>>>>>> m2 = rte_pktmbuf_alloc(mp);
>>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m2, 500);
>>>>>>>>>>>>>>>>>>> rte_pktmbuf_chain(m1, m2);
>>>>>>>>>>>>>>>>>>> m0 = rte_pktmbuf_alloc(mp);
>>>>>>>>>>>>>>>>>>> rte_pktmbuf_append(m0, 500);
>>>>>>>>>>>>>>>>>>> rte_pktmbuf_chain(m0, m1);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As rte_pktmbuf_chain() does not reset
>>>> nb_seg in
>>>>>> the
>>>>>>>>>> initial m1
>>>>>>>>>>>>>>>>>>> segment (this is not required), after
>> this
>>>> code
>>>>>> the
>>>>>>>>>> mbuf chain
>>>>>>>>>>>>>>>>>>> have 3 segments:
>>>>>>>>>>>>>>>>>>> - m0: next=m1, nb_seg=3
>>>>>>>>>>>>>>>>>>> - m1: next=m2, nb_seg=2
>>>>>>>>>>>>>>>>>>> - m2: next=NULL, nb_seg=1
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Freeing this mbuf chain will not
>> restore
>>>>>> nb_seg=1
>>>>>>>> in
>>>>>>>>>> the second
>>>>>>>>>>>>>>>>>>> segment.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hmm, not sure why is that?
>>>>>>>>>>>>>>>>>> You are talking about freeing m1, right?
>>>>>>>>>>>>>>>>>> rte_pktmbuf_prefree_seg(struct rte_mbuf
>> *m)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>> if (m->next != NULL) {
>>>>>>>>>>>>>>>>>> m->next = NULL;
>>>>>>>>>>>>>>>>>> m->nb_segs = 1;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> m1->next != NULL, so it will enter the
>> if()
>>>>>> block,
>>>>>>>>>>>>>>>>>> and will reset both next and nb_segs.
>>>>>>>>>>>>>>>>>> What I am missing here?
>>>>>>>>>>>>>>>>>> Thinking in more generic way, that
>> change:
>>>>>>>>>>>>>>>>>> - if (m->next != NULL) {
>>>>>>>>>>>>>>>>>> - m->next = NULL;
>>>>>>>>>>>>>>>>>> - m->nb_segs = 1;
>>>>>>>>>>>>>>>>>> - }
>>>>>>>>>>>>>>>>>> + m->next = NULL;
>>>>>>>>>>>>>>>>>> + m->nb_segs = 1;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ah, sorry. I oversimplified the example
>> and
>>>> now
>>>>>> it
>>>>>>>> does
>>>>>>>>>> not
>>>>>>>>>>>>>>>>> show the issue...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The full example also adds a split() to
>> break
>>>> the
>>>>>>>> mbuf
>>>>>>>>>> chain
>>>>>>>>>>>>>>>>> between m1 and m2. The kind of thing that
>>>> would
>>>>>> be
>>>>>>>> done
>>>>>>>>>> for
>>>>>>>>>>>>>>>>> software TCP segmentation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If so, may be the right solution is to care
>>>> about
>>>>>>>> nb_segs
>>>>>>>>>>>>>>>> when next is set to NULL on split? Any
>> place
>>>> when
>>>>>> next
>>>>>>>> is
>>>>>>>>>> set
>>>>>>>>>>>>>>>> to NULL. Just to keep the optimization in a
>>>> more
>>>>>>>> generic
>>>>>>>>>> place.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem with that approach is that there
>> are
>>>>>> already
>>>>>>>>>> several
>>>>>>>>>>>>>>> existing split() or trim() implementations in
>>>>>> different
>>>>>>>> DPDK-
>>>>>>>>>> based
>>>>>>>>>>>>>>> applications. For instance, we have some in
>>>>>> 6WINDGate. If
>>>>>>>> we
>>>>>>>>>> force
>>>>>>>>>>>>>>> applications to set nb_seg to 1 when
>> resetting
>>>> next,
>>>>>> it
>>>>>>>> has
>>>>>>>>>> to be
>>>>>>>>>>>>>>> documented because it is not straightforward.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think it is better to go that way.
>>>>>>>>>>>>>> From my perspective it seems natural to reset
>>>> nb_seg at
>>>>>>>> same
>>>>>>>>>> time
>>>>>>>>>>>>>> we reset next, otherwise inconsistency will
>> occur.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While it is not explicitly stated for nb_segs, to
>> me
>>>> it
>>>>>> was
>>>>>>>> clear
>>>>>>>>>> that
>>>>>>>>>>>>> nb_segs is only valid in the first segment, like
>> for
>>>> many
>>>>>>>> fields
>>>>>>>>>> (port,
>>>>>>>>>>>>> ol_flags, vlan, rss, ...).
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we say that nb_segs has to be valid in any
>>>> segments,
>>>>>> it
>>>>>>>> means
>>>>>>>>>> that
>>>>>>>>>>>>> chain() or split() will have to update it in all
>>>>>> segments,
>>>>>>>> which
>>>>>>>>>> is not
>>>>>>>>>>>>> efficient.
>>>>>>>>>>>>
>>>>>>>>>>>> Why in all?
>>>>>>>>>>>> We can state that nb_segs on non-first segment
>> should
>>>>>> always
>>>>>>>> equal
>>>>>>>>>> 1.
>>>>>>>>>>>> As I understand in that case, both split() and
>> chain()
>>>> have
>>>>>> to
>>>>>>>>>> update nb_segs
>>>>>>>>>>>> only for head mbufs, rest ones will remain
>> untouched.
>>>>>>>>>>>
>>>>>>>>>>> Well, anyway, I think it's strange to have a
>> constraint
>>>> on m-
>>>>>>>>> nb_segs
>>>>>>>>>> for
>>>>>>>>>>> non-first segment. We don't have that kind of
>> constraints
>>>> for
>>>>>>>> other
>>>>>>>>>> fields.
>>>>>>>>>>
>>>>>>>>>> True, we don't. But this is one of the fields we
>> consider
>>>>>> critical
>>>>>>>>>> for proper work of mbuf alloc/free mechanism.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am not sure that requiring m->nb_segs == 1 on non-first
>>>>>> segments
>>>>>>>> will provide any benefits.
>>>>>>>>
>>>>>>>> It would make this patch unneeded.
>>>>>>>> So, for direct, non-segmented mbufs pktmbuf_free() will
>> remain
>>>>>> write-
>>>>>>>> free.
>>>>>>>
>>>>>>> I see. Then I agree with Konstantin that alternative
>> solutions
>>>> should
>>>>>> be considered.
>>>>>>>
>>>>>>> The benefit regarding free()'ing non-segmented mbufs - which
>> is a
>>>>>> very common operation - certainly outweighs the cost of
>> requiring
>>>>>> split()/chain() operations to set the new head mbuf's nb_segs =
>> 1.
>>>>>>>
>>>>>>> Nonetheless, the bug needs to be fixed somehow.
>>>>>>>
>>>>>>> If we can't come up with a better solution that doesn't break
>> the
>>>>>> ABI, we are forced to accept the patch.
>>>>>>>
>>>>>>> Unless the techboard accepts to break the ABI in order to
>> avoid
>>>> the
>>>>>> performance cost of this patch.
>>>>>>
>>>>>> Did someone notice a performance drop with this patch?
>>>>>> On my side, I don't see any regression on a L3 use case.
>>>>>
>>>>> I am afraid that the DPDK performance regression tests are based
>> on
>>>> TX immediately following RX, so cache misses in TX may go by
>> unnoticed
>>>> because RX warmed up the cache for TX already. And similarly for RX
>>>> reusing mbufs that have been warmed up by the preceding free() at
>> TX.
>>>>>
>>>>> Please consider testing the performance difference with the mbuf
>>>> being completely cold at TX, and going completely cold again before
>>>> being reused for RX.
>>>>>
>>>>>>
>>>>>> Let's sumarize: splitting a mbuf chain and freeing it causes
>>>> subsequent
>>>>>> mbuf
>>>>>> allocation to return a mbuf which is not correctly initialized.
>>>> There
>>>>>> are 2
>>>>>> options to fix it:
>>>>>>
>>>>>> 1/ change the mbuf free function (this patch)
>>>>>>
>>>>>> - m->nb_segs would behave like many other field: valid in
>> the
>>>> first
>>>>>> segment, ignored in other segments
>>>>>> - may impact performance (suspected)
>>>>>>
>>>>>> 2/ change all places where a mbuf chain is split, or trimmed
>>>>>>
>>>>>> - m->nb_segs would have a specific behavior: count the
>> number of
>>>>>> segments in the first mbuf, should be 1 in the last
>> segment,
>>>>>> ignored in other ones.
>>>>>> - no code change in mbuf library, so no performance impact
>>>>>> - need to patch all places where we do a mbuf split or trim.
>>>> From
>>>>>> afar,
>>>>>> I see at least mbuf_cut_seg_ofs() in DPDK. Some external
>>>>>> applications
>>>>>> may have to be patched (for instance, I already found 3
>> places
>>>> in
>>>>>> 6WIND code base without a deep search).
>>>>>>
>>>>>> In my opinion, 1/ is better, except we notice a significant
>>>>>> performance,
>>>>>> because the (implicit) behavior is unchanged.
>>>>>>
>>>>>> Whatever the solution, some documentation has to be added.
>>>>>>
>>>>>> Olivier
>>>>>>
>>>>>
>>>>> Unfortunately, I don't think that anything but the first option
>> will
>>>> go into 20.11 and stable releases of older versions, so I stand by
>> my
>>>> acknowledgment of the patch.
>>>>
>>>> If we are affraid about 20.11 performance (it is legitimate, few
>> days
>>>> before the release), we can target 21.02. After all, everybody
>> lives
>>>> with this bug since 2017, so there is no urgency. If accepted and
>> well
>>>> tested, it can be backported in stable branches.
>>>
>>> +1
>>>
>>> Good thinking, Olivier!
>>
>> Looking at the changes once again, it probably can be reworked a bit:
>>
>> - if (m->next != NULL) {
>> - m->next = NULL;
>> - m->nb_segs = 1;
>> - }
>>
>> + if (m->next != NULL)
>> + m->next = NULL;
>> + if (m->nb_segs != 1)
>> + m->nb_segs = 1;
>>
>> That way we add one more condition checking, but I suppose it
>> shouldn't be that perf critical.
>> That way for direct,non-segmented mbuf it still should be write-free.
>> Except cases as you described above: chain(), then split().
>>
>> Of-course we still need to do perf testing for that approach too.
>> So if your preference it to postpone it till 21.02 - that's ok for me.
>> Konstantin
>
> With this suggestion, I cannot imagine any performance drop for direct, non-segmented mbufs: It now reads m->nb_segs, residing in the mbuf's first cache line, but the function already reads m->refcnt in the first cache line; so no cache misses are introduced.
+1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 11:53 0% ` Ananyev, Konstantin
@ 2020-11-06 12:23 0% ` Morten Brørup
2020-11-08 14:16 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-06 12:23 UTC (permalink / raw)
To: Ananyev, Konstantin, Olivier Matz; +Cc: Andrew Rybchenko, dev
> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> Sent: Friday, November 6, 2020 12:54 PM
>
> > > > > > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free
> > > whatever
> > > > > the
> > > > > > > value
> > > > > > > > > of m->next,
> > > > > > > > > > > > > > > >>> because it can happen that m->nb_seg is
> !=
> > > 1.
> > > > > For
> > > > > > > > > instance in this
> > > > > > > > > > > > > > > >>> case:
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> As rte_pktmbuf_chain() does not reset
> > > nb_seg in
> > > > > the
> > > > > > > > > initial m1
> > > > > > > > > > > > > > > >>> segment (this is not required), after
> this
> > > code
> > > > > the
> > > > > > > > > mbuf chain
> > > > > > > > > > > > > > > >>> have 3 segments:
> > > > > > > > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> Freeing this mbuf chain will not
> restore
> > > > > nb_seg=1
> > > > > > > in
> > > > > > > > > the second
> > > > > > > > > > > > > > > >>> segment.
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf
> *m)
> > > > > > > > > > > > > > > >> {
> > > > > > > > > > > > > > > >> ...
> > > > > > > > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > > > > > > > >> m->next = NULL;
> > > > > > > > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > > > > > > > >> }
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> m1->next != NULL, so it will enter the
> if()
> > > > > block,
> > > > > > > > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > > > > > > > >> What I am missing here?
> > > > > > > > > > > > > > > >> Thinking in more generic way, that
> change:
> > > > > > > > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > > > > > > > >> - m->next = NULL;
> > > > > > > > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > > > > > > > >> - }
> > > > > > > > > > > > > > > >> + m->next = NULL;
> > > > > > > > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Ah, sorry. I oversimplified the example
> and
> > > now
> > > > > it
> > > > > > > does
> > > > > > > > > not
> > > > > > > > > > > > > > > > show the issue...
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The full example also adds a split() to
> break
> > > the
> > > > > > > mbuf
> > > > > > > > > chain
> > > > > > > > > > > > > > > > between m1 and m2. The kind of thing that
> > > would
> > > > > be
> > > > > > > done
> > > > > > > > > for
> > > > > > > > > > > > > > > > software TCP segmentation.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If so, may be the right solution is to care
> > > about
> > > > > > > nb_segs
> > > > > > > > > > > > > > > when next is set to NULL on split? Any
> place
> > > when
> > > > > next
> > > > > > > is
> > > > > > > > > set
> > > > > > > > > > > > > > > to NULL. Just to keep the optimization in a
> > > more
> > > > > > > generic
> > > > > > > > > place.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > The problem with that approach is that there
> are
> > > > > already
> > > > > > > > > several
> > > > > > > > > > > > > > existing split() or trim() implementations in
> > > > > different
> > > > > > > DPDK-
> > > > > > > > > based
> > > > > > > > > > > > > > applications. For instance, we have some in
> > > > > 6WINDGate. If
> > > > > > > we
> > > > > > > > > force
> > > > > > > > > > > > > > applications to set nb_seg to 1 when
> resetting
> > > next,
> > > > > it
> > > > > > > has
> > > > > > > > > to be
> > > > > > > > > > > > > > documented because it is not straightforward.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think it is better to go that way.
> > > > > > > > > > > > > From my perspective it seems natural to reset
> > > nb_seg at
> > > > > > > same
> > > > > > > > > time
> > > > > > > > > > > > > we reset next, otherwise inconsistency will
> occur.
> > > > > > > > > > > >
> > > > > > > > > > > > While it is not explicitly stated for nb_segs, to
> me
> > > it
> > > > > was
> > > > > > > clear
> > > > > > > > > that
> > > > > > > > > > > > nb_segs is only valid in the first segment, like
> for
> > > many
> > > > > > > fields
> > > > > > > > > (port,
> > > > > > > > > > > > ol_flags, vlan, rss, ...).
> > > > > > > > > > > >
> > > > > > > > > > > > If we say that nb_segs has to be valid in any
> > > segments,
> > > > > it
> > > > > > > means
> > > > > > > > > that
> > > > > > > > > > > > chain() or split() will have to update it in all
> > > > > segments,
> > > > > > > which
> > > > > > > > > is not
> > > > > > > > > > > > efficient.
> > > > > > > > > > >
> > > > > > > > > > > Why in all?
> > > > > > > > > > > We can state that nb_segs on non-first segment
> should
> > > > > always
> > > > > > > equal
> > > > > > > > > 1.
> > > > > > > > > > > As I understand in that case, both split() and
> chain()
> > > have
> > > > > to
> > > > > > > > > update nb_segs
> > > > > > > > > > > only for head mbufs, rest ones will remain
> untouched.
> > > > > > > > > >
> > > > > > > > > > Well, anyway, I think it's strange to have a
> constraint
> > > on m-
> > > > > > > >nb_segs
> > > > > > > > > for
> > > > > > > > > > non-first segment. We don't have that kind of
> constraints
> > > for
> > > > > > > other
> > > > > > > > > fields.
> > > > > > > > >
> > > > > > > > > True, we don't. But this is one of the fields we
> consider
> > > > > critical
> > > > > > > > > for proper work of mbuf alloc/free mechanism.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I am not sure that requiring m->nb_segs == 1 on non-first
> > > > > segments
> > > > > > > will provide any benefits.
> > > > > > >
> > > > > > > It would make this patch unneeded.
> > > > > > > So, for direct, non-segmented mbufs pktmbuf_free() will
> remain
> > > > > write-
> > > > > > > free.
> > > > > >
> > > > > > I see. Then I agree with Konstantin that alternative
> solutions
> > > should
> > > > > be considered.
> > > > > >
> > > > > > The benefit regarding free()'ing non-segmented mbufs - which
> is a
> > > > > very common operation - certainly outweighs the cost of
> requiring
> > > > > split()/chain() operations to set the new head mbuf's nb_segs =
> 1.
> > > > > >
> > > > > > Nonetheless, the bug needs to be fixed somehow.
> > > > > >
> > > > > > If we can't come up with a better solution that doesn't break
> the
> > > > > ABI, we are forced to accept the patch.
> > > > > >
> > > > > > Unless the techboard accepts to break the ABI in order to
> avoid
> > > the
> > > > > performance cost of this patch.
> > > > >
> > > > > Did someone notice a performance drop with this patch?
> > > > > On my side, I don't see any regression on a L3 use case.
> > > >
> > > > I am afraid that the DPDK performance regression tests are based
> on
> > > TX immediately following RX, so cache misses in TX may go by
> unnoticed
> > > because RX warmed up the cache for TX already. And similarly for RX
> > > reusing mbufs that have been warmed up by the preceding free() at
> TX.
> > > >
> > > > Please consider testing the performance difference with the mbuf
> > > being completely cold at TX, and going completely cold again before
> > > being reused for RX.
> > > >
> > > > >
> > > > > Let's sumarize: splitting a mbuf chain and freeing it causes
> > > subsequent
> > > > > mbuf
> > > > > allocation to return a mbuf which is not correctly initialized.
> > > There
> > > > > are 2
> > > > > options to fix it:
> > > > >
> > > > > 1/ change the mbuf free function (this patch)
> > > > >
> > > > > - m->nb_segs would behave like many other field: valid in
> the
> > > first
> > > > > segment, ignored in other segments
> > > > > - may impact performance (suspected)
> > > > >
> > > > > 2/ change all places where a mbuf chain is split, or trimmed
> > > > >
> > > > > - m->nb_segs would have a specific behavior: count the
> number of
> > > > > segments in the first mbuf, should be 1 in the last
> segment,
> > > > > ignored in other ones.
> > > > > - no code change in mbuf library, so no performance impact
> > > > > - need to patch all places where we do a mbuf split or trim.
> > > From
> > > > > afar,
> > > > > I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> > > > > applications
> > > > > may have to be patched (for instance, I already found 3
> places
> > > in
> > > > > 6WIND code base without a deep search).
> > > > >
> > > > > In my opinion, 1/ is better, except we notice a significant
> > > > > performance,
> > > > > because the (implicit) behavior is unchanged.
> > > > >
> > > > > Whatever the solution, some documentation has to be added.
> > > > >
> > > > > Olivier
> > > > >
> > > >
> > > > Unfortunately, I don't think that anything but the first option
> will
> > > go into 20.11 and stable releases of older versions, so I stand by
> my
> > > acknowledgment of the patch.
> > >
> > > If we are affraid about 20.11 performance (it is legitimate, few
> days
> > > before the release), we can target 21.02. After all, everybody
> lives
> > > with this bug since 2017, so there is no urgency. If accepted and
> well
> > > tested, it can be backported in stable branches.
> >
> > +1
> >
> > Good thinking, Olivier!
>
> Looking at the changes once again, it probably can be reworked a bit:
>
> - if (m->next != NULL) {
> - m->next = NULL;
> - m->nb_segs = 1;
> - }
>
> + if (m->next != NULL)
> + m->next = NULL;
> + if (m->nb_segs != 1)
> + m->nb_segs = 1;
>
> That way we add one more condition checking, but I suppose it
> shouldn't be that perf critical.
> That way for direct,non-segmented mbuf it still should be write-free.
> Except cases as you described above: chain(), then split().
>
> Of-course we still need to do perf testing for that approach too.
> So if your preference it to postpone it till 21.02 - that's ok for me.
> Konstantin
With this suggestion, I cannot imagine any performance drop for direct, non-segmented mbufs: It now reads m->nb_segs, residing in the mbuf's first cache line, but the function already reads m->refcnt in the first cache line; so no cache misses are introduced.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 10:07 0% ` Morten Brørup
@ 2020-11-06 11:53 0% ` Ananyev, Konstantin
2020-11-06 12:23 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2020-11-06 11:53 UTC (permalink / raw)
To: Morten Brørup, Olivier Matz; +Cc: Andrew Rybchenko, dev
> > > > > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free
> > whatever
> > > > the
> > > > > > value
> > > > > > > > of m->next,
> > > > > > > > > > > > > > >>> because it can happen that m->nb_seg is !=
> > 1.
> > > > For
> > > > > > > > instance in this
> > > > > > > > > > > > > > >>> case:
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> As rte_pktmbuf_chain() does not reset
> > nb_seg in
> > > > the
> > > > > > > > initial m1
> > > > > > > > > > > > > > >>> segment (this is not required), after this
> > code
> > > > the
> > > > > > > > mbuf chain
> > > > > > > > > > > > > > >>> have 3 segments:
> > > > > > > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> Freeing this mbuf chain will not restore
> > > > nb_seg=1
> > > > > > in
> > > > > > > > the second
> > > > > > > > > > > > > > >>> segment.
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > > > > > > > > > > > > >> {
> > > > > > > > > > > > > > >> ...
> > > > > > > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > > > > > > >> m->next = NULL;
> > > > > > > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > > > > > > >> }
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> m1->next != NULL, so it will enter the if()
> > > > block,
> > > > > > > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > > > > > > >> What I am missing here?
> > > > > > > > > > > > > > >> Thinking in more generic way, that change:
> > > > > > > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > > > > > > >> - m->next = NULL;
> > > > > > > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > > > > > > >> - }
> > > > > > > > > > > > > > >> + m->next = NULL;
> > > > > > > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Ah, sorry. I oversimplified the example and
> > now
> > > > it
> > > > > > does
> > > > > > > > not
> > > > > > > > > > > > > > > show the issue...
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The full example also adds a split() to break
> > the
> > > > > > mbuf
> > > > > > > > chain
> > > > > > > > > > > > > > > between m1 and m2. The kind of thing that
> > would
> > > > be
> > > > > > done
> > > > > > > > for
> > > > > > > > > > > > > > > software TCP segmentation.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If so, may be the right solution is to care
> > about
> > > > > > nb_segs
> > > > > > > > > > > > > > when next is set to NULL on split? Any place
> > when
> > > > next
> > > > > > is
> > > > > > > > set
> > > > > > > > > > > > > > to NULL. Just to keep the optimization in a
> > more
> > > > > > generic
> > > > > > > > place.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > The problem with that approach is that there are
> > > > already
> > > > > > > > several
> > > > > > > > > > > > > existing split() or trim() implementations in
> > > > different
> > > > > > DPDK-
> > > > > > > > based
> > > > > > > > > > > > > applications. For instance, we have some in
> > > > 6WINDGate. If
> > > > > > we
> > > > > > > > force
> > > > > > > > > > > > > applications to set nb_seg to 1 when resetting
> > next,
> > > > it
> > > > > > has
> > > > > > > > to be
> > > > > > > > > > > > > documented because it is not straightforward.
> > > > > > > > > > > >
> > > > > > > > > > > > I think it is better to go that way.
> > > > > > > > > > > > From my perspective it seems natural to reset
> > nb_seg at
> > > > > > same
> > > > > > > > time
> > > > > > > > > > > > we reset next, otherwise inconsistency will occur.
> > > > > > > > > > >
> > > > > > > > > > > While it is not explicitly stated for nb_segs, to me
> > it
> > > > was
> > > > > > clear
> > > > > > > > that
> > > > > > > > > > > nb_segs is only valid in the first segment, like for
> > many
> > > > > > fields
> > > > > > > > (port,
> > > > > > > > > > > ol_flags, vlan, rss, ...).
> > > > > > > > > > >
> > > > > > > > > > > If we say that nb_segs has to be valid in any
> > segments,
> > > > it
> > > > > > means
> > > > > > > > that
> > > > > > > > > > > chain() or split() will have to update it in all
> > > > segments,
> > > > > > which
> > > > > > > > is not
> > > > > > > > > > > efficient.
> > > > > > > > > >
> > > > > > > > > > Why in all?
> > > > > > > > > > We can state that nb_segs on non-first segment should
> > > > always
> > > > > > equal
> > > > > > > > 1.
> > > > > > > > > > As I understand in that case, both split() and chain()
> > have
> > > > to
> > > > > > > > update nb_segs
> > > > > > > > > > only for head mbufs, rest ones will remain untouched.
> > > > > > > > >
> > > > > > > > > Well, anyway, I think it's strange to have a constraint
> > on m-
> > > > > > >nb_segs
> > > > > > > > for
> > > > > > > > > non-first segment. We don't have that kind of constraints
> > for
> > > > > > other
> > > > > > > > fields.
> > > > > > > >
> > > > > > > > True, we don't. But this is one of the fields we consider
> > > > critical
> > > > > > > > for proper work of mbuf alloc/free mechanism.
> > > > > > > >
> > > > > > >
> > > > > > > I am not sure that requiring m->nb_segs == 1 on non-first
> > > > segments
> > > > > > will provide any benefits.
> > > > > >
> > > > > > It would make this patch unneeded.
> > > > > > So, for direct, non-segmented mbufs pktmbuf_free() will remain
> > > > write-
> > > > > > free.
> > > > >
> > > > > I see. Then I agree with Konstantin that alternative solutions
> > should
> > > > be considered.
> > > > >
> > > > > The benefit regarding free()'ing non-segmented mbufs - which is a
> > > > very common operation - certainly outweighs the cost of requiring
> > > > split()/chain() operations to set the new head mbuf's nb_segs = 1.
> > > > >
> > > > > Nonetheless, the bug needs to be fixed somehow.
> > > > >
> > > > > If we can't come up with a better solution that doesn't break the
> > > > ABI, we are forced to accept the patch.
> > > > >
> > > > > Unless the techboard accepts to break the ABI in order to avoid
> > the
> > > > performance cost of this patch.
> > > >
> > > > Did someone notice a performance drop with this patch?
> > > > On my side, I don't see any regression on a L3 use case.
> > >
> > > I am afraid that the DPDK performance regression tests are based on
> > TX immediately following RX, so cache misses in TX may go by unnoticed
> > because RX warmed up the cache for TX already. And similarly for RX
> > reusing mbufs that have been warmed up by the preceding free() at TX.
> > >
> > > Please consider testing the performance difference with the mbuf
> > being completely cold at TX, and going completely cold again before
> > being reused for RX.
> > >
> > > >
> > > > Let's sumarize: splitting a mbuf chain and freeing it causes
> > subsequent
> > > > mbuf
> > > > allocation to return a mbuf which is not correctly initialized.
> > There
> > > > are 2
> > > > options to fix it:
> > > >
> > > > 1/ change the mbuf free function (this patch)
> > > >
> > > > - m->nb_segs would behave like many other field: valid in the
> > first
> > > > segment, ignored in other segments
> > > > - may impact performance (suspected)
> > > >
> > > > 2/ change all places where a mbuf chain is split, or trimmed
> > > >
> > > > - m->nb_segs would have a specific behavior: count the number of
> > > > segments in the first mbuf, should be 1 in the last segment,
> > > > ignored in other ones.
> > > > - no code change in mbuf library, so no performance impact
> > > > - need to patch all places where we do a mbuf split or trim.
> > From
> > > > afar,
> > > > I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> > > > applications
> > > > may have to be patched (for instance, I already found 3 places
> > in
> > > > 6WIND code base without a deep search).
> > > >
> > > > In my opinion, 1/ is better, except we notice a significant
> > > > performance,
> > > > because the (implicit) behavior is unchanged.
> > > >
> > > > Whatever the solution, some documentation has to be added.
> > > >
> > > > Olivier
> > > >
> > >
> > > Unfortunately, I don't think that anything but the first option will
> > go into 20.11 and stable releases of older versions, so I stand by my
> > acknowledgment of the patch.
> >
> > If we are affraid about 20.11 performance (it is legitimate, few days
> > before the release), we can target 21.02. After all, everybody lives
> > with this bug since 2017, so there is no urgency. If accepted and well
> > tested, it can be backported in stable branches.
>
> +1
>
> Good thinking, Olivier!
Looking at the changes once again, it probably can be reworked a bit:
- if (m->next != NULL) {
- m->next = NULL;
- m->nb_segs = 1;
- }
+ if (m->next != NULL)
+ m->next = NULL;
+ if (m->nb_segs != 1)
+ m->nb_segs = 1;
That way we add one more condition checking, but I suppose it
shouldn't be that perf critical.
That way for direct,non-segmented mbuf it still should be write-free.
Except cases as you described above: chain(), then split().
Of-course we still need to do perf testing for that approach too.
So if your preference it to postpone it till 21.02 - that's ok for me.
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 10:04 0% ` Olivier Matz
@ 2020-11-06 10:07 0% ` Morten Brørup
2020-11-06 11:53 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-06 10:07 UTC (permalink / raw)
To: Olivier Matz; +Cc: Ananyev, Konstantin, Andrew Rybchenko, dev
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Friday, November 6, 2020 11:05 AM
>
> On Fri, Nov 06, 2020 at 09:50:45AM +0100, Morten Brørup wrote:
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Friday, November 6, 2020 9:21 AM
> > >
> > > On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > > > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> > > > > Sent: Friday, November 6, 2020 12:55 AM
> > > > >
> > > > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free
> whatever
> > > the
> > > > > value
> > > > > > > of m->next,
> > > > > > > > > > > > > >>> because it can happen that m->nb_seg is !=
> 1.
> > > For
> > > > > > > instance in this
> > > > > > > > > > > > > >>> case:
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> As rte_pktmbuf_chain() does not reset
> nb_seg in
> > > the
> > > > > > > initial m1
> > > > > > > > > > > > > >>> segment (this is not required), after this
> code
> > > the
> > > > > > > mbuf chain
> > > > > > > > > > > > > >>> have 3 segments:
> > > > > > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> Freeing this mbuf chain will not restore
> > > nb_seg=1
> > > > > in
> > > > > > > the second
> > > > > > > > > > > > > >>> segment.
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > > > > > > > > > > > >> {
> > > > > > > > > > > > > >> ...
> > > > > > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > > > > > >> m->next = NULL;
> > > > > > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > > > > > >> }
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> m1->next != NULL, so it will enter the if()
> > > block,
> > > > > > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > > > > > >> What I am missing here?
> > > > > > > > > > > > > >> Thinking in more generic way, that change:
> > > > > > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > > > > > >> - m->next = NULL;
> > > > > > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > > > > > >> - }
> > > > > > > > > > > > > >> + m->next = NULL;
> > > > > > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Ah, sorry. I oversimplified the example and
> now
> > > it
> > > > > does
> > > > > > > not
> > > > > > > > > > > > > > show the issue...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The full example also adds a split() to break
> the
> > > > > mbuf
> > > > > > > chain
> > > > > > > > > > > > > > between m1 and m2. The kind of thing that
> would
> > > be
> > > > > done
> > > > > > > for
> > > > > > > > > > > > > > software TCP segmentation.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > If so, may be the right solution is to care
> about
> > > > > nb_segs
> > > > > > > > > > > > > when next is set to NULL on split? Any place
> when
> > > next
> > > > > is
> > > > > > > set
> > > > > > > > > > > > > to NULL. Just to keep the optimization in a
> more
> > > > > generic
> > > > > > > place.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > The problem with that approach is that there are
> > > already
> > > > > > > several
> > > > > > > > > > > > existing split() or trim() implementations in
> > > different
> > > > > DPDK-
> > > > > > > based
> > > > > > > > > > > > applications. For instance, we have some in
> > > 6WINDGate. If
> > > > > we
> > > > > > > force
> > > > > > > > > > > > applications to set nb_seg to 1 when resetting
> next,
> > > it
> > > > > has
> > > > > > > to be
> > > > > > > > > > > > documented because it is not straightforward.
> > > > > > > > > > >
> > > > > > > > > > > I think it is better to go that way.
> > > > > > > > > > > From my perspective it seems natural to reset
> nb_seg at
> > > > > same
> > > > > > > time
> > > > > > > > > > > we reset next, otherwise inconsistency will occur.
> > > > > > > > > >
> > > > > > > > > > While it is not explicitly stated for nb_segs, to me
> it
> > > was
> > > > > clear
> > > > > > > that
> > > > > > > > > > nb_segs is only valid in the first segment, like for
> many
> > > > > fields
> > > > > > > (port,
> > > > > > > > > > ol_flags, vlan, rss, ...).
> > > > > > > > > >
> > > > > > > > > > If we say that nb_segs has to be valid in any
> segments,
> > > it
> > > > > means
> > > > > > > that
> > > > > > > > > > chain() or split() will have to update it in all
> > > segments,
> > > > > which
> > > > > > > is not
> > > > > > > > > > efficient.
> > > > > > > > >
> > > > > > > > > Why in all?
> > > > > > > > > We can state that nb_segs on non-first segment should
> > > always
> > > > > equal
> > > > > > > 1.
> > > > > > > > > As I understand in that case, both split() and chain()
> have
> > > to
> > > > > > > update nb_segs
> > > > > > > > > only for head mbufs, rest ones will remain untouched.
> > > > > > > >
> > > > > > > > Well, anyway, I think it's strange to have a constraint
> on m-
> > > > > >nb_segs
> > > > > > > for
> > > > > > > > non-first segment. We don't have that kind of constraints
> for
> > > > > other
> > > > > > > fields.
> > > > > > >
> > > > > > > True, we don't. But this is one of the fields we consider
> > > critical
> > > > > > > for proper work of mbuf alloc/free mechanism.
> > > > > > >
> > > > > >
> > > > > > I am not sure that requiring m->nb_segs == 1 on non-first
> > > segments
> > > > > will provide any benefits.
> > > > >
> > > > > It would make this patch unneeded.
> > > > > So, for direct, non-segmented mbufs pktmbuf_free() will remain
> > > write-
> > > > > free.
> > > >
> > > > I see. Then I agree with Konstantin that alternative solutions
> should
> > > be considered.
> > > >
> > > > The benefit regarding free()'ing non-segmented mbufs - which is a
> > > very common operation - certainly outweighs the cost of requiring
> > > split()/chain() operations to set the new head mbuf's nb_segs = 1.
> > > >
> > > > Nonetheless, the bug needs to be fixed somehow.
> > > >
> > > > If we can't come up with a better solution that doesn't break the
> > > ABI, we are forced to accept the patch.
> > > >
> > > > Unless the techboard accepts to break the ABI in order to avoid
> the
> > > performance cost of this patch.
> > >
> > > Did someone notice a performance drop with this patch?
> > > On my side, I don't see any regression on a L3 use case.
> >
> > I am afraid that the DPDK performance regression tests are based on
> TX immediately following RX, so cache misses in TX may go by unnoticed
> because RX warmed up the cache for TX already. And similarly for RX
> reusing mbufs that have been warmed up by the preceding free() at TX.
> >
> > Please consider testing the performance difference with the mbuf
> being completely cold at TX, and going completely cold again before
> being reused for RX.
> >
> > >
> > > Let's sumarize: splitting a mbuf chain and freeing it causes
> subsequent
> > > mbuf
> > > allocation to return a mbuf which is not correctly initialized.
> There
> > > are 2
> > > options to fix it:
> > >
> > > 1/ change the mbuf free function (this patch)
> > >
> > > - m->nb_segs would behave like many other field: valid in the
> first
> > > segment, ignored in other segments
> > > - may impact performance (suspected)
> > >
> > > 2/ change all places where a mbuf chain is split, or trimmed
> > >
> > > - m->nb_segs would have a specific behavior: count the number of
> > > segments in the first mbuf, should be 1 in the last segment,
> > > ignored in other ones.
> > > - no code change in mbuf library, so no performance impact
> > > - need to patch all places where we do a mbuf split or trim.
> From
> > > afar,
> > > I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> > > applications
> > > may have to be patched (for instance, I already found 3 places
> in
> > > 6WIND code base without a deep search).
> > >
> > > In my opinion, 1/ is better, except we notice a significant
> > > performance,
> > > because the (implicit) behavior is unchanged.
> > >
> > > Whatever the solution, some documentation has to be added.
> > >
> > > Olivier
> > >
> >
> > Unfortunately, I don't think that anything but the first option will
> go into 20.11 and stable releases of older versions, so I stand by my
> acknowledgment of the patch.
>
> If we are affraid about 20.11 performance (it is legitimate, few days
> before the release), we can target 21.02. After all, everybody lives
> with this bug since 2017, so there is no urgency. If accepted and well
> tested, it can be backported in stable branches.
+1
Good thinking, Olivier!
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 8:50 0% ` Morten Brørup
@ 2020-11-06 10:04 0% ` Olivier Matz
2020-11-06 10:07 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2020-11-06 10:04 UTC (permalink / raw)
To: Morten Brørup; +Cc: Ananyev, Konstantin, Andrew Rybchenko, dev
On Fri, Nov 06, 2020 at 09:50:45AM +0100, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Friday, November 6, 2020 9:21 AM
> >
> > On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> > > > Sent: Friday, November 6, 2020 12:55 AM
> > > >
> > > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free whatever
> > the
> > > > value
> > > > > > of m->next,
> > > > > > > > > > > > >>> because it can happen that m->nb_seg is != 1.
> > For
> > > > > > instance in this
> > > > > > > > > > > > >>> case:
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> As rte_pktmbuf_chain() does not reset nb_seg in
> > the
> > > > > > initial m1
> > > > > > > > > > > > >>> segment (this is not required), after this code
> > the
> > > > > > mbuf chain
> > > > > > > > > > > > >>> have 3 segments:
> > > > > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> Freeing this mbuf chain will not restore
> > nb_seg=1
> > > > in
> > > > > > the second
> > > > > > > > > > > > >>> segment.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > > > > > > > > > > >> {
> > > > > > > > > > > > >> ...
> > > > > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > > > > >> m->next = NULL;
> > > > > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > > > > >> }
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> m1->next != NULL, so it will enter the if()
> > block,
> > > > > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > > > > >> What I am missing here?
> > > > > > > > > > > > >> Thinking in more generic way, that change:
> > > > > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > > > > >> - m->next = NULL;
> > > > > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > > > > >> - }
> > > > > > > > > > > > >> + m->next = NULL;
> > > > > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > > > > >
> > > > > > > > > > > > > Ah, sorry. I oversimplified the example and now
> > it
> > > > does
> > > > > > not
> > > > > > > > > > > > > show the issue...
> > > > > > > > > > > > >
> > > > > > > > > > > > > The full example also adds a split() to break the
> > > > mbuf
> > > > > > chain
> > > > > > > > > > > > > between m1 and m2. The kind of thing that would
> > be
> > > > done
> > > > > > for
> > > > > > > > > > > > > software TCP segmentation.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > If so, may be the right solution is to care about
> > > > nb_segs
> > > > > > > > > > > > when next is set to NULL on split? Any place when
> > next
> > > > is
> > > > > > set
> > > > > > > > > > > > to NULL. Just to keep the optimization in a more
> > > > generic
> > > > > > place.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > The problem with that approach is that there are
> > already
> > > > > > several
> > > > > > > > > > > existing split() or trim() implementations in
> > different
> > > > DPDK-
> > > > > > based
> > > > > > > > > > > applications. For instance, we have some in
> > 6WINDGate. If
> > > > we
> > > > > > force
> > > > > > > > > > > applications to set nb_seg to 1 when resetting next,
> > it
> > > > has
> > > > > > to be
> > > > > > > > > > > documented because it is not straightforward.
> > > > > > > > > >
> > > > > > > > > > I think it is better to go that way.
> > > > > > > > > > From my perspective it seems natural to reset nb_seg at
> > > > same
> > > > > > time
> > > > > > > > > > we reset next, otherwise inconsistency will occur.
> > > > > > > > >
> > > > > > > > > While it is not explicitly stated for nb_segs, to me it
> > was
> > > > clear
> > > > > > that
> > > > > > > > > nb_segs is only valid in the first segment, like for many
> > > > fields
> > > > > > (port,
> > > > > > > > > ol_flags, vlan, rss, ...).
> > > > > > > > >
> > > > > > > > > If we say that nb_segs has to be valid in any segments,
> > it
> > > > means
> > > > > > that
> > > > > > > > > chain() or split() will have to update it in all
> > segments,
> > > > which
> > > > > > is not
> > > > > > > > > efficient.
> > > > > > > >
> > > > > > > > Why in all?
> > > > > > > > We can state that nb_segs on non-first segment should
> > always
> > > > equal
> > > > > > 1.
> > > > > > > > As I understand in that case, both split() and chain() have
> > to
> > > > > > update nb_segs
> > > > > > > > only for head mbufs, rest ones will remain untouched.
> > > > > > >
> > > > > > > Well, anyway, I think it's strange to have a constraint on m-
> > > > >nb_segs
> > > > > > for
> > > > > > > non-first segment. We don't have that kind of constraints for
> > > > other
> > > > > > fields.
> > > > > >
> > > > > > True, we don't. But this is one of the fields we consider
> > critical
> > > > > > for proper work of mbuf alloc/free mechanism.
> > > > > >
> > > > >
> > > > > I am not sure that requiring m->nb_segs == 1 on non-first
> > segments
> > > > will provide any benefits.
> > > >
> > > > It would make this patch unneeded.
> > > > So, for direct, non-segmented mbufs pktmbuf_free() will remain
> > write-
> > > > free.
> > >
> > > I see. Then I agree with Konstantin that alternative solutions should
> > be considered.
> > >
> > > The benefit regarding free()'ing non-segmented mbufs - which is a
> > very common operation - certainly outweighs the cost of requiring
> > split()/chain() operations to set the new head mbuf's nb_segs = 1.
> > >
> > > Nonetheless, the bug needs to be fixed somehow.
> > >
> > > If we can't come up with a better solution that doesn't break the
> > ABI, we are forced to accept the patch.
> > >
> > > Unless the techboard accepts to break the ABI in order to avoid the
> > performance cost of this patch.
> >
> > Did someone notice a performance drop with this patch?
> > On my side, I don't see any regression on a L3 use case.
>
> I am afraid that the DPDK performance regression tests are based on TX immediately following RX, so cache misses in TX may go by unnoticed because RX warmed up the cache for TX already. And similarly for RX reusing mbufs that have been warmed up by the preceding free() at TX.
>
> Please consider testing the performance difference with the mbuf being completely cold at TX, and going completely cold again before being reused for RX.
>
> >
> > Let's sumarize: splitting a mbuf chain and freeing it causes subsequent
> > mbuf
> > allocation to return a mbuf which is not correctly initialized. There
> > are 2
> > options to fix it:
> >
> > 1/ change the mbuf free function (this patch)
> >
> > - m->nb_segs would behave like many other field: valid in the first
> > segment, ignored in other segments
> > - may impact performance (suspected)
> >
> > 2/ change all places where a mbuf chain is split, or trimmed
> >
> > - m->nb_segs would have a specific behavior: count the number of
> > segments in the first mbuf, should be 1 in the last segment,
> > ignored in other ones.
> > - no code change in mbuf library, so no performance impact
> > - need to patch all places where we do a mbuf split or trim. From
> > afar,
> > I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> > applications
> > may have to be patched (for instance, I already found 3 places in
> > 6WIND code base without a deep search).
> >
> > In my opinion, 1/ is better, except we notice a significant
> > performance,
> > because the (implicit) behavior is unchanged.
> >
> > Whatever the solution, some documentation has to be added.
> >
> > Olivier
> >
>
> Unfortunately, I don't think that anything but the first option will go into 20.11 and stable releases of older versions, so I stand by my acknowledgment of the patch.
If we are affraid about 20.11 performance (it is legitimate, few days
before the release), we can target 21.02. After all, everybody lives
with this bug since 2017, so there is no urgency. If accepted and well
tested, it can be backported in stable branches.
> Which reminds me: Consider reporting the bug in Bugzilla.
>
> >
> > >
> > > >
> > > > >
> > > > > E.g. the second segment of a three-segment chain will still have
> > m-
> > > > >next != NULL, so it cannot be used as a gate to prevent accessing
> > m-
> > > > > >next.
> > > > >
> > > > > I might have overlooked something, though.
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Saying that nb_segs has to be valid for the first and
> > last
> > > > > > segment seems
> > > > > > > > > really odd to me. What is the logic behind that except
> > > > keeping
> > > > > > this test
> > > > > > > > > as is?
> > > > > > > > >
> > > > > > > > > In any case, it has to be better documented.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Olivier
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > I think the approach from
> > > > > > > > > > > this patch is safer.
> > > > > > > > > >
> > > > > > > > > > It might be easier from perspective that changes in
> > less
> > > > places
> > > > > > are required,
> > > > > > > > > > Though I think that this patch will introduce some
> > > > performance
> > > > > > drop.
> > > > > > > > > > As now each mbuf_prefree_seg() will cause update of 2
> > cache
> > > > > > lines unconditionally.
> > > > > > > > > >
> > > > > > > > > > > By the way, for 21.11, if we are able to do some
> > > > > > optimizations and have
> > > > > > > > > > > both pool (index?) and next in the first cache line,
> > we
> > > > may
> > > > > > reconsider
> > > > > > > > > > > the fact that next and nb_segs are already set for
> > new
> > > > > > allocated mbufs,
> > > > > > > > > > > because it is not straightforward either.
> > > > > > > > > >
> > > > > > > > > > My suggestion - let's put future optimization
> > discussion
> > > > aside
> > > > > > for now,
> > > > > > > > > > and concentrate on that particular patch.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > After this operation, we have 2 mbuf chain:
> > > > > > > > > > > > > - m0 with 2 segments, the last one has next=NULL
> > but
> > > > > > nb_seg=2
> > > > > > > > > > > > > - new_m with 1 segment
> > > > > > > > > > > > >
> > > > > > > > > > > > > Freeing m0 will not restore nb_seg=1 in the
> > second
> > > > > > segment.
> > > > > > > > > > > > >
> > > > > > > > > > > > >> Assumes that it is ok to have an mbuf with
> > > > > > > > > > > > >> nb_seg > 1 and next == NULL.
> > > > > > > > > > > > >> Which seems wrong to me.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I don't think it is wrong: nb_seg is just ignored
> > > > when
> > > > > > not in the first
> > > > > > > > > > > > > segment, and there is nothing saying it should be
> > set
> > > > to
> > > > > > 1. Typically,
> > > > > > > > > > > > > rte_pktmbuf_chain() does not change it, and I
> > guess
> > > > it's
> > > > > > the same for
> > > > > > > > > > > > > many similar functions in applications.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Olivier
> > > > > > > > > > > > >
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> This is expected that mbufs stored in pool have
> > > > their
> > > > > > > > > > > > >>> nb_seg field set to 1.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields
> > while
> > > > in
> > > > > > pool")
> > > > > > > > > > > > >>> Cc: stable@dpdk.org
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> Signed-off-by: Olivier Matz
> > > > <olivier.matz@6wind.com>
> > > > > > > > > > > > >>> ---
> > > > > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.c | 6 ++----
> > > > > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.h | 12 ++++--------
> > > > > > > > > > > > >>> 2 files changed, 6 insertions(+), 12
> > deletions(-)
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.c
> > > > > > b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > > > >>> index 8a456e5e64..e632071c23 100644
> > > > > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > > > >>> @@ -129,10 +129,8 @@
> > > > > > rte_pktmbuf_free_pinned_extmem(void *addr, void *opaque)
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> rte_mbuf_ext_refcnt_set(m->shinfo, 1);
> > > > > > > > > > > > >>> m->ol_flags = EXT_ATTACHED_MBUF;
> > > > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > > > >>> - }
> > > > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > > > >>> rte_mbuf_raw_free(m);
> > > > > > > > > > > > >>> }
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.h
> > > > > > b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > > > >>> index a1414ed7cd..ef5800c8ef 100644
> > > > > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > > > >>> @@ -1329,10 +1329,8 @@
> > > > rte_pktmbuf_prefree_seg(struct
> > > > > > rte_mbuf *m)
> > > > > > > > > > > > >>> return NULL;
> > > > > > > > > > > > >>> }
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > > > >>> - }
> > > > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> return m;
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> @@ -1346,10 +1344,8 @@
> > > > rte_pktmbuf_prefree_seg(struct
> > > > > > rte_mbuf *m)
> > > > > > > > > > > > >>> return NULL;
> > > > > > > > > > > > >>> }
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > > > >>> - }
> > > > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > > > >>> rte_mbuf_refcnt_set(m, 1);
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> return m;
> > > > > > > > > > > > >>> --
> > > > > > > > > > > > >>> 2.25.1
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > >
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 8:20 0% ` Olivier Matz
@ 2020-11-06 8:50 0% ` Morten Brørup
2020-11-06 10:04 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-06 8:50 UTC (permalink / raw)
To: Olivier Matz; +Cc: Ananyev, Konstantin, Andrew Rybchenko, dev
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Friday, November 6, 2020 9:21 AM
>
> On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> > > Sent: Friday, November 6, 2020 12:55 AM
> > >
> > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > >>
> > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free whatever
> the
> > > value
> > > > > of m->next,
> > > > > > > > > > > >>> because it can happen that m->nb_seg is != 1.
> For
> > > > > instance in this
> > > > > > > > > > > >>> case:
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> As rte_pktmbuf_chain() does not reset nb_seg in
> the
> > > > > initial m1
> > > > > > > > > > > >>> segment (this is not required), after this code
> the
> > > > > mbuf chain
> > > > > > > > > > > >>> have 3 segments:
> > > > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> Freeing this mbuf chain will not restore
> nb_seg=1
> > > in
> > > > > the second
> > > > > > > > > > > >>> segment.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > > > > > > > > > >> {
> > > > > > > > > > > >> ...
> > > > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > > > >> m->next = NULL;
> > > > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > > > >> }
> > > > > > > > > > > >>
> > > > > > > > > > > >> m1->next != NULL, so it will enter the if()
> block,
> > > > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > > > >> What I am missing here?
> > > > > > > > > > > >> Thinking in more generic way, that change:
> > > > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > > > >> - m->next = NULL;
> > > > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > > > >> - }
> > > > > > > > > > > >> + m->next = NULL;
> > > > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > > > >
> > > > > > > > > > > > Ah, sorry. I oversimplified the example and now
> it
> > > does
> > > > > not
> > > > > > > > > > > > show the issue...
> > > > > > > > > > > >
> > > > > > > > > > > > The full example also adds a split() to break the
> > > mbuf
> > > > > chain
> > > > > > > > > > > > between m1 and m2. The kind of thing that would
> be
> > > done
> > > > > for
> > > > > > > > > > > > software TCP segmentation.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > If so, may be the right solution is to care about
> > > nb_segs
> > > > > > > > > > > when next is set to NULL on split? Any place when
> next
> > > is
> > > > > set
> > > > > > > > > > > to NULL. Just to keep the optimization in a more
> > > generic
> > > > > place.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > The problem with that approach is that there are
> already
> > > > > several
> > > > > > > > > > existing split() or trim() implementations in
> different
> > > DPDK-
> > > > > based
> > > > > > > > > > applications. For instance, we have some in
> 6WINDGate. If
> > > we
> > > > > force
> > > > > > > > > > applications to set nb_seg to 1 when resetting next,
> it
> > > has
> > > > > to be
> > > > > > > > > > documented because it is not straightforward.
> > > > > > > > >
> > > > > > > > > I think it is better to go that way.
> > > > > > > > > From my perspective it seems natural to reset nb_seg at
> > > same
> > > > > time
> > > > > > > > > we reset next, otherwise inconsistency will occur.
> > > > > > > >
> > > > > > > > While it is not explicitly stated for nb_segs, to me it
> was
> > > clear
> > > > > that
> > > > > > > > nb_segs is only valid in the first segment, like for many
> > > fields
> > > > > (port,
> > > > > > > > ol_flags, vlan, rss, ...).
> > > > > > > >
> > > > > > > > If we say that nb_segs has to be valid in any segments,
> it
> > > means
> > > > > that
> > > > > > > > chain() or split() will have to update it in all
> segments,
> > > which
> > > > > is not
> > > > > > > > efficient.
> > > > > > >
> > > > > > > Why in all?
> > > > > > > We can state that nb_segs on non-first segment should
> always
> > > equal
> > > > > 1.
> > > > > > > As I understand in that case, both split() and chain() have
> to
> > > > > update nb_segs
> > > > > > > only for head mbufs, rest ones will remain untouched.
> > > > > >
> > > > > > Well, anyway, I think it's strange to have a constraint on m-
> > > >nb_segs
> > > > > for
> > > > > > non-first segment. We don't have that kind of constraints for
> > > other
> > > > > fields.
> > > > >
> > > > > True, we don't. But this is one of the fields we consider
> critical
> > > > > for proper work of mbuf alloc/free mechanism.
> > > > >
> > > >
> > > > I am not sure that requiring m->nb_segs == 1 on non-first
> segments
> > > will provide any benefits.
> > >
> > > It would make this patch unneeded.
> > > So, for direct, non-segmented mbufs pktmbuf_free() will remain
> write-
> > > free.
> >
> > I see. Then I agree with Konstantin that alternative solutions should
> be considered.
> >
> > The benefit regarding free()'ing non-segmented mbufs - which is a
> very common operation - certainly outweighs the cost of requiring
> split()/chain() operations to set the new head mbuf's nb_segs = 1.
> >
> > Nonetheless, the bug needs to be fixed somehow.
> >
> > If we can't come up with a better solution that doesn't break the
> ABI, we are forced to accept the patch.
> >
> > Unless the techboard accepts to break the ABI in order to avoid the
> performance cost of this patch.
>
> Did someone notice a performance drop with this patch?
> On my side, I don't see any regression on a L3 use case.
I am afraid that the DPDK performance regression tests are based on TX immediately following RX, so cache misses in TX may go by unnoticed because RX warmed up the cache for TX already. And similarly for RX reusing mbufs that have been warmed up by the preceding free() at TX.
Please consider testing the performance difference with the mbuf being completely cold at TX, and going completely cold again before being reused for RX.
>
> Let's sumarize: splitting a mbuf chain and freeing it causes subsequent
> mbuf
> allocation to return a mbuf which is not correctly initialized. There
> are 2
> options to fix it:
>
> 1/ change the mbuf free function (this patch)
>
> - m->nb_segs would behave like many other field: valid in the first
> segment, ignored in other segments
> - may impact performance (suspected)
>
> 2/ change all places where a mbuf chain is split, or trimmed
>
> - m->nb_segs would have a specific behavior: count the number of
> segments in the first mbuf, should be 1 in the last segment,
> ignored in other ones.
> - no code change in mbuf library, so no performance impact
> - need to patch all places where we do a mbuf split or trim. From
> afar,
> I see at least mbuf_cut_seg_ofs() in DPDK. Some external
> applications
> may have to be patched (for instance, I already found 3 places in
> 6WIND code base without a deep search).
>
> In my opinion, 1/ is better, except we notice a significant
> performance,
> because the (implicit) behavior is unchanged.
>
> Whatever the solution, some documentation has to be added.
>
> Olivier
>
Unfortunately, I don't think that anything but the first option will go into 20.11 and stable releases of older versions, so I stand by my acknowledgment of the patch.
Which reminds me: Consider reporting the bug in Bugzilla.
>
> >
> > >
> > > >
> > > > E.g. the second segment of a three-segment chain will still have
> m-
> > > >next != NULL, so it cannot be used as a gate to prevent accessing
> m-
> > > > >next.
> > > >
> > > > I might have overlooked something, though.
> > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Saying that nb_segs has to be valid for the first and
> last
> > > > > segment seems
> > > > > > > > really odd to me. What is the logic behind that except
> > > keeping
> > > > > this test
> > > > > > > > as is?
> > > > > > > >
> > > > > > > > In any case, it has to be better documented.
> > > > > > > >
> > > > > > > >
> > > > > > > > Olivier
> > > > > > > >
> > > > > > > >
> > > > > > > > > > I think the approach from
> > > > > > > > > > this patch is safer.
> > > > > > > > >
> > > > > > > > > It might be easier from perspective that changes in
> less
> > > places
> > > > > are required,
> > > > > > > > > Though I think that this patch will introduce some
> > > performance
> > > > > drop.
> > > > > > > > > As now each mbuf_prefree_seg() will cause update of 2
> cache
> > > > > lines unconditionally.
> > > > > > > > >
> > > > > > > > > > By the way, for 21.11, if we are able to do some
> > > > > optimizations and have
> > > > > > > > > > both pool (index?) and next in the first cache line,
> we
> > > may
> > > > > reconsider
> > > > > > > > > > the fact that next and nb_segs are already set for
> new
> > > > > allocated mbufs,
> > > > > > > > > > because it is not straightforward either.
> > > > > > > > >
> > > > > > > > > My suggestion - let's put future optimization
> discussion
> > > aside
> > > > > for now,
> > > > > > > > > and concentrate on that particular patch.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > After this operation, we have 2 mbuf chain:
> > > > > > > > > > > > - m0 with 2 segments, the last one has next=NULL
> but
> > > > > nb_seg=2
> > > > > > > > > > > > - new_m with 1 segment
> > > > > > > > > > > >
> > > > > > > > > > > > Freeing m0 will not restore nb_seg=1 in the
> second
> > > > > segment.
> > > > > > > > > > > >
> > > > > > > > > > > >> Assumes that it is ok to have an mbuf with
> > > > > > > > > > > >> nb_seg > 1 and next == NULL.
> > > > > > > > > > > >> Which seems wrong to me.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think it is wrong: nb_seg is just ignored
> > > when
> > > > > not in the first
> > > > > > > > > > > > segment, and there is nothing saying it should be
> set
> > > to
> > > > > 1. Typically,
> > > > > > > > > > > > rte_pktmbuf_chain() does not change it, and I
> guess
> > > it's
> > > > > the same for
> > > > > > > > > > > > many similar functions in applications.
> > > > > > > > > > > >
> > > > > > > > > > > > Olivier
> > > > > > > > > > > >
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >>> This is expected that mbufs stored in pool have
> > > their
> > > > > > > > > > > >>> nb_seg field set to 1.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields
> while
> > > in
> > > > > pool")
> > > > > > > > > > > >>> Cc: stable@dpdk.org
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> Signed-off-by: Olivier Matz
> > > <olivier.matz@6wind.com>
> > > > > > > > > > > >>> ---
> > > > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.c | 6 ++----
> > > > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.h | 12 ++++--------
> > > > > > > > > > > >>> 2 files changed, 6 insertions(+), 12
> deletions(-)
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.c
> > > > > b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > > >>> index 8a456e5e64..e632071c23 100644
> > > > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > > >>> @@ -129,10 +129,8 @@
> > > > > rte_pktmbuf_free_pinned_extmem(void *addr, void *opaque)
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> rte_mbuf_ext_refcnt_set(m->shinfo, 1);
> > > > > > > > > > > >>> m->ol_flags = EXT_ATTACHED_MBUF;
> > > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > > >>> - }
> > > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > > >>> rte_mbuf_raw_free(m);
> > > > > > > > > > > >>> }
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.h
> > > > > b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > > >>> index a1414ed7cd..ef5800c8ef 100644
> > > > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > > >>> @@ -1329,10 +1329,8 @@
> > > rte_pktmbuf_prefree_seg(struct
> > > > > rte_mbuf *m)
> > > > > > > > > > > >>> return NULL;
> > > > > > > > > > > >>> }
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > > >>> - }
> > > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> return m;
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> @@ -1346,10 +1344,8 @@
> > > rte_pktmbuf_prefree_seg(struct
> > > > > rte_mbuf *m)
> > > > > > > > > > > >>> return NULL;
> > > > > > > > > > > >>> }
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > > >>> - }
> > > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > > >>> rte_mbuf_refcnt_set(m, 1);
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> return m;
> > > > > > > > > > > >>> --
> > > > > > > > > > > >>> 2.25.1
> > > > > > > > > > > >>
> > > > > > > > > > >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
2020-11-06 7:52 4% ` Morten Brørup
@ 2020-11-06 8:20 0% ` Olivier Matz
2020-11-06 8:50 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2020-11-06 8:20 UTC (permalink / raw)
To: Morten Brørup; +Cc: Ananyev, Konstantin, Andrew Rybchenko, dev
On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> > Sent: Friday, November 6, 2020 12:55 AM
> >
> > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > >>
> > > > > > > > > > >>> m->nb_seg must be reset on mbuf free whatever the
> > value
> > > > of m->next,
> > > > > > > > > > >>> because it can happen that m->nb_seg is != 1. For
> > > > instance in this
> > > > > > > > > > >>> case:
> > > > > > > > > > >>>
> > > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > > >>>
> > > > > > > > > > >>> As rte_pktmbuf_chain() does not reset nb_seg in the
> > > > initial m1
> > > > > > > > > > >>> segment (this is not required), after this code the
> > > > mbuf chain
> > > > > > > > > > >>> have 3 segments:
> > > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > > >>>
> > > > > > > > > > >>> Freeing this mbuf chain will not restore nb_seg=1
> > in
> > > > the second
> > > > > > > > > > >>> segment.
> > > > > > > > > > >>
> > > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > > > > > > > > >> {
> > > > > > > > > > >> ...
> > > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > > >> m->next = NULL;
> > > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > > >> }
> > > > > > > > > > >>
> > > > > > > > > > >> m1->next != NULL, so it will enter the if() block,
> > > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > > >> What I am missing here?
> > > > > > > > > > >> Thinking in more generic way, that change:
> > > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > > >> - m->next = NULL;
> > > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > > >> - }
> > > > > > > > > > >> + m->next = NULL;
> > > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > > >
> > > > > > > > > > > Ah, sorry. I oversimplified the example and now it
> > does
> > > > not
> > > > > > > > > > > show the issue...
> > > > > > > > > > >
> > > > > > > > > > > The full example also adds a split() to break the
> > mbuf
> > > > chain
> > > > > > > > > > > between m1 and m2. The kind of thing that would be
> > done
> > > > for
> > > > > > > > > > > software TCP segmentation.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > If so, may be the right solution is to care about
> > nb_segs
> > > > > > > > > > when next is set to NULL on split? Any place when next
> > is
> > > > set
> > > > > > > > > > to NULL. Just to keep the optimization in a more
> > generic
> > > > place.
> > > > > > > >
> > > > > > > >
> > > > > > > > > The problem with that approach is that there are already
> > > > several
> > > > > > > > > existing split() or trim() implementations in different
> > DPDK-
> > > > based
> > > > > > > > > applications. For instance, we have some in 6WINDGate. If
> > we
> > > > force
> > > > > > > > > applications to set nb_seg to 1 when resetting next, it
> > has
> > > > to be
> > > > > > > > > documented because it is not straightforward.
> > > > > > > >
> > > > > > > > I think it is better to go that way.
> > > > > > > > From my perspective it seems natural to reset nb_seg at
> > same
> > > > time
> > > > > > > > we reset next, otherwise inconsistency will occur.
> > > > > > >
> > > > > > > While it is not explicitly stated for nb_segs, to me it was
> > clear
> > > > that
> > > > > > > nb_segs is only valid in the first segment, like for many
> > fields
> > > > (port,
> > > > > > > ol_flags, vlan, rss, ...).
> > > > > > >
> > > > > > > If we say that nb_segs has to be valid in any segments, it
> > means
> > > > that
> > > > > > > chain() or split() will have to update it in all segments,
> > which
> > > > is not
> > > > > > > efficient.
> > > > > >
> > > > > > Why in all?
> > > > > > We can state that nb_segs on non-first segment should always
> > equal
> > > > 1.
> > > > > > As I understand in that case, both split() and chain() have to
> > > > update nb_segs
> > > > > > only for head mbufs, rest ones will remain untouched.
> > > > >
> > > > > Well, anyway, I think it's strange to have a constraint on m-
> > >nb_segs
> > > > for
> > > > > non-first segment. We don't have that kind of constraints for
> > other
> > > > fields.
> > > >
> > > > True, we don't. But this is one of the fields we consider critical
> > > > for proper work of mbuf alloc/free mechanism.
> > > >
> > >
> > > I am not sure that requiring m->nb_segs == 1 on non-first segments
> > will provide any benefits.
> >
> > It would make this patch unneeded.
> > So, for direct, non-segmented mbufs pktmbuf_free() will remain write-
> > free.
>
> I see. Then I agree with Konstantin that alternative solutions should be considered.
>
> The benefit regarding free()'ing non-segmented mbufs - which is a very common operation - certainly outweighs the cost of requiring split()/chain() operations to set the new head mbuf's nb_segs = 1.
>
> Nonetheless, the bug needs to be fixed somehow.
>
> If we can't come up with a better solution that doesn't break the ABI, we are forced to accept the patch.
>
> Unless the techboard accepts to break the ABI in order to avoid the performance cost of this patch.
Did someone notice a performance drop with this patch?
On my side, I don't see any regression on a L3 use case.
Let's sumarize: splitting a mbuf chain and freeing it causes subsequent mbuf
allocation to return a mbuf which is not correctly initialized. There are 2
options to fix it:
1/ change the mbuf free function (this patch)
- m->nb_segs would behave like many other field: valid in the first
segment, ignored in other segments
- may impact performance (suspected)
2/ change all places where a mbuf chain is split, or trimmed
- m->nb_segs would have a specific behavior: count the number of
segments in the first mbuf, should be 1 in the last segment,
ignored in other ones.
- no code change in mbuf library, so no performance impact
- need to patch all places where we do a mbuf split or trim. From afar,
I see at least mbuf_cut_seg_ofs() in DPDK. Some external applications
may have to be patched (for instance, I already found 3 places in
6WIND code base without a deep search).
In my opinion, 1/ is better, except we notice a significant performance,
because the (implicit) behavior is unchanged.
Whatever the solution, some documentation has to be added.
Olivier
>
> >
> > >
> > > E.g. the second segment of a three-segment chain will still have m-
> > >next != NULL, so it cannot be used as a gate to prevent accessing m-
> > > >next.
> > >
> > > I might have overlooked something, though.
> > >
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Saying that nb_segs has to be valid for the first and last
> > > > segment seems
> > > > > > > really odd to me. What is the logic behind that except
> > keeping
> > > > this test
> > > > > > > as is?
> > > > > > >
> > > > > > > In any case, it has to be better documented.
> > > > > > >
> > > > > > >
> > > > > > > Olivier
> > > > > > >
> > > > > > >
> > > > > > > > > I think the approach from
> > > > > > > > > this patch is safer.
> > > > > > > >
> > > > > > > > It might be easier from perspective that changes in less
> > places
> > > > are required,
> > > > > > > > Though I think that this patch will introduce some
> > performance
> > > > drop.
> > > > > > > > As now each mbuf_prefree_seg() will cause update of 2 cache
> > > > lines unconditionally.
> > > > > > > >
> > > > > > > > > By the way, for 21.11, if we are able to do some
> > > > optimizations and have
> > > > > > > > > both pool (index?) and next in the first cache line, we
> > may
> > > > reconsider
> > > > > > > > > the fact that next and nb_segs are already set for new
> > > > allocated mbufs,
> > > > > > > > > because it is not straightforward either.
> > > > > > > >
> > > > > > > > My suggestion - let's put future optimization discussion
> > aside
> > > > for now,
> > > > > > > > and concentrate on that particular patch.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > After this operation, we have 2 mbuf chain:
> > > > > > > > > > > - m0 with 2 segments, the last one has next=NULL but
> > > > nb_seg=2
> > > > > > > > > > > - new_m with 1 segment
> > > > > > > > > > >
> > > > > > > > > > > Freeing m0 will not restore nb_seg=1 in the second
> > > > segment.
> > > > > > > > > > >
> > > > > > > > > > >> Assumes that it is ok to have an mbuf with
> > > > > > > > > > >> nb_seg > 1 and next == NULL.
> > > > > > > > > > >> Which seems wrong to me.
> > > > > > > > > > >
> > > > > > > > > > > I don't think it is wrong: nb_seg is just ignored
> > when
> > > > not in the first
> > > > > > > > > > > segment, and there is nothing saying it should be set
> > to
> > > > 1. Typically,
> > > > > > > > > > > rte_pktmbuf_chain() does not change it, and I guess
> > it's
> > > > the same for
> > > > > > > > > > > many similar functions in applications.
> > > > > > > > > > >
> > > > > > > > > > > Olivier
> > > > > > > > > > >
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>> This is expected that mbufs stored in pool have
> > their
> > > > > > > > > > >>> nb_seg field set to 1.
> > > > > > > > > > >>>
> > > > > > > > > > >>> Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields while
> > in
> > > > pool")
> > > > > > > > > > >>> Cc: stable@dpdk.org
> > > > > > > > > > >>>
> > > > > > > > > > >>> Signed-off-by: Olivier Matz
> > <olivier.matz@6wind.com>
> > > > > > > > > > >>> ---
> > > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.c | 6 ++----
> > > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.h | 12 ++++--------
> > > > > > > > > > >>> 2 files changed, 6 insertions(+), 12 deletions(-)
> > > > > > > > > > >>>
> > > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.c
> > > > b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > >>> index 8a456e5e64..e632071c23 100644
> > > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > > >>> @@ -129,10 +129,8 @@
> > > > rte_pktmbuf_free_pinned_extmem(void *addr, void *opaque)
> > > > > > > > > > >>>
> > > > > > > > > > >>> rte_mbuf_ext_refcnt_set(m->shinfo, 1);
> > > > > > > > > > >>> m->ol_flags = EXT_ATTACHED_MBUF;
> > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > >>> - }
> > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > >>> rte_mbuf_raw_free(m);
> > > > > > > > > > >>> }
> > > > > > > > > > >>>
> > > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.h
> > > > b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > >>> index a1414ed7cd..ef5800c8ef 100644
> > > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > > >>> @@ -1329,10 +1329,8 @@
> > rte_pktmbuf_prefree_seg(struct
> > > > rte_mbuf *m)
> > > > > > > > > > >>> return NULL;
> > > > > > > > > > >>> }
> > > > > > > > > > >>>
> > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > >>> - }
> > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > >>>
> > > > > > > > > > >>> return m;
> > > > > > > > > > >>>
> > > > > > > > > > >>> @@ -1346,10 +1344,8 @@
> > rte_pktmbuf_prefree_seg(struct
> > > > rte_mbuf *m)
> > > > > > > > > > >>> return NULL;
> > > > > > > > > > >>> }
> > > > > > > > > > >>>
> > > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > > >>> - }
> > > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > > >>> rte_mbuf_refcnt_set(m, 1);
> > > > > > > > > > >>>
> > > > > > > > > > >>> return m;
> > > > > > > > > > >>> --
> > > > > > > > > > >>> 2.25.1
> > > > > > > > > > >>
> > > > > > > > > >
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free
@ 2020-11-06 7:52 4% ` Morten Brørup
2020-11-06 8:20 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-06 7:52 UTC (permalink / raw)
To: Ananyev, Konstantin, Olivier Matz; +Cc: Andrew Rybchenko, dev
> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> Sent: Friday, November 6, 2020 12:55 AM
>
> > > > > > > > > >> Hi Olivier,
> > > > > > > > > >>
> > > > > > > > > >>> m->nb_seg must be reset on mbuf free whatever the
> value
> > > of m->next,
> > > > > > > > > >>> because it can happen that m->nb_seg is != 1. For
> > > instance in this
> > > > > > > > > >>> case:
> > > > > > > > > >>>
> > > > > > > > > >>> m1 = rte_pktmbuf_alloc(mp);
> > > > > > > > > >>> rte_pktmbuf_append(m1, 500);
> > > > > > > > > >>> m2 = rte_pktmbuf_alloc(mp);
> > > > > > > > > >>> rte_pktmbuf_append(m2, 500);
> > > > > > > > > >>> rte_pktmbuf_chain(m1, m2);
> > > > > > > > > >>> m0 = rte_pktmbuf_alloc(mp);
> > > > > > > > > >>> rte_pktmbuf_append(m0, 500);
> > > > > > > > > >>> rte_pktmbuf_chain(m0, m1);
> > > > > > > > > >>>
> > > > > > > > > >>> As rte_pktmbuf_chain() does not reset nb_seg in the
> > > initial m1
> > > > > > > > > >>> segment (this is not required), after this code the
> > > mbuf chain
> > > > > > > > > >>> have 3 segments:
> > > > > > > > > >>> - m0: next=m1, nb_seg=3
> > > > > > > > > >>> - m1: next=m2, nb_seg=2
> > > > > > > > > >>> - m2: next=NULL, nb_seg=1
> > > > > > > > > >>>
> > > > > > > > > >>> Freeing this mbuf chain will not restore nb_seg=1
> in
> > > the second
> > > > > > > > > >>> segment.
> > > > > > > > > >>
> > > > > > > > > >> Hmm, not sure why is that?
> > > > > > > > > >> You are talking about freeing m1, right?
> > > > > > > > > >> rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> > > > > > > > > >> {
> > > > > > > > > >> ...
> > > > > > > > > >> if (m->next != NULL) {
> > > > > > > > > >> m->next = NULL;
> > > > > > > > > >> m->nb_segs = 1;
> > > > > > > > > >> }
> > > > > > > > > >>
> > > > > > > > > >> m1->next != NULL, so it will enter the if() block,
> > > > > > > > > >> and will reset both next and nb_segs.
> > > > > > > > > >> What I am missing here?
> > > > > > > > > >> Thinking in more generic way, that change:
> > > > > > > > > >> - if (m->next != NULL) {
> > > > > > > > > >> - m->next = NULL;
> > > > > > > > > >> - m->nb_segs = 1;
> > > > > > > > > >> - }
> > > > > > > > > >> + m->next = NULL;
> > > > > > > > > >> + m->nb_segs = 1;
> > > > > > > > > >
> > > > > > > > > > Ah, sorry. I oversimplified the example and now it
> does
> > > not
> > > > > > > > > > show the issue...
> > > > > > > > > >
> > > > > > > > > > The full example also adds a split() to break the
> mbuf
> > > chain
> > > > > > > > > > between m1 and m2. The kind of thing that would be
> done
> > > for
> > > > > > > > > > software TCP segmentation.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > If so, may be the right solution is to care about
> nb_segs
> > > > > > > > > when next is set to NULL on split? Any place when next
> is
> > > set
> > > > > > > > > to NULL. Just to keep the optimization in a more
> generic
> > > place.
> > > > > > >
> > > > > > >
> > > > > > > > The problem with that approach is that there are already
> > > several
> > > > > > > > existing split() or trim() implementations in different
> DPDK-
> > > based
> > > > > > > > applications. For instance, we have some in 6WINDGate. If
> we
> > > force
> > > > > > > > applications to set nb_seg to 1 when resetting next, it
> has
> > > to be
> > > > > > > > documented because it is not straightforward.
> > > > > > >
> > > > > > > I think it is better to go that way.
> > > > > > > From my perspective it seems natural to reset nb_seg at
> same
> > > time
> > > > > > > we reset next, otherwise inconsistency will occur.
> > > > > >
> > > > > > While it is not explicitly stated for nb_segs, to me it was
> clear
> > > that
> > > > > > nb_segs is only valid in the first segment, like for many
> fields
> > > (port,
> > > > > > ol_flags, vlan, rss, ...).
> > > > > >
> > > > > > If we say that nb_segs has to be valid in any segments, it
> means
> > > that
> > > > > > chain() or split() will have to update it in all segments,
> which
> > > is not
> > > > > > efficient.
> > > > >
> > > > > Why in all?
> > > > > We can state that nb_segs on non-first segment should always
> equal
> > > 1.
> > > > > As I understand in that case, both split() and chain() have to
> > > update nb_segs
> > > > > only for head mbufs, rest ones will remain untouched.
> > > >
> > > > Well, anyway, I think it's strange to have a constraint on m-
> >nb_segs
> > > for
> > > > non-first segment. We don't have that kind of constraints for
> other
> > > fields.
> > >
> > > True, we don't. But this is one of the fields we consider critical
> > > for proper work of mbuf alloc/free mechanism.
> > >
> >
> > I am not sure that requiring m->nb_segs == 1 on non-first segments
> will provide any benefits.
>
> It would make this patch unneeded.
> So, for direct, non-segmented mbufs pktmbuf_free() will remain write-
> free.
I see. Then I agree with Konstantin that alternative solutions should be considered.
The benefit regarding free()'ing non-segmented mbufs - which is a very common operation - certainly outweighs the cost of requiring split()/chain() operations to set the new head mbuf's nb_segs = 1.
Nonetheless, the bug needs to be fixed somehow.
If we can't come up with a better solution that doesn't break the ABI, we are forced to accept the patch.
Unless the techboard accepts to break the ABI in order to avoid the performance cost of this patch.
>
> >
> > E.g. the second segment of a three-segment chain will still have m-
> >next != NULL, so it cannot be used as a gate to prevent accessing m-
> > >next.
> >
> > I might have overlooked something, though.
> >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > Saying that nb_segs has to be valid for the first and last
> > > segment seems
> > > > > > really odd to me. What is the logic behind that except
> keeping
> > > this test
> > > > > > as is?
> > > > > >
> > > > > > In any case, it has to be better documented.
> > > > > >
> > > > > >
> > > > > > Olivier
> > > > > >
> > > > > >
> > > > > > > > I think the approach from
> > > > > > > > this patch is safer.
> > > > > > >
> > > > > > > It might be easier from perspective that changes in less
> places
> > > are required,
> > > > > > > Though I think that this patch will introduce some
> performance
> > > drop.
> > > > > > > As now each mbuf_prefree_seg() will cause update of 2 cache
> > > lines unconditionally.
> > > > > > >
> > > > > > > > By the way, for 21.11, if we are able to do some
> > > optimizations and have
> > > > > > > > both pool (index?) and next in the first cache line, we
> may
> > > reconsider
> > > > > > > > the fact that next and nb_segs are already set for new
> > > allocated mbufs,
> > > > > > > > because it is not straightforward either.
> > > > > > >
> > > > > > > My suggestion - let's put future optimization discussion
> aside
> > > for now,
> > > > > > > and concentrate on that particular patch.
> > > > > > >
> > > > > > > >
> > > > > > > > > > After this operation, we have 2 mbuf chain:
> > > > > > > > > > - m0 with 2 segments, the last one has next=NULL but
> > > nb_seg=2
> > > > > > > > > > - new_m with 1 segment
> > > > > > > > > >
> > > > > > > > > > Freeing m0 will not restore nb_seg=1 in the second
> > > segment.
> > > > > > > > > >
> > > > > > > > > >> Assumes that it is ok to have an mbuf with
> > > > > > > > > >> nb_seg > 1 and next == NULL.
> > > > > > > > > >> Which seems wrong to me.
> > > > > > > > > >
> > > > > > > > > > I don't think it is wrong: nb_seg is just ignored
> when
> > > not in the first
> > > > > > > > > > segment, and there is nothing saying it should be set
> to
> > > 1. Typically,
> > > > > > > > > > rte_pktmbuf_chain() does not change it, and I guess
> it's
> > > the same for
> > > > > > > > > > many similar functions in applications.
> > > > > > > > > >
> > > > > > > > > > Olivier
> > > > > > > > > >
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>> This is expected that mbufs stored in pool have
> their
> > > > > > > > > >>> nb_seg field set to 1.
> > > > > > > > > >>>
> > > > > > > > > >>> Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields while
> in
> > > pool")
> > > > > > > > > >>> Cc: stable@dpdk.org
> > > > > > > > > >>>
> > > > > > > > > >>> Signed-off-by: Olivier Matz
> <olivier.matz@6wind.com>
> > > > > > > > > >>> ---
> > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.c | 6 ++----
> > > > > > > > > >>> lib/librte_mbuf/rte_mbuf.h | 12 ++++--------
> > > > > > > > > >>> 2 files changed, 6 insertions(+), 12 deletions(-)
> > > > > > > > > >>>
> > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.c
> > > b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > >>> index 8a456e5e64..e632071c23 100644
> > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.c
> > > > > > > > > >>> @@ -129,10 +129,8 @@
> > > rte_pktmbuf_free_pinned_extmem(void *addr, void *opaque)
> > > > > > > > > >>>
> > > > > > > > > >>> rte_mbuf_ext_refcnt_set(m->shinfo, 1);
> > > > > > > > > >>> m->ol_flags = EXT_ATTACHED_MBUF;
> > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > >>> - }
> > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > >>> rte_mbuf_raw_free(m);
> > > > > > > > > >>> }
> > > > > > > > > >>>
> > > > > > > > > >>> diff --git a/lib/librte_mbuf/rte_mbuf.h
> > > b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > >>> index a1414ed7cd..ef5800c8ef 100644
> > > > > > > > > >>> --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > >>> +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > >>> @@ -1329,10 +1329,8 @@
> rte_pktmbuf_prefree_seg(struct
> > > rte_mbuf *m)
> > > > > > > > > >>> return NULL;
> > > > > > > > > >>> }
> > > > > > > > > >>>
> > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > >>> - }
> > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > >>>
> > > > > > > > > >>> return m;
> > > > > > > > > >>>
> > > > > > > > > >>> @@ -1346,10 +1344,8 @@
> rte_pktmbuf_prefree_seg(struct
> > > rte_mbuf *m)
> > > > > > > > > >>> return NULL;
> > > > > > > > > >>> }
> > > > > > > > > >>>
> > > > > > > > > >>> - if (m->next != NULL) {
> > > > > > > > > >>> - m->next = NULL;
> > > > > > > > > >>> - m->nb_segs = 1;
> > > > > > > > > >>> - }
> > > > > > > > > >>> + m->next = NULL;
> > > > > > > > > >>> + m->nb_segs = 1;
> > > > > > > > > >>> rte_mbuf_refcnt_set(m, 1);
> > > > > > > > > >>>
> > > > > > > > > >>> return m;
> > > > > > > > > >>> --
> > > > > > > > > >>> 2.25.1
> > > > > > > > > >>
> > > > > > > > >
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v9 6/6] doc: update release notes now for block allow changes
@ 2020-11-05 22:36 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-11-05 22:36 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Remove the deprecation notice and add description to the release notes.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 23 -----------------------
doc/guides/rel_notes/release_20_11.rst | 11 +++++++++++
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index f3258eb3f725..d459a25eabe3 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -28,29 +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 as well as macros.
-
- The macro ``RTE_DEV_BLACKLISTED`` will be replaced with ``RTE_DEV_EXCLUDED``
- and ``RTE_DEV_WHITELISTED`` will be replaced with ``RTE_DEV_INCLUDED``
- ``RTE_BUS_SCAN_BLACKLIST`` and ``RTE_BUS_SCAN_WHITELIST`` will be
- replaced with ``RTE_BUS_SCAN_EXCLUDED`` and ``RTE_BUS_SCAN_INCLUDED``
- respectively. Likewise ``RTE_DEVTYPE_BLACKLISTED_PCI`` and
- ``RTE_DEVTYPE_WHITELISTED_PCI`` will be replaced with
- ``RTE_DEVTYPE_EXCLUDED`` and ``RTE_DEVTYPE_INCLUDED``.
-
- The old macros will be marked as deprecated in 20.11 and any
- usage will cause a compile warning. They will be removed in
- a future release.
-
- 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``.
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 6bbd6ee93922..df955e2214c4 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -644,6 +644,17 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The selection of devices on the EAL command line has been
+ changed from ``--pci-blacklist`` and ``--pci-whitelist``
+ to ``--block`` and ``--allow``. The short form option for
+ using a device is now ``-a`` instead of ``-w``.
+
+ The internal macros for ``RTE_DEV_BLACKLISTED`` and ``RTE_DEV_WHITELISTED``
+ have been replaced with ``RTE_DEV_BLOCKED`` and ``RTE_DEV_ALLOWED``.
+
+ There are compatibility macros and command line mappings to accept
+ the old values but applications and scripts are strongly encouraged
+ to migrate to the new names.
ABI Changes
-----------
--
2.27.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-05 9:35 3% ` Morten Brørup
@ 2020-11-05 10:29 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2020-11-05 10:29 UTC (permalink / raw)
To: Morten Brørup
Cc: Ananyev, Konstantin, Olivier Matz, Slava Ovsiienko,
NBU-Contact-Thomas Monjalon, dev, techboard, Ajit Khaparde,
Andrew Rybchenko, Yigit, Ferruh, david.marchand, jerinj,
honnappa.nagarahalli, maxime.coquelin, stephen, hemant.agrawal,
Matan Azrad, Shahaf Shuler
On Thu, Nov 05, 2020 at 10:35:45AM +0100, Morten Brørup wrote:
> There is a simple alternative for applications with a single mbuf pool to avoid accessing m->pool.
>
> We could add a global variable pointing to the single mbuf pool.
>
> It would be NULL by default.
>
> It would be set by rte_pktmbuf_pool_create() on first invocation, and reset back to NULL on following invocations. (There would need to be a counter too, to prevent setting it again on the third invocation.)
>
> All functions accessing m->pool would use the global mbuf pool pointer if set, and otherwise use the m->pool pointer, like this:
>
> - rte_mempool_put(m->pool, m);
> + rte_mempool_put(global_mbuf_pool ? global_mbuf_pool : m->pool, m);
>
> This optimization can be implemented without ABI breakage:
>
> Since m->pool is initialized as always, functions that are not modified to use the global_mbuf_pool will simply continue using m->pool, not knowing that a global mbuf pool exists.
>
Very interesting idea. Definitely worth considering. A TX function would
only have to check the global variable once at the start of cleanup too,
and if set, it can use bulk frees without any additional work.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-05 0:25 0% ` Ananyev, Konstantin
@ 2020-11-05 9:35 3% ` Morten Brørup
2020-11-05 10:29 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-05 9:35 UTC (permalink / raw)
To: Ananyev, Konstantin, Olivier Matz
Cc: Slava Ovsiienko, NBU-Contact-Thomas Monjalon, dev, techboard,
Ajit Khaparde, Andrew Rybchenko, Yigit, Ferruh, david.marchand,
Richardson, Bruce, jerinj, honnappa.nagarahalli, maxime.coquelin,
stephen, hemant.agrawal, Matan Azrad, Shahaf Shuler
There is a simple alternative for applications with a single mbuf pool to avoid accessing m->pool.
We could add a global variable pointing to the single mbuf pool.
It would be NULL by default.
It would be set by rte_pktmbuf_pool_create() on first invocation, and reset back to NULL on following invocations. (There would need to be a counter too, to prevent setting it again on the third invocation.)
All functions accessing m->pool would use the global mbuf pool pointer if set, and otherwise use the m->pool pointer, like this:
- rte_mempool_put(m->pool, m);
+ rte_mempool_put(global_mbuf_pool ? global_mbuf_pool : m->pool, m);
This optimization can be implemented without ABI breakage:
Since m->pool is initialized as always, functions that are not modified to use the global_mbuf_pool will simply continue using m->pool, not knowing that a global mbuf pool exists.
Med venlig hilsen / kind regards
- Morten Brørup
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-04 15:00 0% ` Olivier Matz
@ 2020-11-05 0:25 0% ` Ananyev, Konstantin
2020-11-05 9:35 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2020-11-05 0:25 UTC (permalink / raw)
To: Olivier Matz, Morten Brørup
Cc: Slava Ovsiienko, NBU-Contact-Thomas Monjalon, dev, techboard,
Ajit Khaparde, Andrew Rybchenko, Yigit, Ferruh, david.marchand,
Richardson, Bruce, jerinj, honnappa.nagarahalli, maxime.coquelin,
stephen, hemant.agrawal, Matan Azrad, Shahaf Shuler
>
> Hi,
>
> On Tue, Nov 03, 2020 at 04:03:46PM +0100, Morten Brørup wrote:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Slava Ovsiienko
> > > Sent: Tuesday, November 3, 2020 3:03 PM
> > >
> > > Hi, Morten
> > >
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: Tuesday, November 3, 2020 14:10
> > > >
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > Sent: Monday, November 2, 2020 4:58 PM
> > > > >
> > > > > +Cc techboard
> > > > >
> > > > > We need benchmark numbers in order to take a decision.
> > > > > Please all, prepare some arguments and numbers so we can discuss
> > > the
> > > > > mbuf layout in the next techboard meeting.
>
> I did some quick tests, and it appears to me that just moving the pool
> pointer to the first cache line has not a significant impact.
Hmm, as I remember Thomas mentioned about 5%+ improvement
with that change. Though I suppose a lot depends from actual test-case.
Would be good to know when it does help and when it doesn't.
>
> However, I agree with Morten that there is some room for optimization
> around m->pool: I did a hack in the ixgbe driver to assume there is only
> one mbuf pool. This simplifies a lot the freeing of mbufs in Tx, because
> we don't have to group them in bulks that shares the same pool (see
> ixgbe_tx_free_bufs()). The impact of this hack is quite good: +~5% on a
> real-life forwarding use case.
I think we already have such optimization ability within DPDK:
#define DEV_TX_OFFLOAD_MBUF_FAST_FREE 0x00010000
/**< Device supports optimization for fast release of mbufs.
* When set application must guarantee that per-queue all mbufs comes from
* the same mempool and has refcnt = 1.
*/
Seems over-optimistic to me, but many PMDs do support it.
>
> It is maybe possible to store the pool in the sw ring to avoid a later
> access to m->pool. Having a pool index as suggested by Morten would also
> help to reduce used room in sw ring in this case. But this is a bit
> off-topic :)
>
>
>
> > > > I propose that the techboard considers this from two angels:
> > > >
> > > > 1. Long term goals and their relative priority. I.e. what can be
> > > achieved with
> > > > wide-ranging modifications, requiring yet another ABI break and due
> > > notices.
> > > >
> > > > 2. Short term goals, i.e. what can be achieved for this release.
> > > >
> > > >
> > > > My suggestions follow...
> > > >
> > > > 1. Regarding long term goals:
> > > >
> > > > I have argued that simple forwarding of non-segmented packets using
> > > only the
> > > > first mbuf cache line can be achieved by making three
> > > > modifications:
> > > >
> > > > a) Move m->tx_offload to the first cache line.
> > > Not all PMDs use this field on Tx. HW might support the checksum
> > > offloads
> > > directly, not requiring these fields at all.
>
> To me, a driver should use m->tx_offload, because the application
> specifies the offset where the checksum has to be done, in case the hw
> is not able to recognize the protocol.
>
> > > > b) Use an 8 bit pktmbuf mempool index in the first cache line,
> > > > instead of the 64 bit m->pool pointer in the second cache line.
> > > 256 mpool looks enough, as for me. Regarding the indirect access to the
> > > pool
> > > (via some table) - it might introduce some performance impact.
> >
> > It might, but I hope that it is negligible, so the benefits outweigh the disadvantages.
> >
> > It would have to be measured, though.
> >
> > And m->pool is only used for free()'ing (and detach()'ing) mbufs.
> >
> > > For example,
> > > mlx5 PMD strongly relies on pool field for allocating mbufs in Rx
> > > datapath.
> > > We're going to update (o-o, we found point to optimize), but for now it
> > > does.
> >
> > Without looking at the source code, I don't think the PMD is using m->pool in the RX datapath, I think it is using a pool dedicated to a
> receive queue used for RX descriptors in the PMD (i.e. driver->queue->pool).
> >
> > >
> > > > c) Do not access m->next when we know that it is NULL.
> > > > We can use m->nb_segs == 1 or some other invariant as the gate.
> > > > It can be implemented by adding an m->next accessor function:
> > > > struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> > > > {
> > > > return m->nb_segs == 1 ? NULL : m->next;
> > > > }
> > >
> > > Sorry, not sure about this. IIRC, nb_segs is valid in the first
> > > segment/mbuf only.
> > > If we have the 4 segments in the pkt we see nb_seg=4 in the first one,
> > > and the nb_seg=1
> > > in the others. The next field is NULL in the last mbuf only. Am I wrong
> > > and miss something ?
> >
> > You are correct.
> >
> > This would have to be updated too. Either by increasing m->nb_seg in the following segments, or by splitting up relevant functions into
> functions for working on first segments (incl. non-segmented packets), and functions for working on following segments of segmented
> packets.
>
> Instead of maintaining a valid nb_segs, a HAS_NEXT flag would be easier
> to implement. However it means that an accessor needs to be used instead
> of any m->next access.
>
> > > > Regarding the priority of this goal, I guess that simple forwarding
> > > of non-
> > > > segmented packets is probably the path taken by the majority of
> > > packets
> > > > handled by DPDK.
> > > >
> > > > An alternative goal could be:
> > > > Do not touch the second cache line during RX.
> > > > A comment in the mbuf structure says so, but it is not true anymore.
> > > >
> > > > (I guess that regression testing didn't catch this because the tests
> > > perform TX
> > > > immediately after RX, so the cache miss just moves from the TX to the
> > > RX part
> > > > of the test application.)
> > > >
> > > >
> > > > 2. Regarding short term goals:
> > > >
> > > > The current DPDK source code looks to me like m->next is the most
> > > frequently
> > > > accessed field in the second cache line, so it makes sense moving
> > > this to the
> > > > first cache line, rather than m->pool.
> > > > Benchmarking may help here.
> > >
> > > Moreover, for the segmented packets the packet size is supposed to be
> > > large,
> > > and it imposes the relatively low packet rate, so probably optimization
> > > of
> > > moving next to the 1st cache line might be negligible at all. Just
> > > compare 148Mpps of
> > > 64B pkts and 4Mpps of 3000B pkts over 100Gbps link. Currently we are on
> > > benchmarking
> > > and did not succeed yet on difference finding. The benefit can't be
> > > expressed in mpps delta,
> > > we should measure CPU clocks, but Rx queue is almost always empty - we
> > > have an empty
> > > loops. So, if we have the boost - it is extremely hard to catch one.
> >
> > Very good point regarding the value of such an optimization, Slava!
> >
> > And when free()'ing packets, both m->next and m->pool are touched.
> >
> > So perhaps the free()/detach() functions in the mbuf library can be modified to handle first segments (and non-segmented packets) and
> following segments differently, so accessing m->next can be avoided for non-segmented packets. Then m->pool should be moved to the
> first cache line.
> >
>
> I also think that Moving m->pool without doing something else about
> m->next is probably useless. And it's too late for 20.11 to do
> additionnal changes, so I suggest to postpone the field move to 21.11,
> once we have a clearer view of possible optimizations.
>
> Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] mbuf: minor cleanup
2020-10-20 11:55 0% ` Thomas Monjalon
@ 2020-11-04 22:17 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2020-11-04 22:17 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Olivier Matz
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, October 20, 2020 1:56 PM
>
> Hi Morten,
> Any update about this patch please?
Thomas,
v4 contains all the modifications suggested by Olivier:
https://patchwork.dpdk.org/patch/82198/
Except a depreciation notice about the old names without RTE_. I'm not sure about the formal requirements for depreciation notices. If there are no formal requirements, please feel free to add a notice when merging.
Changes regarding missing RTE_ prefix:
* Converted the MBUF_RAW_ALLOC_CHECK() macro to an
__rte_mbuf_raw_sanity_check() inline function.
Added backwards compatible macro with the original name.
* Renamed the MBUF_INVALID_PORT definition to RTE_MBUF_PORT_INVALID.
Added backwards compatible definition with the original name.
>
> 07/10/2020 11:16, Olivier Matz:
> > Hi Morten,
> >
> > Thanks for this cleanup. Please see some comments below.
> >
> > On Wed, Sep 16, 2020 at 12:40:13PM +0200, Morten Brørup wrote:
> > > The mbuf header files had some commenting style errors that affected
> the
> > > API documentation.
> > > Also, the RTE_ prefix was missing on a macro and a definition.
> > >
> > > Note: This patch does not touch the offload and attachment flags that
> are
> > > also missing the RTE_ prefix.
> > >
> > > Changes only affecting documentation:
> > > * Removed the MBUF_INVALID_PORT definition from rte_mbuf.h; it is
> > > already defined in rte_mbuf_core.h.
> > > This removal also reestablished the description of the
> > > rte_pktmbuf_reset() function.
> > > * Corrected the comment related to RTE_MBUF_MAX_NB_SEGS.
> > > * Corrected the comment related to PKT_TX_QINQ_PKT.
> > >
> > > Changes regarding missing RTE_ prefix:
> > > * Converted the MBUF_RAW_ALLOC_CHECK() macro to an
> > > __rte_mbuf_raw_sanity_check() inline function.
> > > Added backwards compatible macro with the original name.
> > > * Renamed the MBUF_INVALID_PORT definition to RTE_MBUF_PORT_INVALID.
> > > Added backwards compatible definition with the original name.
> > >
> > > v2:
> > > * Use RTE_MBUF_PORT_INVALID instead of MBUF_INVALID_PORT in rte_mbuf.c.
> > >
> > > v3:
> > > * The functions/macros used in __rte_mbuf_raw_sanity_check() require
> > > RTE_ENABLE_ASSERT or RTE_LIBRTE_MBUF_DEBUG, or they don't use the
> mbuf
> > > parameter, which generates a compiler waning. So mark the mbuf
> parameter
> > > __rte_unused if none of them are defined.
> > >
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > ---
> > > doc/guides/rel_notes/deprecation.rst | 7 ----
> > > lib/librte_mbuf/rte_mbuf.c | 4 +-
> > > lib/librte_mbuf/rte_mbuf.h | 55 +++++++++++++++++++---------
> > > lib/librte_mbuf/rte_mbuf_core.h | 9 +++--
> > > 4 files changed, 45 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> > > index 279eccb04..88d7d0761 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -294,13 +294,6 @@ Deprecation Notices
> > > - https://patches.dpdk.org/patch/71457/
> > > - https://patches.dpdk.org/patch/71456/
> > >
> > > -* rawdev: The rawdev APIs which take a device-specific structure as
> > > - parameter directly, or indirectly via a "private" pointer inside
> another
> > > - structure, will be modified to take an additional parameter of the
> > > - structure size. The affected APIs will include
> ``rte_rawdev_info_get``,
> > > - ``rte_rawdev_configure``, ``rte_rawdev_queue_conf_get`` and
> > > - ``rte_rawdev_queue_setup``.
> > > -
> > > * acl: ``RTE_ACL_CLASSIFY_NUM`` enum value will be removed.
> > > This enum value is not used inside DPDK, while it prevents to add
> new
> > > classify algorithms without causing an ABI breakage.
> >
> > I think this change is not related.
> >
> > This makes me think that a deprecation notice could be done for the
> > old names without the RTE_ prefix, to be removed in 21.11.
> >
> >
> > > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> > > index 8a456e5e6..53a015311 100644
> > > --- a/lib/librte_mbuf/rte_mbuf.c
> > > +++ b/lib/librte_mbuf/rte_mbuf.c
> > > @@ -104,7 +104,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
> > > /* init some constant fields */
> > > m->pool = mp;
> > > m->nb_segs = 1;
> > > - m->port = MBUF_INVALID_PORT;
> > > + m->port = RTE_MBUF_PORT_INVALID;
> > > rte_mbuf_refcnt_set(m, 1);
> > > m->next = NULL;
> > > }
> > > @@ -207,7 +207,7 @@ __rte_pktmbuf_init_extmem(struct rte_mempool *mp,
> > > /* init some constant fields */
> > > m->pool = mp;
> > > m->nb_segs = 1;
> > > - m->port = MBUF_INVALID_PORT;
> > > + m->port = RTE_MBUF_PORT_INVALID;
> > > m->ol_flags = EXT_ATTACHED_MBUF;
> > > rte_mbuf_refcnt_set(m, 1);
> > > m->next = NULL;
> > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > > index 7259575a7..406d3abb2 100644
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -554,12 +554,36 @@ __rte_experimental
> > > int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
> > > const char **reason);
> > >
> > > -#define MBUF_RAW_ALLOC_CHECK(m) do { \
> > > - RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1); \
> > > - RTE_ASSERT((m)->next == NULL); \
> > > - RTE_ASSERT((m)->nb_segs == 1); \
> > > - __rte_mbuf_sanity_check(m, 0); \
> > > -} while (0)
> > > +#if defined(RTE_ENABLE_ASSERT) || defined(RTE_LIBRTE_MBUF_DEBUG)
> >
> > I don't see why this #if is needed. Wouldn't it work to have only
> > one function definition with the __rte_unused attribute?
> >
> > > +/**
> > > + * Sanity checks on a reinitialized mbuf.
> > > + *
> > > + * Check the consistency of the given reinitialized mbuf.
> > > + * The function will cause a panic if corruption is detected.
> > > + *
> > > + * Check that the mbuf is properly reinitialized (refcnt=1, next=NULL,
> > > + * nb_segs=1), as done by rte_pktmbuf_prefree_seg().
> > > + *
> >
> > Maybe indicate that these checks are only done when debug is on.
> >
> > > + * @param m
> > > + * The mbuf to be checked.
> > > + */
> > > +static __rte_always_inline void
> > > +__rte_mbuf_raw_sanity_check(const struct rte_mbuf *m)
> > > +{
> > > + RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
> > > + RTE_ASSERT(m->next == NULL);
> > > + RTE_ASSERT(m->nb_segs == 1);
> > > + __rte_mbuf_sanity_check(m, 0);
> > > +}
> > > +#else
> > > +static __rte_always_inline void
> > > +__rte_mbuf_raw_sanity_check(const struct rte_mbuf *m __rte_unused)
> > > +{
> > > + /* Nothing here. */
> > > +}
> > > +#endif
> > > +/** For backwards compatibility. */
> > > +#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_sanity_check(m)
> >
> > It looks that MBUF_RAW_ALLOC_CHECK() is also used in drivers/net/sfc,
> > I think it should be updated too.
> >
> > >
> > > /**
> > > * Allocate an uninitialized mbuf from mempool *mp*.
> > > @@ -586,7 +610,7 @@ static inline struct rte_mbuf
> *rte_mbuf_raw_alloc(struct rte_mempool *mp)
> > >
> > > if (rte_mempool_get(mp, (void **)&m) < 0)
> > > return NULL;
> > > - MBUF_RAW_ALLOC_CHECK(m);
> > > + __rte_mbuf_raw_sanity_check(m);
> > > return m;
> > > }
> > >
> > > @@ -609,10 +633,7 @@ rte_mbuf_raw_free(struct rte_mbuf *m)
> > > {
> > > RTE_ASSERT(!RTE_MBUF_CLONED(m) &&
> > > (!RTE_MBUF_HAS_EXTBUF(m) || RTE_MBUF_HAS_PINNED_EXTBUF(m)));
> > > - RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
> > > - RTE_ASSERT(m->next == NULL);
> > > - RTE_ASSERT(m->nb_segs == 1);
> > > - __rte_mbuf_sanity_check(m, 0);
> > > + __rte_mbuf_raw_sanity_check(m);
> > > rte_mempool_put(m->pool, m);
> > > }
> > >
> > > @@ -858,8 +879,6 @@ static inline void
> rte_pktmbuf_reset_headroom(struct rte_mbuf *m)
> > > * @param m
> > > * The packet mbuf to be reset.
> > > */
> > > -#define MBUF_INVALID_PORT UINT16_MAX
> > > -
> > > static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> > > {
> > > m->next = NULL;
> > > @@ -868,7 +887,7 @@ static inline void rte_pktmbuf_reset(struct
> rte_mbuf *m)
> > > m->vlan_tci = 0;
> > > m->vlan_tci_outer = 0;
> > > m->nb_segs = 1;
> > > - m->port = MBUF_INVALID_PORT;
> > > + m->port = RTE_MBUF_PORT_INVALID;
> > >
> > > m->ol_flags &= EXT_ATTACHED_MBUF;
> > > m->packet_type = 0;
> > > @@ -931,22 +950,22 @@ static inline int rte_pktmbuf_alloc_bulk(struct
> rte_mempool *pool,
> > > switch (count % 4) {
> > > case 0:
> > > while (idx != count) {
> > > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > > rte_pktmbuf_reset(mbufs[idx]);
> > > idx++;
> > > /* fall-through */
> > > case 3:
> > > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > > rte_pktmbuf_reset(mbufs[idx]);
> > > idx++;
> > > /* fall-through */
> > > case 2:
> > > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > > rte_pktmbuf_reset(mbufs[idx]);
> > > idx++;
> > > /* fall-through */
> > > case 1:
> > > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > > rte_pktmbuf_reset(mbufs[idx]);
> > > idx++;
> > > /* fall-through */
> > > diff --git a/lib/librte_mbuf/rte_mbuf_core.h
> b/lib/librte_mbuf/rte_mbuf_core.h
> > > index 8cd7137ac..4ac5609e3 100644
> > > --- a/lib/librte_mbuf/rte_mbuf_core.h
> > > +++ b/lib/librte_mbuf/rte_mbuf_core.h
> > > @@ -272,7 +272,7 @@ extern "C" {
> > > * mbuf 'vlan_tci' & 'vlan_tci_outer' must be valid when this flag is
> set.
> > > */
> > > #define PKT_TX_QINQ (1ULL << 49)
> > > -/* this old name is deprecated */
> > > +/** This old name is deprecated. */
> > > #define PKT_TX_QINQ_PKT PKT_TX_QINQ
> > >
> > > /**
> > > @@ -686,7 +686,7 @@ struct rte_mbuf_ext_shared_info {
> > > };
> > > };
> > >
> > > -/**< Maximum number of nb_segs allowed. */
> > > +/** Maximum number of nb_segs allowed. */
> > > #define RTE_MBUF_MAX_NB_SEGS UINT16_MAX
> > >
> > > /**
> > > @@ -714,7 +714,10 @@ struct rte_mbuf_ext_shared_info {
> > > #define RTE_MBUF_DIRECT(mb) \
> > > (!((mb)->ol_flags & (IND_ATTACHED_MBUF | EXT_ATTACHED_MBUF)))
> > >
> > > -#define MBUF_INVALID_PORT UINT16_MAX
> > > +/** NULL value for the uint16_t port type. */
> > > +#define RTE_MBUF_PORT_INVALID UINT16_MAX
> >
> > I don't really like talking about "NULL". What do you think instead of
> > this wording?
> >
> > /** Uninitialized or unspecified port */
> >
> > > +/** For backwards compatibility. */
> > > +#define MBUF_INVALID_PORT RTE_MBUF_PORT_INVALID
> > >
> > > /**
> > > * A macro that points to an offset into the data in the mbuf.
> >
> > Thanks,
> > Olivier
> >
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 15:03 0% ` Morten Brørup
@ 2020-11-04 15:00 0% ` Olivier Matz
2020-11-05 0:25 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2020-11-04 15:00 UTC (permalink / raw)
To: Morten Brørup
Cc: Slava Ovsiienko, NBU-Contact-Thomas Monjalon, dev, techboard,
Ajit Khaparde, Ananyev, Konstantin, Andrew Rybchenko, Yigit,
Ferruh, david.marchand, Richardson, Bruce, jerinj,
honnappa.nagarahalli, maxime.coquelin, stephen, hemant.agrawal,
Matan Azrad, Shahaf Shuler
Hi,
On Tue, Nov 03, 2020 at 04:03:46PM +0100, Morten Brørup wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Slava Ovsiienko
> > Sent: Tuesday, November 3, 2020 3:03 PM
> >
> > Hi, Morten
> >
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: Tuesday, November 3, 2020 14:10
> > >
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Monday, November 2, 2020 4:58 PM
> > > >
> > > > +Cc techboard
> > > >
> > > > We need benchmark numbers in order to take a decision.
> > > > Please all, prepare some arguments and numbers so we can discuss
> > the
> > > > mbuf layout in the next techboard meeting.
I did some quick tests, and it appears to me that just moving the pool
pointer to the first cache line has not a significant impact.
However, I agree with Morten that there is some room for optimization
around m->pool: I did a hack in the ixgbe driver to assume there is only
one mbuf pool. This simplifies a lot the freeing of mbufs in Tx, because
we don't have to group them in bulks that shares the same pool (see
ixgbe_tx_free_bufs()). The impact of this hack is quite good: +~5% on a
real-life forwarding use case.
It is maybe possible to store the pool in the sw ring to avoid a later
access to m->pool. Having a pool index as suggested by Morten would also
help to reduce used room in sw ring in this case. But this is a bit
off-topic :)
> > > I propose that the techboard considers this from two angels:
> > >
> > > 1. Long term goals and their relative priority. I.e. what can be
> > achieved with
> > > wide-ranging modifications, requiring yet another ABI break and due
> > notices.
> > >
> > > 2. Short term goals, i.e. what can be achieved for this release.
> > >
> > >
> > > My suggestions follow...
> > >
> > > 1. Regarding long term goals:
> > >
> > > I have argued that simple forwarding of non-segmented packets using
> > only the
> > > first mbuf cache line can be achieved by making three
> > > modifications:
> > >
> > > a) Move m->tx_offload to the first cache line.
> > Not all PMDs use this field on Tx. HW might support the checksum
> > offloads
> > directly, not requiring these fields at all.
To me, a driver should use m->tx_offload, because the application
specifies the offset where the checksum has to be done, in case the hw
is not able to recognize the protocol.
> > > b) Use an 8 bit pktmbuf mempool index in the first cache line,
> > > instead of the 64 bit m->pool pointer in the second cache line.
> > 256 mpool looks enough, as for me. Regarding the indirect access to the
> > pool
> > (via some table) - it might introduce some performance impact.
>
> It might, but I hope that it is negligible, so the benefits outweigh the disadvantages.
>
> It would have to be measured, though.
>
> And m->pool is only used for free()'ing (and detach()'ing) mbufs.
>
> > For example,
> > mlx5 PMD strongly relies on pool field for allocating mbufs in Rx
> > datapath.
> > We're going to update (o-o, we found point to optimize), but for now it
> > does.
>
> Without looking at the source code, I don't think the PMD is using m->pool in the RX datapath, I think it is using a pool dedicated to a receive queue used for RX descriptors in the PMD (i.e. driver->queue->pool).
>
> >
> > > c) Do not access m->next when we know that it is NULL.
> > > We can use m->nb_segs == 1 or some other invariant as the gate.
> > > It can be implemented by adding an m->next accessor function:
> > > struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> > > {
> > > return m->nb_segs == 1 ? NULL : m->next;
> > > }
> >
> > Sorry, not sure about this. IIRC, nb_segs is valid in the first
> > segment/mbuf only.
> > If we have the 4 segments in the pkt we see nb_seg=4 in the first one,
> > and the nb_seg=1
> > in the others. The next field is NULL in the last mbuf only. Am I wrong
> > and miss something ?
>
> You are correct.
>
> This would have to be updated too. Either by increasing m->nb_seg in the following segments, or by splitting up relevant functions into functions for working on first segments (incl. non-segmented packets), and functions for working on following segments of segmented packets.
Instead of maintaining a valid nb_segs, a HAS_NEXT flag would be easier
to implement. However it means that an accessor needs to be used instead
of any m->next access.
> > > Regarding the priority of this goal, I guess that simple forwarding
> > of non-
> > > segmented packets is probably the path taken by the majority of
> > packets
> > > handled by DPDK.
> > >
> > > An alternative goal could be:
> > > Do not touch the second cache line during RX.
> > > A comment in the mbuf structure says so, but it is not true anymore.
> > >
> > > (I guess that regression testing didn't catch this because the tests
> > perform TX
> > > immediately after RX, so the cache miss just moves from the TX to the
> > RX part
> > > of the test application.)
> > >
> > >
> > > 2. Regarding short term goals:
> > >
> > > The current DPDK source code looks to me like m->next is the most
> > frequently
> > > accessed field in the second cache line, so it makes sense moving
> > this to the
> > > first cache line, rather than m->pool.
> > > Benchmarking may help here.
> >
> > Moreover, for the segmented packets the packet size is supposed to be
> > large,
> > and it imposes the relatively low packet rate, so probably optimization
> > of
> > moving next to the 1st cache line might be negligible at all. Just
> > compare 148Mpps of
> > 64B pkts and 4Mpps of 3000B pkts over 100Gbps link. Currently we are on
> > benchmarking
> > and did not succeed yet on difference finding. The benefit can't be
> > expressed in mpps delta,
> > we should measure CPU clocks, but Rx queue is almost always empty - we
> > have an empty
> > loops. So, if we have the boost - it is extremely hard to catch one.
>
> Very good point regarding the value of such an optimization, Slava!
>
> And when free()'ing packets, both m->next and m->pool are touched.
>
> So perhaps the free()/detach() functions in the mbuf library can be modified to handle first segments (and non-segmented packets) and following segments differently, so accessing m->next can be avoided for non-segmented packets. Then m->pool should be moved to the first cache line.
>
I also think that Moving m->pool without doing something else about
m->next is probably useless. And it's too late for 20.11 to do
additionnal changes, so I suggest to postpone the field move to 21.11,
once we have a clearer view of possible optimizations.
Olivier
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [RFC v3 2/2] ethdev: introduce sft lib
@ 2020-11-04 13:17 1% ` Ori Kam
0 siblings, 0 replies; 200+ results
From: Ori Kam @ 2020-11-04 13:17 UTC (permalink / raw)
To: andreyv, mdr
Cc: alexr, andrey.vesnovaty, arybchenko, dev, elibr, ferruh.yigit,
orika, ozsh, roniba, thomas, viacheslavo
Defines RTE SFT (Stateful Flow Table) APIs for Stateful Flow Table library.
Currently, DPDK enables only stateless offloading, using the rte_flow.
stateless means that each packet is handled without any knowledge of
previous or future packets.
As we look at the industry, there is much demand to save a context across
packets that belong to a connection.
Examples for such applications:
- Next-generation firewalls
- Intrusion detection/prevention systems (IDS/IPS): Suricata, snort
- SW/Virtual Switching: OVS
The goals of the SFT library:
- Accelerate flow recognition & its context retrieval for further
lookaside processing.
- Enable context-aware flow handling offload.
The solution suggested is to create a lib that will enable saving states
between different packets that belong to the same connection.
The solution will also enable better HW abstraction than the one we get
from using the rte_flow. The reason for this is that saving states is
not atomic action like we have in rte_flow and also can't be done fully
in HW (The first packets must be seen by the application).
Saying the above this lib is based on interacting with the rte_flow but it
doesn't replace it or encapsulate it.
Key design points.
- The SFT should offload as much as possible to HW.
- The SFT is designed to work alongside the rte_flow.
- The SFT has its own ops that the PMD needs to implement.
- The SFT works on 5 tuple + zone (a user-defined value)
Basic usage flow:
1. Application insert a flow that matches all eth traffic and have
sft action along with jump action. (in the future this jump can be
avoided and in doing so saving some jumps,
but for the most generic and complete solution we think
that allow the application full control of the packet process using
rte_flow is better.)
2. Application insert a flow in the target group that matches the packet
state. Based on this state the application performs the needed
actions. This flow can also be merged with other matching criteria.
The application will also add a flow in the target group that will
upload to the application any packet with a miss state.
3. First eth packet arrives and is routed to the SFT HW component.
since this is the first packet the SFT will have a miss and will
mark the packet with miss state and forward it to the target group.
4. The application will pull the packet from the queue and will send it to
be processed by the sft lib.
5. The SFT will extract HW packet state and if valid the zone or the
flow-id, and report it back to the application.
6. Application will see that this is a new connection, so it will issue
SFT command to create a new connection with a selected state.
The SFT will create a HW flow, that matches the 5 tuple + zone and
sets the state of the packet. The state can be any u8 value, it is
the responsibility of the application to match on the value.
7. On the next packet arriving to the HW it will jump to the SFT and
in the SFT HW there will be a match which will result in setting
the packet state and ID according to the application request.
8. In case of later miss (at some other group) or application logic
that the packet should be routed back to the application.
The application will call the SFT lib with the new mbuf,
which will result in the flow-id returned to the application
along with the context attached to this connection.
Signed-off-by: Andrey Vesnovaty <andreyv@nvidia.com>
Signed-off-by: Ori Kam <orika@nvidia.com>
---
lib/librte_ethdev/meson.build | 3 +
lib/librte_ethdev/rte_ethdev_version.map | 19 +
lib/librte_ethdev/rte_sft.c | 9 +
lib/librte_ethdev/rte_sft.h | 877 +++++++++++++++++++++++
lib/librte_ethdev/rte_sft_driver.h | 201 ++++++
5 files changed, 1109 insertions(+)
create mode 100644 lib/librte_ethdev/rte_sft.c
create mode 100644 lib/librte_ethdev/rte_sft.h
create mode 100644 lib/librte_ethdev/rte_sft_driver.h
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index 8fc24e8c8a..064e3c9443 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -9,6 +9,7 @@ sources = files('ethdev_private.c',
'rte_ethdev.c',
'rte_flow.c',
'rte_mtr.c',
+ 'rte_sft.c',
'rte_tm.c')
headers = files('rte_ethdev.h',
@@ -24,6 +25,8 @@ headers = files('rte_ethdev.h',
'rte_flow_driver.h',
'rte_mtr.h',
'rte_mtr_driver.h',
+ 'rte_sft.h',
+ 'rte_sft_driver.h',
'rte_tm.h',
'rte_tm_driver.h')
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index f8a0945812..e3c829b494 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -232,6 +232,25 @@ EXPERIMENTAL {
rte_eth_fec_get_capability;
rte_eth_fec_get;
rte_eth_fec_set;
+ rte_sft_drain_mbuf;
+ rte_sft_fini;
+ rte_sft_flow_activate;
+ rte_sft_flow_create;
+ rte_sft_flow_destroy;
+ rte_sft_flow_get_client_obj;
+ rte_sft_flow_get_status;
+ rte_sft_flow_query;
+ rte_sft_flow_set_aging;
+ rte_sft_flow_set_client_obj;
+ rte_sft_flow_set_data;
+ rte_sft_flow_set_offload;
+ rte_sft_flow_set_state;
+ rte_sft_flow_touch;
+ rte_sft_init;
+ rte_sft_process_mbuf;
+ rte_sft_process_mbuf_with_zone;
+
+
};
INTERNAL {
diff --git a/lib/librte_ethdev/rte_sft.c b/lib/librte_ethdev/rte_sft.c
new file mode 100644
index 0000000000..f3d3945545
--- /dev/null
+++ b/lib/librte_ethdev/rte_sft.c
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+
+#include "rte_sft.h"
+#include "rte_sft_driver.h"
+
+/* Placeholder for RTE SFT library APIs implementation */
diff --git a/lib/librte_ethdev/rte_sft.h b/lib/librte_ethdev/rte_sft.h
new file mode 100644
index 0000000000..d295bb0b7a
--- /dev/null
+++ b/lib/librte_ethdev/rte_sft.h
@@ -0,0 +1,877 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef _RTE_SFT_H_
+#define _RTE_SFT_H_
+
+/**
+ * @file
+ *
+ * RTE SFT API
+ *
+ * Defines RTE SFT APIs for Statefull Flow Table library.
+ *
+ * The SFT lib is part of the ethdev class, the reason for this is that the main
+ * idea is to leverage the HW offload that the ethdev allow using the rte_flow.
+ *
+ * SFT General description:
+ * SFT library provides a framework for applications that need to maintain
+ * context across different packets of the connection.
+ * Examples for such applications:
+ * - Next-generation firewalls
+ * - Intrusion detection/prevention systems (IDS/IPS): Suricata, Snort
+ * - SW/Virtual Switching: OVS
+ * The goals of the SFT library:
+ * - Accelerate flow recognition & its context retrieval for further look-aside
+ * processing.
+ * - Enable context-aware flow handling offload.
+ *
+ * The SFT is designed to use HW offload to get the best performance.
+ * This is done on two levels. The first one is marking the packet with flow id
+ * to speed the lookup of the flow in the data structure.
+ * The second is done be connecting the SFT results to the rte_flow for
+ * continuing packet process.
+ *
+ * Definitions and Abbreviations:
+ * - 5-tuple: defined by:
+ * -- Source IP address
+ * -- Source port
+ * -- Destination IP address
+ * -- Destination port
+ * -- IP protocol number
+ * - 7-tuple: 5-tuple, zone and port (see struct rte_sft_7tuple)
+ * - 5/7-tuple: 5/7-tuple of the packet from connection initiator
+ * - revers 5/7-tuple: 5/7-tuple of the packet from connection initiate
+ * - application: SFT library API consumer
+ * - APP: see application
+ * - CID: client ID
+ * - CT: connection tracking
+ * - FID: Flow identifier
+ * - FIF: First In Flow
+ * - Flow: defined by 7-tuple and its reverse i.e. flow is bidirectional
+ * - SFT: Stateful Flow Table
+ * - user: see application
+ * - zone: additional user defined value used as differentiator for
+ * connections having same 5-tuple (for example different VXLAN
+ * connections with same inner 5-tuple).
+ *
+ * SFT components:
+ *
+ * +-----------------------------------+
+ * | RTE flow |
+ * | |
+ * | +-------------------------------+ | +----------------+
+ * | | group X | | | RTE_SFT |
+ * | | | | | |
+ * | | +---------------------------+ | | | |
+ * | | | rule ... | | | | |
+ * | | | . | | | +-----------+----+
+ * | | | . | | | |
+ * | | | . | | | entry
+ * | | +---------------------------+ | | create
+ * | | | rule | | | |
+ * | | | patterns ... +---------+ |
+ * | | | actions | | | | |
+ * | | | SFT (zone=Z) | | | | |
+ * | | | JUMP (group=Y) | | | lookup |
+ * | | +---------------------------+ | | zone=Z, |
+ * | | | rule ... | | | 5tuple |
+ * | | | . | | | | |
+ * | | | . | | | +--v-------------+
+ * | | | . | | | | SFT | |
+ * | | | | | | | | |
+ * | | +---------------------------+ | | | +--v--+ |
+ * | | | | | | | |
+ * | +-------------------------------+ | | | PMD | |
+ * | | | | | |
+ * | | | +-----+ |
+ * | +-------------------------------+ | | |
+ * | | group Y | | | |
+ * | | | | | set state |
+ * | | +---------------------------+ | | | set data |
+ * | | | rule | | | +--------+-------+
+ * | | | patterns | | | |
+ * | | | SFT (state=UNDEFINED) | | | |
+ * | | | actions RSS | | | |
+ * | | +---------------------------+ | | |
+ * | | | rule | | | |
+ * | | | patterns | | | |
+ * | | | SFT (state=INVALID) | <-------------+
+ * | | | actions DROP | | | forward
+ * | | +---------------------------+ | | group=Y
+ * | | | rule | | |
+ * | | | patterns | | |
+ * | | | SFT (state=ACCEPTED) | | |
+ * | | | actions PORT | | |
+ * | | +---------------------------+ | |
+ * | | ... | |
+ * | | | |
+ * | +-------------------------------+ |
+ * | ... |
+ * | |
+ * +-----------------------------------+
+ *
+ * SFT as datastructure:
+ * SFT can be treated as datastructure maintaining flow context across its
+ * lifetime. SFT flow entry represents bidirectional network flow and defined by
+ * 7-tuple & its reverse 7-tuple.
+ * Each entry in SFT has:
+ * - FID: 1:1 mapped & used as entry handle & encapsulating internal
+ * implementation of the entry.
+ * - State: user-defined value attached to each entry, the only library
+ * reserved value for state unset (the actual value defined by SFT
+ * configuration). The application should define flow state encodings and
+ * set it for flow via rte_sft_flow_set_ctx() than what actions should be
+ * applied on packets can be defined via related RTE flow rule matching SFT
+ * state (see rules in SFT components diagram above).
+ * - Timestamp: for the last seen in flow packet used for flow aging mechanism
+ * implementation.
+ * - Client Objects: user-defined flow contexts attached as opaques to flow.
+ * - Acceleration & offloading - utilize RTE flow capabilities, when supported
+ * (see action ``SFT``), for flow lookup acceleration and further
+ * context-aware flow handling offload.
+ * - CT state: optionally for TCP connections CT state can be maintained
+ * (see enum rte_sft_flow_ct_state).
+ * - Out of order TCP packets: optionally SFT can keep out of order TCP
+ * packets aside the flow context till the arrival of the missing in-order
+ * packet.
+ *
+ * RTE flow changes:
+ * The SFT flow state (or context) for RTE flow is defined by fields of
+ * struct rte_flow_item_sft.
+ * To utilize SFT capabilities new item and action types introduced:
+ * - item SFT: matching on SFT flow state (see RTE_FLOW_ITEM_TYPE_SFT).
+ * - action SFT: retrieve SFT flow context and attached it to the processed
+ * packet (see RTE_FLOW_ACTION_TYPE_SFT).
+ *
+ * The contents of per port SFT serving RTE flow action ``SFT`` managed via
+ * SFT PMD APIs (see struct rte_sft_ops).
+ * The SFT flow state/context retrieval performed by user-defined zone ``SFT``
+ * action argument and processed packet 5-tuple.
+ * If in scope of action ``SFT`` there is no context/state for the flow in SFT
+ * undefined state attached to the packet meaning that the flow is not
+ * recognized by SFT, most probably FIF packet.
+ *
+ * Once the SFT state set for a packet it can match on item SFT
+ * (see RTE_FLOW_ITEM_TYPE_SFT) and forwarding design can be done for the
+ * packet, for example:
+ * - if state value == x than queue for further processing by the application
+ * - if state value == y than forward it to eth port (full offload)
+ * - if state value == 'undefined' than queue for further processing by
+ * the application (handle FIF packets)
+ *
+ * Processing packets with SFT library:
+ *
+ * FIF packet:
+ * To recognize upcoming packets of the SFT flow every FIF packet should be
+ * forwarded to the application utilizing the SFT library. Non-FIF packets can
+ * be processed by the application or its processing can be fully offloaded.
+ * Processing of the packets in SFT library starts with rte_sft_process_mbuf
+ * or rte_sft_process_mbuf_with_zone. If mbuf recognized as FIF application
+ * should make a design to destroy flow or complete flow creation process in
+ * SFT using rte_sft_flow_activate.
+ *
+ * Recognized SFT flow:
+ * Once struct rte_sft_flow_status with valid fid field possessed by application
+ * it can:
+ * - mange client objects on it (see client_obj field in
+ * struct rte_sft_flow_status) using rte_sft_flow_<OP>_client_obj APIs
+ * - analyze user-defined flow state and CT state.
+ * - set flow state to be attached to the upcoming packets by action ``SFT``
+ * via struct rte_sft_flow_status API.
+ * - decide to destroy flow via rte_sft_flow_destroy API.
+ *
+ * Flow aging:
+ *
+ * SFT library manages the aging for each flow. On flow creation, it's
+ * assigned an aging value, the maximal number of seconds passed since the
+ * last flow packet arrived, once exceeded flow considered aged.
+ * The application notified of aged flow asynchronously via event queues.
+ * The device and port IDs tuple to identify the event queue to enqueue
+ * flow aged events passed on flow creation as arguments
+ * (see rte_sft_flow_activate). It's the application responsibility to
+ * initialize event queues and assign them to each flow for EOF event
+ * notifications.
+ * Aged EOF event handling:
+ * - Should be considered as application responsibility.
+ * - The last stage should be the release of the flow resources via
+ * rte_sft_flow_destroy API.
+ * - All client objects should be removed from flow before the
+ * rte_sft_flow_destroy API call.
+ * See the description of ret_sft_flow_destroy for an example of aged flow
+ * handling.
+ *
+ * SFT API thread safety:
+ *
+ * Since the SFT lib is designed to work as part of the Fast-Path, The SFT
+ * is not thread safe, in order to enable better working with multiple threads
+ * the SFT lib uses the queue approach, where each queue can only be accessesd
+ * by one thread while one thread can access multiple queues.
+ *
+ * SFT Library initialization and cleanup:
+ *
+ * SFT library should be considered as a single instance, preconfigured and
+ * initialized via rte_sft_init() API.
+ * SFT library resource deallocation and cleanup should be done via
+ * rte_sft_init() API as a stage of the application termination procedure.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_config.h>
+#include <rte_errno.h>
+#include <rte_mbuf.h>
+#include <rte_ethdev.h>
+#include <rte_flow.h>
+
+/**
+ * L3/L4 5-tuple - src/dest IP and port and IP protocol.
+ *
+ * Used for flow/connection identification.
+ */
+RTE_STD_C11
+struct rte_sft_5tuple {
+ union {
+ struct {
+ rte_be32_t src_addr; /**< IPv4 source address. */
+ rte_be32_t dst_addr; /**< IPv4 destination address. */
+ } ipv4;
+ struct {
+ uint8_t src_addr[16]; /**< IPv6 source address. */
+ uint8_t dst_addr[16]; /**< IPv6 destination address. */
+ } ipv6;
+ };
+ rte_be16_t src_port; /**< Source port. */
+ rte_be16_t dst_port; /**< Destination port. */
+ uint8_t proto; /**< IP protocol. */
+ uint8_t is_ipv6: 1; /**< True for valid IPv6 fields. Otherwise IPv4. */
+};
+
+/**
+ * Port flow identification.
+ *
+ * @p zone used for setups where 5-tuple is not enough to identify flow.
+ * For example different VLANs/VXLANs may have similar 5-tuples.
+ */
+struct rte_sft_7tuple {
+ struct rte_sft_5tuple flow_5tuple; /**< L3/L4 5-tuple. */
+ uint32_t zone; /**< Zone assigned to flow. */
+ uint16_t port_id; /** <Port identifier of Ethernet device. */
+};
+
+/**
+ * Structure describes SFT library configuration
+ */
+struct rte_sft_conf {
+ uint16_t nb_queues; /**< Preferred number of queues */
+ uint32_t udp_aging; /**< UDP proto default aging in sec */
+ uint32_t tcp_aging; /**< TCP proto default aging in sec */
+ uint32_t tcp_syn_aging; /**< TCP SYN default aging in sec. */
+ uint32_t default_aging; /**< All unlisted proto default aging in sec. */
+ uint32_t nb_max_entries; /**< Max entries in SFT. */
+ uint8_t app_data_len; /**< Number of uint32 of app data. */
+ uint32_t support_partial_match: 1;
+ /**< App can partial match on the data. */
+ uint32_t reorder_enable: 1;
+ /**< TCP packet reordering feature enabled bit. */
+ uint32_t tcp_ct_enable: 1;
+ /**< TCP connection tracking based on standard. */
+ uint32_t reserved: 30;
+};
+
+/**
+ * Structure that holds the action configuration.
+ */
+struct rte_sft_actions_specs {
+ struct rte_sft_5tuple *initiator_nat;
+ /**< The NAT configuration for the initiator flow. */
+ struct rte_sft_5tuple *reverse_nat;
+ /**< The NAT configuration for the reverse flow. */
+ uint64_t aging; /**< the aging time out in sec. */
+};
+
+#define RTE_SFT_ACTION_INITIATOR_NAT (1ul << 0)
+/**< NAT action should be done on the initiator traffic. */
+#define RTE_SFT_ACTION_REVERSE_NAT (1ul << 1)
+/**< NAT action should be done on the reverse traffic. */
+#define RTE_SFT_ACTION_COUNT (1ul << 2) /**< Enable count action. */
+#define RTE_SFT_ACTION_AGE (1ul << 3) /**< Enable ageing action. */
+
+
+/**
+ * Structure that holds the count data.
+ */
+struct rte_sft_query_data {
+ uint64_t nb_bytes; /**< Number of bytes that passed in the flow. */
+ uint64_t nb_packets; /**< Number of packets that passed in the flow. */
+ uint32_t age; /**< Seconds passed since last seen packet. */
+ uint32_t aging;
+ /**< Flow considered aged once this age (seconds) reached. */
+ uint32_t nb_bytes_valid: 1; /**< Number of bytes is valid. */
+ uint32_t nb_packets_valid: 1; /* Number of packets is valid. */
+ uint32_t nb_age_valid: 1; /* Age is valid. */
+ uint32_t nb_aging_valid: 1; /* Aging is valid. */
+ uint32_t reserved: 28;
+};
+
+/**
+ * Structure describes the state of the flow in SFT.
+ */
+struct rte_sft_flow_status {
+ uint32_t fid; /**< SFT flow id. */
+ uint32_t zone; /**< Zone for lookup in SFT */
+ uint8_t state; /**< Application defined bidirectional flow state. */
+ uint8_t proto_state; /**< The state based on the protocol. */
+ uint16_t proto; /**< L4 protocol. */
+ /**< Connection tracking flow state, based on standard. */
+ uint32_t nb_in_order_mbufs;
+ /**< Number of in-order mbufs available for drain */
+ uint32_t activated: 1; /**< Flow was activated. */
+ uint32_t zone_valid: 1; /**< Zone field is valid. */
+ uint32_t proto_state_change: 1; /**< Protocol state was changed. */
+ uint32_t fragmented: 1; /**< Last flow mbuf was fragmented. */
+ uint32_t out_of_order: 1; /**< Last flow mbuf was out of order (TCP). */
+ uint32_t offloaded: 1;
+ /**< The connection is offload and no packet should be stored. */
+ uint32_t initiator: 1; /**< marks if the mbuf is from the initiator. */
+ uint32_t reserved: 25;
+ uint32_t data[];
+ /**< Application data. The length is defined by the configuration. */
+};
+
+/**
+ * Verbose error types.
+ *
+ * Most of them provide the type of the object referenced by struct
+ * rte_flow_error.cause.
+ */
+enum rte_sft_error_type {
+ RTE_SFT_ERROR_TYPE_NONE, /**< No error. */
+ RTE_SFT_ERROR_TYPE_UNSPECIFIED, /**< Cause unspecified. */
+ RTE_SFT_ERROR_TYPE_FLOW_NOT_DEFINED, /**< The FID is not defined. */
+};
+
+/**
+ * Verbose error structure definition.
+ *
+ * This object is normally allocated by applications and set by SFT, the
+ * message points to a constant string which does not need to be freed by
+ * the application, however its pointer can be considered valid only as long
+ * as its associated DPDK port remains configured. Closing the underlying
+ * device or unloading the PMD invalidates it.
+ *
+ * Both cause and message may be NULL regardless of the error type.
+ */
+struct rte_sft_error {
+ enum rte_sft_error_type type; /**< Cause field and error types. */
+ const void *cause; /**< Object responsible for the error. */
+ const char *message; /**< Human-readable error message. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get SFT flow status, based on the fid.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] status
+ * Structure to dump actual SFT flow status.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_get_status(const uint16_t queue, const uint32_t fid,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set user defined data.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param data
+ * User defined data. The len is defined at configuration time.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_data(uint16_t queue, uint32_t fid, const uint32_t *data,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set user defined state.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param state
+ * User state.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_state(uint16_t queue, uint32_t fid, const uint8_t state,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set user defined state.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param offload
+ * set if flow is offloaded.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_offload(uint16_t queue, uint32_t fid, bool offload,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Initialize SFT library instance.
+ *
+ * @param conf
+ * SFT library instance configuration.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_init(const struct rte_sft_conf *conf, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Finalize SFT library instance.
+ * Cleanup & release allocated resources.
+ */
+__rte_experimental
+void
+rte_sft_fini(void);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Process mbuf received on RX queue.
+ *
+ * This function checks the mbuf against the SFT database and return the
+ * connection status that this mbuf belongs to.
+ *
+ * If status.activated = 1 and status.offloaded = 0 the input mbuf is
+ * considered consumed and the application is not allowed to use it or free it,
+ * instead the application should use the mbuf pointed by the mbuf_out.
+ * In case the mbuf is out of order or fragmented the mbuf_out will be NULL.
+ *
+ * If status.activated = 0 or status.offloaded = 1, the input mbuf is not
+ * consumed and the mbuf_out will always be NULL.
+ *
+ * This function doesn't create new entry in the SFT.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param[in] mbuf_in
+ * mbuf to process; mbuf pointer considered 'consumed' and should not be used
+ * if status.activated and status.offload = 0.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param[out] status
+ * Connection status based on the last in mbuf.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Initialize in case of
+ * error only.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_process_mbuf(uint16_t queue, struct rte_mbuf *mbuf_in,
+ struct rte_mbuf **mbuf_out,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Process mbuf received on RX queue while zone value provided by caller.
+ *
+ * The behaviour of this function is similar to rte_sft_process_mbuf except
+ * the lookup in SFT procedure. The lookup in SFT always done by the *zone*
+ * arg and 5-tuple 5-tuple, extracted form mbuf outer header contents.
+ *
+ * @see rte_sft_process_mbuf
+ *
+ * @param queue
+ * The sft queue number.
+ * @param[in] mbuf_in
+ * mbuf to process; mbuf pointer considered 'consumed' and should not be used
+ * after successful call to this function.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param[out] status
+ * Connection status based on the last in mbuf.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Initialize in case of
+ * error only.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_process_mbuf_with_zone(uint16_t queue, struct rte_mbuf *mbuf_in,
+ uint32_t zone, struct rte_mbuf **mbuf_out,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Drain next in order mbuf.
+ *
+ * This function behaves similar to rte_sft_process_mbuf() but acts on packets
+ * accumulated in SFT flow due to missing in order packet. Processing done on
+ * single mbuf at a time and `in order`. Other than above the behavior is
+ * same as of rte_sft_process_mbuf for flow defined & activated & mbuf isn't
+ * fragmented & 'in order'. This function should be called when
+ * rte_sft_process_mbuf or rte_sft_process_mbuf_with_zone sets
+ * status->nb_in_order_mbufs output param !=0 and until
+ * status->nb_in_order_mbufs == 0.
+ * Flow should be locked by caller (see rte_sft_flow_lock).
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param nb_out
+ * Number of buffers to be drained.
+ * @param initiator
+ * true packets that will be drained belongs to the initiator.
+ * @param[out] status
+ * Connection status based on the last mbuf that was drained.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Initialize in case of
+ * error only.
+ *
+ * @return
+ * The number of mbufs that were drained, negative value in case
+ * of error and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_drain_mbuf(uint16_t queue, uint32_t fid, struct rte_mbuf **mbuf_out,
+ uint16_t nb_out, bool initiator,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Activate flow in SFT.
+ *
+ * This function creates an entry in the SFT for this connection.
+ * The reasons for 2 phase flow creation procedure:
+ * 1. Missing reverse flow - flow context is shared for both flow directions
+ * i.e. in order maintain bidirectional flow context in RTE SFT packets
+ * arriving from both directions should be identified as packets of the
+ * RTE SFT flow. Consequently, before the creation of the SFT flow caller
+ * should provide reverse flow direction 7-tuple.
+ * 2. The caller of rte_sft_process_mbuf/rte_sft_process_mbuf_with_zone should
+ * be notified that arrived mbuf is first in flow & decide whether to
+ * create a new flow or disregard this packet.
+ * This function completes the creation of the bidirectional SFT flow & creates
+ * entry for 7-tuple on SFT PMD defined by the tuple port for both
+ * initiator/initiate 7-tuples.
+ * Flow aging, connection tracking state & out of order handling will be
+ * initialized according to the content of the *mbuf_in* passes to
+ * rte_sft_process_mbuf/_with_zone during phase 1 of flow creation.
+ * Once this function returns upcoming calls rte_sft_process_mbuf/_with_zone
+ * with 7-tuple or its reverse will return the handle to this flow.
+ * Flow should be locked by the caller (see rte_sft_flow_lock).
+ *
+ * @param queue
+ * The SFT queue.
+ * @param[in] mbuf_in
+ * mbuf to process; mbuf pointer considered 'consumed' and should not be used
+ * after successful call to this function.
+ * @param reverse_tuple
+ * Expected response flow 7-tuple.
+ * @param state
+ * User defined state to set.
+ * @param data
+ * User defined data, the len is configured during sft init.
+ * @param proto_enable
+ * Enables maintenance of status->proto_state connection tracking value
+ * for the flow. otherwise status->proto_state will be initialized with zeros.
+ * @param dev_id
+ * Event dev ID to enqueue end of flow event.
+ * @param port_id
+ * Event port ID to enqueue end of flow event.
+ * @param actions
+ * Flags that indicate which actions should be done on the packet before
+ * returning it to the rte_flow.
+ * @param action_specs
+ * Hold the actions configuration.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param[out] status
+ * Structure to dump SFT flow status once activated.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_activate(uint16_t queue, struct rte_mbuf *mbuf_in,
+ const struct rte_sft_7tuple *reverse_tuple,
+ uint8_t state, uint32_t *data, uint8_t proto_enable,
+ uint8_t dev_id, uint8_t port_id, uint64_t actions,
+ const struct rte_sft_actions_specs *action_specs,
+ struct rte_mbuf **mbuf_out,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Artificially create SFT flow.
+ *
+ * Function to create SFT flow before reception of the first flow packet.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param tuple
+ * Expected initiator flow 7-tuple.
+ * @param reverse_tuple
+ * Expected initiate flow 7-tuple.
+ * @param state
+ * User defined state to set.
+ * @param data
+ * User defined data, the len is configured during sft init.
+ * @param proto_enable
+ * Enables maintenance of status->proto_state connection tracking value
+ * for the flow. otherwise status->proto_state will be initialized with zeros.
+ * @param[out] status
+ * Connection status.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. PMDs initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * - on success: 0, locked SFT flow recognized by status->fid.
+ * - on error: a negative errno value otherwise and rte_errno is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_create(uint16_t queue, const struct rte_sft_7tuple *tuple,
+ const struct rte_sft_7tuple *reverse_tuple,
+ const struct rte_flow_item_sft *ctx,
+ uint8_t ct_enable,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Removes flow from SFT.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID to destroy.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_destroy(uint16_t queue, uint32_t fid, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Query counter and aging data.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] data.
+ * SFT flow ID.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_query(uint16_t queue, uint32_t fid,
+ struct rte_sft_query_data *data,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Reset flow age to zero.
+ *
+ * Simulates last flow packet with timestamp set to just now.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_touch(uint16_t queue, uint32_t fid, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set flow aging to specific value.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param aging
+ * New flow aging value.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_aging(uint16_t queue, uint32_t fid, uint32_t aging,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set client object for given client ID.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param client_id
+ * Client ID to set object for.
+ * @param client_obj
+ * Pointer to opaque client object structure.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_client_obj(uint16_t queue, uint32_t fid, uint8_t client_id,
+ void *client_obj, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get client object for given client ID.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param client_id
+ * Client ID to get object for.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * A valid client object opaque pointer in case of success, NULL otherwise
+ * and rte_sft_error is set.
+ */
+__rte_experimental
+void *
+rte_sft_flow_get_client_obj(uint16_t queue, const uint32_t fid,
+ uint8_t client_id, struct rte_sft_error *error);
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_SFT_H_ */
diff --git a/lib/librte_ethdev/rte_sft_driver.h b/lib/librte_ethdev/rte_sft_driver.h
new file mode 100644
index 0000000000..6ae3c4b997
--- /dev/null
+++ b/lib/librte_ethdev/rte_sft_driver.h
@@ -0,0 +1,201 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef RTE_SFT_DRIVER_H_
+#define RTE_SFT_DRIVER_H_
+
+/**
+ * @file
+ * RTE generic SFT API (driver side)
+ *
+ * This file provides implementation helpers for internal use by PMDs, they
+ * are not intended to be exposed to applications and are not subject to ABI
+ * versioning.
+ */
+
+#include <stdint.h>
+
+#include "rte_ethdev.h"
+#include "rte_ethdev_driver.h"
+#include "rte_sft.h"
+#include "rte_flow.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+struct rte_sft_entry;
+
+#define RTE_SFT_STATE_FLAG_FID_VALID (1 << 0)
+#define RTE_SFT_STATE_FLAG_ZONE_VALID (1 << 1)
+#define RTE_SFT_STATE_FLAG_FLOW_MISS (1 << 2)
+
+#define RTE_SFT_MISS_TCP_FLAGS (1 << 0)
+
+RTE_STD_C11
+struct rte_sft_decode_info {
+ union {
+ uint32_t fid; /**< The fid value. */
+ uint32_t zone; /**< The zone value. */
+ };
+ uint32_t state;
+ /**< Flags that mark the packet state. see RTE_SFT_STATE_FLAG_*. */
+};
+
+/**
+ * @internal
+ * Insert a flow to the SFT HW component.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param fid
+ * Flow ID.
+ * @param queue
+ * The sft working queue.
+ * @param pattern
+ * The matching pattern.
+ * @param miss_conditions
+ * The conditions that forces a miss even if the 5 tuple was matched
+ * see RTE_SFT_MISS_*.
+ * @param actions
+ * Set pf actions to apply in case the flow was hit. If no terminating action
+ * (queue, rss, drop, port) was given, the terminating action should be taken
+ * from the flow that resulted in the SFT.
+ * @param miss_actions
+ * Set pf actions to apply in case the flow was hit. but the miss conditions
+ * were hit. (6 tuple match but tcp flags are on) If no terminating action
+ * (queue, rss, drop, port) was given, the terminating action should be taken
+ * from the flow that resulted in the SFT.
+ * @param data
+ * The application data to attached to the flow.
+ * @param data_len
+ * The length of the data in uint32_t increments.
+ * @param state
+ * The application state to set.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Pointer to sft_entry in case of success, null otherwise and rte_sft_error
+ * is set.
+ */
+typedef struct rte_sft_entry *(*sft_entry_create_t)
+ (struct rte_eth_dev *dev, uint32_t fid, uint16_t queue,
+ const struct rte_flow_item *pattern, uint64_t miss_conditions,
+ const struct rte_flow_action *actions,
+ const struct rte_flow_action *miss_actions,
+ const uint32_t *data, uint16_t data_len, uint8_t state,
+ struct rte_sft_error *error);
+
+/**
+ * @internal
+ * Modify the state and the data of SFT flow in HW component.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param entry
+ * The entry to modify.
+ * @param queue
+ * The sft working queue.
+ * @param data
+ * The application data to attached to the flow.
+ * @param data_len
+ * The length of the data in uint32_t increments.
+ * @param state
+ * The application state to set.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Negative errno value on error, 0 on success.
+ */
+typedef int *(*sft_entry_modify_t)(struct rte_eth_dev *dev,
+ struct rte_sft_entry *entry, uint16_t queue,
+ const uint32_t *data, uint16_t data_len,
+ uint8_t state, struct rte_sft_error *error);
+
+/**
+ * @internal
+ * Destroy SFT flow in HW component.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param entry
+ * The entry to modify.
+ * @param queue
+ * The sft working queue.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Negative errno value on error, 0 on success.
+ */
+typedef int *(*sft_entry_destroy_t)(struct rte_eth_dev *dev,
+ struct rte_sft_entry *entry, uint16_t queue,
+ struct rte_sft_error *error);
+
+/**
+ * @internal
+ * Decode sft state and FID from mbuf.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param entry
+ * The entry to modify.
+ * @param queue
+ * The sft working queue.
+ * @param mbuf
+ * The input mbuf.
+ * @param info[out]
+ * The decoded sft data.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Negative errno value on error, 0 on success.
+ */
+typedef int *(*sft_entry_decode_t)(struct rte_eth_dev *dev,
+ struct rte_sft_entry *entry, uint16_t queue,
+ struct rte_mbuf *mbuf,
+ struct rte_sft_decode_info *info,
+ struct rte_sft_error *error);
+
+/**
+ * Generic sft operations structure implemented and returned by PMDs.
+ *
+ * If successful, this operation must result in a pointer to a PMD-specific.
+ *
+ * See also rte_sft_ops_get().
+ *
+ * These callback functions are not supposed to be used by applications
+ * directly, which must rely on the API defined in rte_sft.h.
+ */
+struct rte_sft_ops {
+ sft_entry_create_t sft_create_entry;
+ sft_entry_modify_t sft_entry_modify;
+ sft_entry_destroy_t sft_entry_destroy;
+ sft_entry_decode_t sft_entry_decode;
+};
+
+/**
+ * Get generic sft operations structure from a port.
+ *
+ * @param port_id
+ * Port identifier to query.
+ * @param[out] error
+ * Pointer to flow error structure.
+ *
+ * @return
+ * The flow operations structure associated with port_id, NULL in case of
+ * error, in which case rte_errno is set and the error structure contains
+ * additional details.
+ */
+const struct rte_sft_ops *
+rte_sft_ops_get(uint16_t port_id, struct rte_sft_error *error);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_SFT_DRIVER_H_ */
--
2.25.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 2/2] ethdev: introduce sft lib
@ 2020-11-04 12:59 1% ` Ori Kam
0 siblings, 0 replies; 200+ results
From: Ori Kam @ 2020-11-04 12:59 UTC (permalink / raw)
To: andreyv, mdr
Cc: alexr, andrey.vesnovaty, arybchenko, dev, elibr, ferruh.yigit,
orika, ozsh, roniba, thomas, viacheslavo
Defines RTE SFT (Stateful Flow Table) APIs for Stateful Flow Table library.
Currently, DPDK enables only stateless offloading, using the rte_flow.
stateless means that each packet is handled without any knowledge of
privious or future packets.
As we look at the industry, there is much demand to save a context across
packets that belong to a connection.
Examples for such applications:
- Next-generation firewalls
- Intrusion detection/prevention systems (IDS/IPS): Suricata, snort
- SW/Virtual Switching: OVS
The goals of the SFT library:
- Accelerate flow recognition & its context retrieval for further
lookaside processing.
- Enable context-aware flow handling offload.
The solution suggested is to create a lib that will enable saving states
between different packets that belong to the same connection.
The solution will also enable better HW abstraction than the one we get
from using the rte_flow. The reason for this is that saving states is
not atomic action like we have in rte_flow and also can't be done fully
in HW (The first packets must be seen by the application).
Saying the above this lib is based on interacting with the rte_flow but it
doesn't replace it or encapsulate it.
Key design points.
- The SFT should offload as much as possible to HW.
- The SFT is designed to work alongside the rte_flow.
- The SFT has its own ops that the PMD needs to implement.
- The SFT works on 5 tuple + zone (a user-defined value)
Basic usage flow:
1. Application insert a flow that matches all eth traffic and have
sft action along with jump action. (in the future this jump can be
avoided and in doing so saving some jumps,
but for the most generic and complete solution we think
that allow the application full control of the packet process using
rte_flow is better.)
2. Application insert a flow in the target group that matches the packet
state. Based on this state the application performs the needed
actions. This flow can also be merged with other matching criteria.
The application will also add a flow in the target group that will
upload to the application any packet with a miss state.
3. First eth packet arrives and is routed to the SFT HW component.
since this is the first packet the SFT will have a miss and will
mark the packet with miss state and forward it to the target group.
4. The application will pull the packet from the queue and will send it to
be processed by the sft lib.
5. The SFT will extract HW packet state and if valid the zone or the
flow-id, and report it back to the application.
6. Application will see that this is a new connection, so it will issue
SFT command to create a new connection with a selected state.
The SFT will create a HW flow, that matches the 5 tuple + zone and
sets the state of the packet. The state can be any u8 value, it is
the responsibility of the application to match on the value.
7. On the next packet arriving to the HW it will jump to the SFT and
in the SFT HW there will be a match which will result in setting
the packet state and ID according to the application request.
8. In case of later miss (at some other group) or application logic
that the packet should be routed back to the application.
The application will call the SFT lib with the new mbuf,
which will result in the flow-id returend to the application
along with the context attached to this connection.
Signed-off-by: Andrey Vesnovaty <andreyv@nvidia.com>
Signed-off-by: Ori Kam <orika@nvidia.com>
---
lib/librte_ethdev/meson.build | 3 +
lib/librte_ethdev/rte_ethdev_version.map | 19 +
lib/librte_ethdev/rte_sft.c | 9 +
lib/librte_ethdev/rte_sft.h | 878 +++++++++++++++++++++++
lib/librte_ethdev/rte_sft_driver.h | 201 ++++++
5 files changed, 1110 insertions(+)
create mode 100644 lib/librte_ethdev/rte_sft.c
create mode 100644 lib/librte_ethdev/rte_sft.h
create mode 100644 lib/librte_ethdev/rte_sft_driver.h
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index 8fc24e8c8a..064e3c9443 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -9,6 +9,7 @@ sources = files('ethdev_private.c',
'rte_ethdev.c',
'rte_flow.c',
'rte_mtr.c',
+ 'rte_sft.c',
'rte_tm.c')
headers = files('rte_ethdev.h',
@@ -24,6 +25,8 @@ headers = files('rte_ethdev.h',
'rte_flow_driver.h',
'rte_mtr.h',
'rte_mtr_driver.h',
+ 'rte_sft.h',
+ 'rte_sft_driver.h',
'rte_tm.h',
'rte_tm_driver.h')
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index f8a0945812..e3c829b494 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -232,6 +232,25 @@ EXPERIMENTAL {
rte_eth_fec_get_capability;
rte_eth_fec_get;
rte_eth_fec_set;
+ rte_sft_drain_mbuf;
+ rte_sft_fini;
+ rte_sft_flow_activate;
+ rte_sft_flow_create;
+ rte_sft_flow_destroy;
+ rte_sft_flow_get_client_obj;
+ rte_sft_flow_get_status;
+ rte_sft_flow_query;
+ rte_sft_flow_set_aging;
+ rte_sft_flow_set_client_obj;
+ rte_sft_flow_set_data;
+ rte_sft_flow_set_offload;
+ rte_sft_flow_set_state;
+ rte_sft_flow_touch;
+ rte_sft_init;
+ rte_sft_process_mbuf;
+ rte_sft_process_mbuf_with_zone;
+
+
};
INTERNAL {
diff --git a/lib/librte_ethdev/rte_sft.c b/lib/librte_ethdev/rte_sft.c
new file mode 100644
index 0000000000..f3d3945545
--- /dev/null
+++ b/lib/librte_ethdev/rte_sft.c
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+
+#include "rte_sft.h"
+#include "rte_sft_driver.h"
+
+/* Placeholder for RTE SFT library APIs implementation */
diff --git a/lib/librte_ethdev/rte_sft.h b/lib/librte_ethdev/rte_sft.h
new file mode 100644
index 0000000000..edd8671cad
--- /dev/null
+++ b/lib/librte_ethdev/rte_sft.h
@@ -0,0 +1,878 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef _RTE_SFT_H_
+#define _RTE_SFT_H_
+
+/**
+ * @file
+ *
+ * RTE SFT API
+ *
+ * Defines RTE SFT APIs for Statefull Flow Table library.
+ *
+ * The SFT lib is part of the ethdev class, the reason for this is that the main
+ * idea is to leverage the HW offload that the ethdev allow using the rte_flow.
+ *
+ * SFT General description:
+ * SFT library provides a framework for applications that need to maintain
+ * context across different packets of the connection.
+ * Examples for such applications:
+ * - Next-generation firewalls
+ * - Intrusion detection/prevention systems (IDS/IPS): Suricata, Snort
+ * - SW/Virtual Switching: OVS
+ * The goals of the SFT library:
+ * - Accelerate flow recognition & its context retrieval for further look-aside
+ * processing.
+ * - Enable context-aware flow handling offload.
+ *
+ * The SFT is designed to use HW offload to get the best performance.
+ * This is done on two levels. The first one is marking the packet with flow id
+ * to speed the lookup of the flow in the data structure.
+ * The second is done be connecting the SFT results to the rte_flow for
+ * continuing packet process.
+ *
+ * Definitions and Abbreviations:
+ * - 5-tuple: defined by:
+ * -- Source IP address
+ * -- Source port
+ * -- Destination IP address
+ * -- Destination port
+ * -- IP protocol number
+ * - 7-tuple: 5-tuple, zone and port (see struct rte_sft_7tuple)
+ * - 5/7-tuple: 5/7-tuple of the packet from connection initiator
+ * - revers 5/7-tuple: 5/7-tuple of the packet from connection initiate
+ * - application: SFT library API consumer
+ * - APP: see application
+ * - CID: client ID
+ * - CT: connection tracking
+ * - FID: Flow identifier
+ * - FIF: First In Flow
+ * - Flow: defined by 7-tuple and its reverse i.e. flow is bidirectional
+ * - SFT: Stateful Flow Table
+ * - user: see application
+ * - zone: additional user defined value used as differentiator for
+ * connections having same 5-tuple (for example different VXLAN
+ * connections with same inner 5-tuple).
+ *
+ * SFT components:
+ *
+ * +-----------------------------------+
+ * | RTE flow |
+ * | |
+ * | +-------------------------------+ | +----------------+
+ * | | group X | | | RTE_SFT |
+ * | | | | | |
+ * | | +---------------------------+ | | | |
+ * | | | rule ... | | | | |
+ * | | | . | | | +-----------+----+
+ * | | | . | | | |
+ * | | | . | | | entry
+ * | | +---------------------------+ | | create
+ * | | | rule | | | |
+ * | | | patterns ... +---------+ |
+ * | | | actions | | | | |
+ * | | | SFT (zone=Z) | | | | |
+ * | | | JUMP (group=Y) | | | lookup |
+ * | | +---------------------------+ | | zone=Z, |
+ * | | | rule ... | | | 5tuple |
+ * | | | . | | | | |
+ * | | | . | | | +--v-------------+
+ * | | | . | | | | SFT | |
+ * | | | | | | | | |
+ * | | +---------------------------+ | | | +--v--+ |
+ * | | | | | | | |
+ * | +-------------------------------+ | | | PMD | |
+ * | | | | | |
+ * | | | +-----+ |
+ * | +-------------------------------+ | | |
+ * | | group Y | | | |
+ * | | | | | set state |
+ * | | +---------------------------+ | | | set data |
+ * | | | rule | | | +--------+-------+
+ * | | | patterns | | | |
+ * | | | SFT (state=UNDEFINED) | | | |
+ * | | | actions RSS | | | |
+ * | | +---------------------------+ | | |
+ * | | | rule | | | |
+ * | | | patterns | | | |
+ * | | | SFT (state=INVALID) | <-------------+
+ * | | | actions DROP | | | forward
+ * | | +---------------------------+ | | group=Y
+ * | | | rule | | |
+ * | | | patterns | | |
+ * | | | SFT (state=ACCEPTED) | | |
+ * | | | actions PORT | | |
+ * | | +---------------------------+ | |
+ * | | ... | |
+ * | | | |
+ * | +-------------------------------+ |
+ * | ... |
+ * | |
+ * +-----------------------------------+
+ *
+ * SFT as datastructure:
+ * SFT can be treated as datastructure maintaining flow context across its
+ * lifetime. SFT flow entry represents bidirectional network flow and defined by
+ * 7-tuple & its reverse 7-tuple.
+ * Each entry in SFT has:
+ * - FID: 1:1 mapped & used as entry handle & encapsulating internal
+ * implementation of the entry.
+ * - State: user-defined value attached to each entry, the only library
+ * reserved value for state unset (the actual value defined by SFT
+ * configuration). The application should define flow state encodings and
+ * set it for flow via rte_sft_flow_set_ctx() than what actions should be
+ * applied on packets can be defined via related RTE flow rule matching SFT
+ * state (see rules in SFT components diagram above).
+ * - Timestamp: for the last seen in flow packet used for flow aging mechanism
+ * implementation.
+ * - Client Objects: user-defined flow contexts attached as opaques to flow.
+ * - Acceleration & offloading - utilize RTE flow capabilities, when supported
+ * (see action ``SFT``), for flow lookup acceleration and further
+ * context-aware flow handling offload.
+ * - CT state: optionally for TCP connections CT state can be maintained
+ * (see enum rte_sft_flow_ct_state).
+ * - Out of order TCP packets: optionally SFT can keep out of order TCP
+ * packets aside the flow context till the arrival of the missing in-order
+ * packet.
+ *
+ * RTE flow changes:
+ * The SFT flow state (or context) for RTE flow is defined by fields of
+ * struct rte_flow_item_sft.
+ * To utilize SFT capabilities new item and action types introduced:
+ * - item SFT: matching on SFT flow state (see RTE_FLOW_ITEM_TYPE_SFT).
+ * - action SFT: retrieve SFT flow context and attache it to the processed
+ * packet (see RTE_FLOW_ACTION_TYPE_SFT).
+ *
+ * The contents of per port SFT serving RTE flow action ``SFT`` managed via
+ * SFT PMD APIs (see struct rte_sft_ops).
+ * The SFT flow state/context retrieval performed by user-defined zone ``SFT``
+ * action argument and processed packet 5-tuple.
+ * If in scope of action ``SFT`` there is no context/state for the flow in SFT
+ * undefined sate attached to the packet meaning that the flow is not
+ * recognized by SFT, most probably FIF packet.
+ *
+ * Once the SFT state set for a packet it can match on item SFT
+ * (see RTE_FLOW_ITEM_TYPE_SFT) and forwarding design can be done for the
+ * packet, for example:
+ * - if state value == x than queue for further processing by the application
+ * - if state value == y than forward it to eth port (full offload)
+ * - if state value == 'undefined' than queue for further processing by
+ * the application (handle FIF packets)
+ *
+ * Processing packets with SFT library:
+ *
+ * FIF packet:
+ * To recognize upcoming packets of the SFT flow every FIF packet should be
+ * forwarded to the application utilizing the SFT library. Non-FIF packets can
+ * be processed by the application or its processing can be fully offloaded.
+ * Processing of the packets in SFT library starts with rte_sft_process_mbuf
+ * or rte_sft_process_mbuf_with_zone. If mbuf recognized as FIF application
+ * should make a design to destroy flow or complete flow creation process in
+ * SFT using rte_sft_flow_activate.
+ *
+ * Recognized SFT flow:
+ * Once struct rte_sft_flow_status with valid fid field possessed by application
+ * it can:
+ * - mange client objects on it (see client_obj field in
+ * struct rte_sft_flow_status) using rte_sft_flow_<OP>_client_obj APIs
+ * - analyze user-defined flow state and CT state (see state & ct_sate fields
+ * in struct rte_sft_flow_status).
+ * - set flow state to be attached to the upcoming packets by action ``SFT``
+ * via struct rte_sft_flow_status API.
+ * - decide to destroy flow via rte_sft_flow_destroy API.
+ *
+ * Flow aging:
+ *
+ * SFT library manages the aging for each flow. On flow creation, it's
+ * assigned an aging value, the maximal number of seconds passed since the
+ * last flow packet arrived, once exceeded flow considered aged.
+ * The application notified of aged flow asynchronously via event queues.
+ * The device and port IDs tuple to identify the event queue to enqueue
+ * flow aged events passed on flow creation as arguments
+ * (see rte_sft_flow_activate). It's the application responsibility to
+ * initialize event queues and assign them to each flow for EOF event
+ * notifications.
+ * Aged EOF event handling:
+ * - Should be considered as application responsibility.
+ * - The last stage should be the release of the flow resources via
+ * rte_sft_flow_destroy API.
+ * - All client objects should be removed from flow before the
+ * rte_sft_flow_destroy API call.
+ * See the description of ret_sft_flow_destroy for an example of aged flow
+ * handling.
+ *
+ * SFT API thread safety:
+ *
+ * Since the SFT lib is designed to work as part of the Fast-Path, The SFT
+ * is not thread safe, in order to enable better working with multiple threads
+ * the SFT lib uses the queue approach, where each queue can only be accessesd
+ * by one thread while one thread can access multiple queues.
+ *
+ * SFT Library initialization and cleanup:
+ *
+ * SFT library should be considered as a single instance, preconfigured and
+ * initialized via rte_sft_init() API.
+ * SFT library resource deallocation and cleanup should be done via
+ * rte_sft_init() API as a stage of the application termination procedure.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_config.h>
+#include <rte_errno.h>
+#include <rte_mbuf.h>
+#include <rte_ethdev.h>
+#include <rte_flow.h>
+
+/**
+ * L3/L4 5-tuple - src/dest IP and port and IP protocol.
+ *
+ * Used for flow/connection identification.
+ */
+RTE_STD_C11
+struct rte_sft_5tuple {
+ union {
+ struct {
+ rte_be32_t src_addr; /**< IPv4 source address. */
+ rte_be32_t dst_addr; /**< IPv4 destination address. */
+ } ipv4;
+ struct {
+ uint8_t src_addr[16]; /**< IPv6 source address. */
+ uint8_t dst_addr[16]; /**< IPv6 destination address. */
+ } ipv6;
+ };
+ rte_be16_t src_port; /**< Source port. */
+ rte_be16_t dst_port; /**< Destination port. */
+ uint8_t proto; /**< IP protocol. */
+ uint8_t is_ipv6: 1; /**< True for valid IPv6 fields. Otherwise IPv4. */
+};
+
+/**
+ * Port flow identification.
+ *
+ * @p zone used for setups where 5-tuple is not enough to identify flow.
+ * For example different VLANs/VXLANs may have similar 5-tuples.
+ */
+struct rte_sft_7tuple {
+ struct rte_sft_5tuple flow_5tuple; /**< L3/L4 5-tuple. */
+ uint32_t zone; /**< Zone assigned to flow. */
+ uint16_t port_id; /** <Port identifier of Ethernet device. */
+};
+
+/**
+ * Structure describes SFT library configuration
+ */
+struct rte_sft_conf {
+ uint16_t nb_queues; /**< Preferred number of queues */
+ uint32_t udp_aging; /**< UDP proto default aging in sec */
+ uint32_t tcp_aging; /**< TCP proto default aging in sec */
+ uint32_t tcp_syn_aging; /**< TCP SYN default aging in sec. */
+ uint32_t default_aging; /**< All unlisted proto default aging in sec. */
+ uint32_t nb_max_entries; /**< Max entries in SFT. */
+ uint8_t app_data_len; /**< Number of uint32 of app data. */
+ uint32_t support_partial_match: 1;
+ /**< App can partial match on the data. */
+ uint32_t reorder_enable: 1;
+ /**< TCP packet reordering feature enabled bit. */
+ uint32_t tcp_ct_enable: 1;
+ /**< TCP connection tracking based on standard. */
+ uint32_t reserved: 30;
+};
+
+/**
+ * Structure that holds the action configuration.
+ */
+struct rte_sft_actions_specs {
+ struct rte_sft_5tuple *initiator_nat;
+ /**< The NAT configuration for the initiator flow. */
+ struct rte_sft_5tuple *reverse_nat;
+ /**< The NAT configuration for the reverse flow. */
+ uint64_t aging; /**< the aging time out in sec. */
+};
+
+#define RTE_SFT_ACTION_INITIATOR_NAT (1ul << 0)
+/**< NAT action should be done on the initiator traffic. */
+#define RTE_SFT_ACTION_REVERSE_NAT (1ul << 1)
+/**< NAT action should be done on the reverse traffic. */
+#define RTE_SFT_ACTION_COUNT (1ul << 2) /**< Enable count action. */
+#define RTE_SFT_ACTION_AGE (1ul << 3) /**< Enable ageing action. */
+
+
+/**
+ * Structure that holds the count data.
+ */
+struct rte_sft_query_data {
+ uint64_t nb_bytes; /**< Number of bytes that passed in the flow. */
+ uint64_t nb_packets; /**< Number of packets that passed in the flow. */
+ uint32_t age; /**< Seconds passed since last seen packet. */
+ uint32_t aging;
+ /**< Flow considered aged once this age (seconds) reached. */
+ uint32_t nb_bytes_valid: 1; /**< Number of bytes is valid. */
+ uint32_t nb_packets_valid: 1; /* Number of packets is valid. */
+ uint32_t nb_age_valid: 1; /* Age is valid. */
+ uint32_t nb_aging_valid: 1; /* Aging is valid. */
+ uint32_t reserved: 28;
+};
+
+/**
+ * Structure describes the state of the flow in SFT.
+ */
+struct rte_sft_flow_status {
+ uint32_t fid; /**< SFT flow id. */
+ uint32_t zone; /**< Zone for lookup in SFT */
+ uint8_t state; /**< Application defined bidirectional flow state. */
+ uint8_t proto_state; /**< The state based on the protocol. */
+ uint16_t proto; /**< L4 protocol. */
+ /**< Connection tracking flow state, based on standard. */
+ uint32_t nb_in_order_mbufs;
+ /**< Number of in-order mbufs available for drain */
+ uint32_t activated: 1; /**< Flow was activated. */
+ uint32_t zone_valid: 1; /**< Zone field is valid. */
+ uint32_t proto_state_change: 1; /**< Protocol state was changed. */
+ uint32_t fragmented: 1; /**< Last flow mbuf was fragmented. */
+ uint32_t out_of_order: 1; /**< Last flow mbuf was out of order (TCP). */
+ uint32_t offloaded: 1;
+ /**< The connection is offload and no packet should be stored. */
+ uint32_t initiator: 1; /**< marks if the mbuf is from the initiator. */
+ uint32_t reserved: 25;
+ uint32_t data[];
+ /**< Application data. The length is defined by the configuration. */
+};
+
+/**
+ * Verbose error types.
+ *
+ * Most of them provide the type of the object referenced by struct
+ * rte_flow_error.cause.
+ */
+enum rte_sft_error_type {
+ RTE_SFT_ERROR_TYPE_NONE, /**< No error. */
+ RTE_SFT_ERROR_TYPE_UNSPECIFIED, /**< Cause unspecified. */
+ RTE_SFT_ERROR_TYPE_FLOW_NOT_DEFINED, /**< The FID is not defined. */
+};
+
+/**
+ * Verbose error structure definition.
+ *
+ * This object is normally allocated by applications and set by SFT, the
+ * message points to a constant string which does not need to be freed by
+ * the application, however its pointer can be considered valid only as long
+ * as its associated DPDK port remains configured. Closing the underlying
+ * device or unloading the PMD invalidates it.
+ *
+ * Both cause and message may be NULL regardless of the error type.
+ */
+struct rte_sft_error {
+ enum rte_sft_error_type type; /**< Cause field and error types. */
+ const void *cause; /**< Object responsible for the error. */
+ const char *message; /**< Human-readable error message. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get SFT flow status, based on the fid.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] status
+ * Structure to dump actual SFT flow status.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_get_status(const uint16_t queue, const uint32_t fid,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set user defined data.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param data
+ * User defined data. The len is defined at configuration time.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_data(uint16_t queue, uint32_t fid, const uint32_t *data,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set user defined state.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param state
+ * User state.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_state(uint16_t queue, uint32_t fid, const uint8_t state,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set user defined state.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param offload
+ * set if flow is offloaded.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_offload(uint16_t queue, uint32_t fid, bool offload,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Initialize SFT library instance.
+ *
+ * @param conf
+ * SFT library instance configuration.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_init(const struct rte_sft_conf *conf, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Finalize SFT library instance.
+ * Cleanup & release allocated resources.
+ */
+__rte_experimental
+void
+rte_sft_fini(void);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Process mbuf received on RX queue.
+ *
+ * This function checks the mbuf against the SFT database and return the
+ * connection status that this mbuf belongs to.
+ *
+ * If status.activated = 1 and status.offloaded = 0 the input mbuf is
+ * considered consumed and the application is not allowed to use it or free it,
+ * instead the application should use the mbuf pointed by the mbuf_out.
+ * Incase the mbuf is out of order or fragmented the mbuf_out will be NULL.
+ *
+ * If status.activated = 0 or status.offloaded = 1, the input mbuf is not
+ * consumed and the mbuf_out will allways be NULL.
+ *
+ * This function doesn't create new entry in the SFT.
+ *
+ * @param queue
+ * The sft queue number.
+ * @param[in] mbuf_in
+ * mbuf to process; mbuf pointer considered 'consumed' and should not be used
+ * if status.activated and status.offload = 0.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param[out] status
+ * Connection status based on the last in mbuf.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Initialize in case of
+ * error only.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_process_mbuf(uint16_t queue, struct rte_mbuf *mbuf_in,
+ struct rte_mbuf **mbuf_out,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Process mbuf received on RX queue while zone value provided by caller.
+ *
+ * The behaviour of this function is similar to rte_sft_process_mbuf except
+ * the lookup in SFT procedure. The lookup in SFT always done by the *zone*
+ * arg and 5-tuple 5-tuple, extracted form mbuf outer header contents.
+ *
+ * @see rte_sft_process_mbuf
+ *
+ * @param queue
+ * The sft queue number.
+ * @param[in] mbuf_in
+ * mbuf to process; mbuf pointer considered 'consumed' and should not be used
+ * after successful call to this function.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param[out] status
+ * Connection status based on the last in mbuf.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Initialize in case of
+ * error only.
+ *
+ * @return
+ * 0 on success , a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_process_mbuf_with_zone(uint16_t queue, struct rte_mbuf *mbuf_in,
+ uint32_t zone, struct rte_mbuf **mbuf_out,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Drain next in order mbuf.
+ *
+ * This function behaves similar to rte_sft_process_mbuf() but acts on packets
+ * accumulated in SFT flow due to missing in order packet. Processing done on
+ * single mbuf at a time and `in order`. Other than above the behavior is
+ * same as of rte_sft_process_mbuf for flow defined & activated & mbuf isn't
+ * fragmented & 'in order'. This function should be called when
+ * rte_sft_process_mbuf or rte_sft_process_mbuf_with_zone sets
+ * status->nb_in_order_mbufs output param !=0 and until
+ * status->nb_in_order_mbufs == 0.
+ * Flow should be locked by caller (see rte_sft_flow_lock).
+ *
+ * @param queue
+ * The sft queue number.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param nb_out
+ * Number of buffers to be drained.
+ * @param initiator
+ * true packets that will be drained belongs to the initiator.
+ * @param[out] status
+ * Connection status based on the last mbuf that was drained.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Initialize in case of
+ * error only.
+ *
+ * @return
+ * The number of mbufs that were drained, negative value in case
+ * of error and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_drain_mbuf(uint16_t queue, uint32_t fid, struct rte_mbuf **mbuf_out,
+ uint16_t nb_out, bool initiator,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Activate flow in SFT.
+ *
+ * This function creates an entry in the SFT for this connection.
+ * The reasons for 2 phase flow creation procedure:
+ * 1. Missing reverse flow - flow context is shared for both flow directions
+ * i.e. in order maintain bidirectional flow context in RTE SFT packets
+ * arriving from both directions should be identified as packets of the
+ * RTE SFT flow. Consequently, before the creation of the SFT flow caller
+ * should provide reverse flow direction 7-tuple.
+ * 2. The caller of rte_sft_process_mbuf/rte_sft_process_mbuf_with_zone should
+ * be notified that arrived mbuf is first in flow & decide whether to
+ * create a new flow or disregard this packet.
+ * This function completes the creation of the bidirectional SFT flow & creates
+ * entry for 7-tuple on SFT PMD defined by the tuple port for both
+ * initiator/initiate 7-tuples.
+ * Flow aging, connection tracking state & out of order handling will be
+ * initialized according to the content of the *mbuf_in* passes to
+ * rte_sft_process_mbuf/_with_zone during phase 1 of flow creation.
+ * Once this function returns upcoming calls rte_sft_process_mbuf/_with_zone
+ * with 7-tuple or its reverse will return the handle to this flow.
+ * Flow should be locked by the caller (see rte_sft_flow_lock).
+ *
+ * @param queue
+ * The SFT queue.
+ * @param[in] mbuf_in
+ * mbuf to process; mbuf pointer considered 'consumed' and should not be used
+ * after successful call to this function.
+ * @param reverse_tuple
+ * Expected response flow 7-tuple.
+ * @param state
+ * User defined state to set.
+ * @param data
+ * User defined data, the len is configured during sft init.
+ * @param proto_enable
+ * Enables maintenance of status->proto_state connection tracking value
+ * for the flow. otherwise status->proto_state will be initialized with zeros.
+ * @param dev_id
+ * Event dev ID to enqueue end of flow event.
+ * @param port_id
+ * Event port ID to enqueue end of flow event.
+ * @param actions
+ * Flags that indicate which actions should be done on the packet before
+ * returning it to the rte_flow.
+ * @param action_specs
+ * Hold the actions configuration.
+ * @param[out] mbuf_out
+ * last processed not fragmented and in order mbuf.
+ * @param[out] status
+ * Structure to dump SFT flow status once activated.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_activate(uint16_t queue, struct rte_mbuf *mbuf_in,
+ const struct rte_sft_7tuple *reverse_tuple,
+ uint8_t state, uint32_t *data, uint8_t proto_enable,
+ uint8_t dev_id, uint8_t port_id, uint64_t actions,
+ const struct rte_sft_actions_specs *action_specs,
+ struct rte_mbuf **mbuf_out,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Artificially create SFT flow.
+ *
+ * Function to create SFT flow before reception of the first flow packet.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param tuple
+ * Expected initiator flow 7-tuple.
+ * @param reverse_tuple
+ * Expected initiate flow 7-tuple.
+ * @param state
+ * User defined state to set.
+ * @param data
+ * User defined data, the len is configured during sft init.
+ * @param proto_enable
+ * Enables maintenance of status->proto_state connection tracking value
+ * for the flow. otherwise status->proto_state will be initialized with zeros.
+ * @param[out] status
+ * Connection status.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. PMDs initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * - on success: 0, locked SFT flow recognized by status->fid.
+ * - on error: a negative errno value otherwise and rte_errno is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_create(uint16_t queue, const struct rte_sft_7tuple *tuple,
+ const struct rte_sft_7tuple *reverse_tuple,
+ const struct rte_flow_item_sft *ctx,
+ uint8_t ct_enable,
+ struct rte_sft_flow_status *status,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Removes flow from SFT.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID to destroy.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_destroy(uint16_t queue, uint32_t fid, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Query counter and aging data.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] data.
+ * SFT flow ID.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_query(uint16_t queue, uint32_t fid,
+ struct rte_sft_query_data *data,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Reset flow age to zero.
+ *
+ * Simulates last flow packet with timestamp set to just now.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_touch(uint16_t queue, uint32_t fid, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set flow aging to specific value.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param aging
+ * New flow aging value.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_aging(uint16_t queue, uint32_t fid, uint32_t aging,
+ struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Set client object for given client ID.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param client_id
+ * Client ID to set object for.
+ * @param client_obj
+ * Pointer to opaque client object structure.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_sft_error is set.
+ */
+__rte_experimental
+int
+rte_sft_flow_set_client_obj(uint16_t queue, uint32_t fid, uint8_t client_id,
+ void *client_obj, struct rte_sft_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get client object for given client ID.
+ *
+ * @param queue
+ * The SFT queue.
+ * @param fid
+ * SFT flow ID.
+ * @param client_id
+ * Client ID to get object for.
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. SFT initialize this
+ * structure in case of error only.
+ *
+ * @return
+ * A valid client object opaque pointer in case of success, NULL otherwise
+ * and rte_sft_error is set.
+ */
+__rte_experimental
+void *
+rte_sft_flow_get_client_obj(uint16_t queue, const uint32_t fid,
+ uint8_t client_id, struct rte_sft_error *error);
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_SFT_H_ */
diff --git a/lib/librte_ethdev/rte_sft_driver.h b/lib/librte_ethdev/rte_sft_driver.h
new file mode 100644
index 0000000000..4f1964dab6
--- /dev/null
+++ b/lib/librte_ethdev/rte_sft_driver.h
@@ -0,0 +1,201 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef RTE_SFT_DRIVER_H_
+#define RTE_SFT_DRIVER_H_
+
+/**
+ * @file
+ * RTE generic SFT API (driver side)
+ *
+ * This file provides implementation helpers for internal use by PMDs, they
+ * are not intended to be exposed to applications and are not subject to ABI
+ * versioning.
+ */
+
+#include <stdint.h>
+
+#include "rte_ethdev.h"
+#include "rte_ethdev_driver.h"
+#include "rte_sft.h"
+#include "rte_flow.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+struct rte_sft_entry;
+
+#define RTE_SFT_STATE_FLAG_FID_VALID (1 << 0)
+#define RTE_SFT_STATE_FLAG_ZONE_VALID (1 << 1)
+#define RTE_SFT_STATE_FLAG_FLOW_MISS (1 << 2)
+
+#define RTE_SFT_MISS_TCP_FLAGS (1 << 0)
+
+RTE_STD_C11
+struct rte_sft_decode_info {
+ union {
+ uint32_t fid; /**< The fid value. */
+ uint32_t zone; /**< The zone value. */
+ };
+ uint32_t state;
+ /**< Flags that mark the packet state. see RTE_SFT_STATE_FLAG_*. */
+};
+
+/**
+ * @internal
+ * Insert a flow to the SFT HW component.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param fid
+ * Flow ID.
+ * @param queue
+ * The sft working queue.
+ * @param pattern
+ * The matching pattern.
+ * @param miss_conditions
+ * The conditions that forces a miss even if the 5 tuple was matched
+ * see RTE_SFT_MISS_*.
+ * @param actions
+ * Set pf actions to apply in case the flow was hit. If no terminating action
+ * (queue, rss, drop, port) was given, the terminating action should be taken
+ * from the flow that resulted in the SFT.
+ * @param miss_actions
+ * Set pf actions to apply in case the flow was hit. but the miss conditions
+ * were hit. (6 tuple match but tcp flags are on) If no terminating action
+ * (queue, rss, drop, port) was given, the terminating action should be taken
+ * from the flow that resulted in the SFT.
+ * @param data
+ * The application data to attached to the flow.
+ * @param data_len
+ * The length of the data in uint32_t increments.
+ * @param state
+ * The application state to set.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Pointer to sft_entry in case of success, null otherwise and rte_sft_error
+ * is set.
+ */
+typedef struct rte_sft_entry *(*sft_entry_create_t)
+ (struct rte_eth_dev *dev, uint32_t fid, uint16_t queue,
+ const struct rte_flow_item *pattern, uint64_t miss_conditions,
+ const struct rte_flow_action *actions,
+ const struct rte_flow_action *miss_actions,
+ const uint32_t *data, uint16_t data_len, uint8_t state,
+ struct rte_sft_error *error);
+
+/**
+ * @internal
+ * Modify the state and the data of SFT flow in HW component.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param entry
+ * The entry to modify.
+ * @param queue
+ * The sft working queue.
+ * @param data
+ * The application data to attached to the flow.
+ * @param data_len
+ * The length of the data in uint32_t increments.
+ * @param state
+ * The application state to set.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Negative errno value on error, 0 on success.
+ */
+typedef int *(*sft_entry_modify_t)(struct rte_eth_dev *dev,
+ struct rte_sft_entry *entry, uint16_t queue,
+ const uint32_t *data, uint16_t data_len,
+ uint8_t state, struct rte_sft_error *error);
+
+/**
+ * @internal
+ * Destroy SFT flow in HW component.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param entry
+ * The entry to modify.
+ * @param queue
+ * The sft working queue.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Negative errno value on error, 0 on success.
+ */
+typedef int *(*sft_entry_destory_t)(struct rte_eth_dev *dev,
+ struct rte_sft_entry *entry, uint16_t queue,
+ struct rte_sft_error *error);
+
+/**
+ * @internal
+ * Decode sft state and FID from mbuf.
+ *
+ * @param dev
+ * ethdev handle of port.
+ * @param entry
+ * The entry to modify.
+ * @param queue
+ * The sft working queue.
+ * @param mbuf
+ * The input mbuf.
+ * @param info[out]
+ * The decoded sft data.
+ * @param error[out]
+ * Verbose of the error.
+ *
+ * @return
+ * Negative errno value on error, 0 on success.
+ */
+typedef int *(*sft_entry_decode_t)(struct rte_eth_dev *dev,
+ struct rte_sft_entry *entry, uint16_t queue,
+ struct rte_mbuf *mbuf,
+ struct rte_sft_decode_info *info,
+ struct rte_sft_error *error);
+
+/**
+ * Generic sft operations structure implemented and returned by PMDs.
+ *
+ * If successful, this operation must result in a pointer to a PMD-specific.
+ *
+ * See also rte_sft_ops_get().
+ *
+ * These callback functions are not supposed to be used by applications
+ * directly, which must rely on the API defined in rte_sft.h.
+ */
+struct rte_sft_ops {
+ sft_entry_create_t sft_create_entry;
+ sft_entry_modify_t sft_entry_modify;
+ sft_entry_destory_t sft_entry_destory;
+ sft_entry_decode_t sft_entry_decode;
+};
+
+/**
+ * Get generic sft operations structure from a port.
+ *
+ * @param port_id
+ * Port identifier to query.
+ * @param[out] error
+ * Pointer to flow error structure.
+ *
+ * @return
+ * The flow operations structure associated with port_id, NULL in case of
+ * error, in which case rte_errno is set and the error structure contains
+ * additional details.
+ */
+const struct rte_sft_ops *
+rte_sft_ops_get(uint16_t port_id, struct rte_sft_error *error);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_SFT_DRIVER_H_ */
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH] ethdev: deprecate shared counters using action attribute
2020-11-03 17:21 3% ` Thomas Monjalon
@ 2020-11-03 17:26 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2020-11-03 17:26 UTC (permalink / raw)
To: Thomas Monjalon, Ori Kam
Cc: dev, Andrew Rybchenko, Andrey Vesnovaty, Ferruh Yigit,
Ray Kinsella, Neil Horman, techboard
On 11/3/20 8:21 PM, Thomas Monjalon wrote:
> +Cc techboard
>
> There is an interesting case here that we should decide
> how to manage in general. Please see below.
>
> 01/11/2020 08:49, Ori Kam:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 29/10/2020 15:39, Ori Kam:
>>>>> struct rte_flow_action_count {
>>>>> - uint32_t shared:1; /**< Share counter ID with other flow rules. */
>>>>> + /** @deprecated Share counter ID with other flow rules. */
>>>>> + uint32_t shared:1;
>>>>> uint32_t reserved:31; /**< Reserved, must be zero. */
>>>>> uint32_t id; /**< Counter ID. */
>>>>> };
>>>>
>>>> As much as I agree with your patch, I don't think we should push it since
>>>> not all PMD made the move to support count action, so the application still
>>> needs
>>>> to use this API.
>>>>
>>>> I think this patch should be done but in next LTS release.
>>>
>>> The patch is not removing the field,
>>> it is just warning it will be removed in next year.
>>
>> Yes I know, but I don't think it is correct to issue such a warning without support.
>> The application still must use this API, the warning should be added as soon as
>> at least one PMD support shared counters with the new API.
>
> It should be replaced with shared actions API,
> but you claim it is not supported yet. Right?
> What are the criterias to define the replacement as supported?
>
> What to do in such case?
> Can we warn about a deprecation without having a proper replacement?
> What is the pre-condition to warn about a deprecation?
>
> About the complete removal, it has already been decided by the techboard
> that we cannot remove an API until its replacement is stable.
> In other words, the new experimental API must be promoted
> in the stable ABI, before removing the deprecated API.
>
May be the right way here is to remove deprecation mark up,
but add a deprecation notice that it will be deprecated in
21.02 and PMDs are encouraged to switch to shared actions.
Anyway questions above about the criteria are still valid
even in this case and should be answered.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: deprecate shared counters using action attribute
@ 2020-11-03 17:21 3% ` Thomas Monjalon
2020-11-03 17:26 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-11-03 17:21 UTC (permalink / raw)
To: Andrew Rybchenko, Ori Kam
Cc: dev, Andrew Rybchenko, Andrey Vesnovaty, Ferruh Yigit,
Ray Kinsella, Neil Horman, techboard
+Cc techboard
There is an interesting case here that we should decide
how to manage in general. Please see below.
01/11/2020 08:49, Ori Kam:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 29/10/2020 15:39, Ori Kam:
> > > > struct rte_flow_action_count {
> > > > - uint32_t shared:1; /**< Share counter ID with other flow rules. */
> > > > + /** @deprecated Share counter ID with other flow rules. */
> > > > + uint32_t shared:1;
> > > > uint32_t reserved:31; /**< Reserved, must be zero. */
> > > > uint32_t id; /**< Counter ID. */
> > > > };
> > >
> > > As much as I agree with your patch, I don't think we should push it since
> > > not all PMD made the move to support count action, so the application still
> > needs
> > > to use this API.
> > >
> > > I think this patch should be done but in next LTS release.
> >
> > The patch is not removing the field,
> > it is just warning it will be removed in next year.
>
> Yes I know, but I don't think it is correct to issue such a warning without support.
> The application still must use this API, the warning should be added as soon as
> at least one PMD support shared counters with the new API.
It should be replaced with shared actions API,
but you claim it is not supported yet. Right?
What are the criterias to define the replacement as supported?
What to do in such case?
Can we warn about a deprecation without having a proper replacement?
What is the pre-condition to warn about a deprecation?
About the complete removal, it has already been decided by the techboard
that we cannot remove an API until its replacement is stable.
In other words, the new experimental API must be promoted
in the stable ABI, before removing the deprecated API.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 14:02 0% ` Slava Ovsiienko
@ 2020-11-03 15:03 0% ` Morten Brørup
2020-11-04 15:00 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-03 15:03 UTC (permalink / raw)
To: Slava Ovsiienko, NBU-Contact-Thomas Monjalon, dev, techboard
Cc: Ajit Khaparde, Ananyev, Konstantin, Andrew Rybchenko, dev, Yigit,
Ferruh, david.marchand, Richardson, Bruce, olivier.matz, jerinj,
honnappa.nagarahalli, maxime.coquelin, stephen, hemant.agrawal,
Matan Azrad, Shahaf Shuler
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Slava Ovsiienko
> Sent: Tuesday, November 3, 2020 3:03 PM
>
> Hi, Morten
>
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Tuesday, November 3, 2020 14:10
> >
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Monday, November 2, 2020 4:58 PM
> > >
> > > +Cc techboard
> > >
> > > We need benchmark numbers in order to take a decision.
> > > Please all, prepare some arguments and numbers so we can discuss
> the
> > > mbuf layout in the next techboard meeting.
> >
> > I propose that the techboard considers this from two angels:
> >
> > 1. Long term goals and their relative priority. I.e. what can be
> achieved with
> > wide-ranging modifications, requiring yet another ABI break and due
> notices.
> >
> > 2. Short term goals, i.e. what can be achieved for this release.
> >
> >
> > My suggestions follow...
> >
> > 1. Regarding long term goals:
> >
> > I have argued that simple forwarding of non-segmented packets using
> only the
> > first mbuf cache line can be achieved by making three
> > modifications:
> >
> > a) Move m->tx_offload to the first cache line.
> Not all PMDs use this field on Tx. HW might support the checksum
> offloads
> directly, not requiring these fields at all.
>
>
> > b) Use an 8 bit pktmbuf mempool index in the first cache line,
> > instead of the 64 bit m->pool pointer in the second cache line.
> 256 mpool looks enough, as for me. Regarding the indirect access to the
> pool
> (via some table) - it might introduce some performance impact.
It might, but I hope that it is negligible, so the benefits outweigh the disadvantages.
It would have to be measured, though.
And m->pool is only used for free()'ing (and detach()'ing) mbufs.
> For example,
> mlx5 PMD strongly relies on pool field for allocating mbufs in Rx
> datapath.
> We're going to update (o-o, we found point to optimize), but for now it
> does.
Without looking at the source code, I don't think the PMD is using m->pool in the RX datapath, I think it is using a pool dedicated to a receive queue used for RX descriptors in the PMD (i.e. driver->queue->pool).
>
> > c) Do not access m->next when we know that it is NULL.
> > We can use m->nb_segs == 1 or some other invariant as the gate.
> > It can be implemented by adding an m->next accessor function:
> > struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> > {
> > return m->nb_segs == 1 ? NULL : m->next;
> > }
>
> Sorry, not sure about this. IIRC, nb_segs is valid in the first
> segment/mbuf only.
> If we have the 4 segments in the pkt we see nb_seg=4 in the first one,
> and the nb_seg=1
> in the others. The next field is NULL in the last mbuf only. Am I wrong
> and miss something ?
You are correct.
This would have to be updated too. Either by increasing m->nb_seg in the following segments, or by splitting up relevant functions into functions for working on first segments (incl. non-segmented packets), and functions for working on following segments of segmented packets.
>
> > Regarding the priority of this goal, I guess that simple forwarding
> of non-
> > segmented packets is probably the path taken by the majority of
> packets
> > handled by DPDK.
> >
> > An alternative goal could be:
> > Do not touch the second cache line during RX.
> > A comment in the mbuf structure says so, but it is not true anymore.
> >
> > (I guess that regression testing didn't catch this because the tests
> perform TX
> > immediately after RX, so the cache miss just moves from the TX to the
> RX part
> > of the test application.)
> >
> >
> > 2. Regarding short term goals:
> >
> > The current DPDK source code looks to me like m->next is the most
> frequently
> > accessed field in the second cache line, so it makes sense moving
> this to the
> > first cache line, rather than m->pool.
> > Benchmarking may help here.
>
> Moreover, for the segmented packets the packet size is supposed to be
> large,
> and it imposes the relatively low packet rate, so probably optimization
> of
> moving next to the 1st cache line might be negligible at all. Just
> compare 148Mpps of
> 64B pkts and 4Mpps of 3000B pkts over 100Gbps link. Currently we are on
> benchmarking
> and did not succeed yet on difference finding. The benefit can't be
> expressed in mpps delta,
> we should measure CPU clocks, but Rx queue is almost always empty - we
> have an empty
> loops. So, if we have the boost - it is extremely hard to catch one.
Very good point regarding the value of such an optimization, Slava!
And when free()'ing packets, both m->next and m->pool are touched.
So perhaps the free()/detach() functions in the mbuf library can be modified to handle first segments (and non-segmented packets) and following segments differently, so accessing m->next can be avoided for non-segmented packets. Then m->pool should be moved to the first cache line.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] Minutes of Technical Board Meeting, 2020-10-21
@ 2020-11-03 14:25 4% Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2020-11-03 14:25 UTC (permalink / raw)
To: dev; +Cc: techboard, Ori Kam, Guy Kaneti, Dovrat Zifroni
Minutes of Technical Board Meeting, 2020-10-21
Members Attending
-----------------
-Bruce
-Ferruh
-Hemant
-Honnappa
-Jerin (Chair)
-Kevin
-Konstantin
-Maxime
-Olivier
-Stephen
-Thomas
NOTE: The technical board meetings every second Wednesday in https://meet.jit.si/DPDK at 3 pm UTC.
Meetings are public, and DPDK community members are welcome to attend.
NOTE: Next meeting will be on Wednesday 2020-11-04 @3pm UTC, and will be chaired by Kevin
# Feedback from TB on l3fwd-regexdev example application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- TB agreed to have an example application that exercises the regex device and network device as a separate application.
- The example shall be used for both Benchmark and functional verification of regex in the forwarding path.
- Based on the discussions, it is agreed that l3fwd might not be the real use case to consider as regex + network application
- Instead, TB recommends having the Deep packet inspection style application to showcase the regex + networking use case.
- Following is the simple DPI style application definition, which can be considered as a candidate, as an example of regex + network application
1) Create or import a rule database.
- Rule database will have an index as rule_id and pattern to search
2) Create or import rule_id to the action table
- Action could be -1 for the drop, 0 .. N for a specific port to forward upon the match
3) Enqueue all the packet from ethdev to regexdev
4) If there is a match, then do the action based on the table created in step 2 using struct rte_regexdev_match::rule_id
5) If there is no match, forward back to the source port
# Approval for ABI exception request for 20.11
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) LPM
- Agreed to merge the patch with ABI changes
- Reference: http://git.dpdk.org/dpdk/commit/?id=ced5a6ce244323435d9b0c0cb8ff98adc07fc6bd
# Update on DTS usability
~~~~~~~~~~~~~~~~~~~~~~~~~
- Waiting for the feedback from community. Revisit after 20.11 release.
# Update Security process issue updates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Call for volunteers to review and to be part of Security process team.
# DMARC mitigation in the mailing list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- No mitigation plan as of now to support DMARC in the mailing list.
- TB may revisit this topic once the popular opensource communities such as
Linux Kernel etc. migrated or have mitigation to support DMARC.
Prepare the CFP text for a virtual Asia event in January 2021
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Following is the TB views on this proposal
1) Since it is a virtual event, Why it needs to be specific to Asia?
Can a similar time geographical zone area can join the virtual connect?
2) Language will be a real barrier to host an Asia specific event.
3) TB recommends if there are enough participants for the Mandarin
language, then it is better to have virtual connect targeting to the Mandarin-only
audience like past connects.
4) Also, Based on country-specific community feedback, other language-specific
event/days can be planed if needed.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 13:50 0% ` Bruce Richardson
@ 2020-11-03 14:03 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2020-11-03 14:03 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, dev, techboard, Ajit Khaparde, Ananyev,
Konstantin, Andrew Rybchenko, Yigit, Ferruh, david.marchand,
olivier.matz, jerinj, viacheslavo, honnappa.nagarahalli,
maxime.coquelin, stephen, hemant.agrawal, Matan Azrad,
Shahaf Shuler
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, November 3, 2020 2:50 PM
>
> On Tue, Nov 03, 2020 at 02:46:17PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Tuesday, November 3, 2020 1:26 PM
> > >
> > > On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > Sent: Monday, November 2, 2020 4:58 PM
> > > > >
> > > > > +Cc techboard
> > > > >
> > > > > We need benchmark numbers in order to take a decision.
> > > > > Please all, prepare some arguments and numbers so we can
> discuss
> > > > > the mbuf layout in the next techboard meeting.
> > > >
> > > > I propose that the techboard considers this from two angels:
> > > >
> > > > 1. Long term goals and their relative priority. I.e. what can be
> > > > achieved with wide-ranging modifications, requiring yet another
> ABI
> > > > break and due notices.
> > > >
> > > > 2. Short term goals, i.e. what can be achieved for this release.
> > > >
> > > >
> > > > My suggestions follow...
> > > >
> > > > 1. Regarding long term goals:
> > > >
> > > > I have argued that simple forwarding of non-segmented packets
> using
> > > > only the first mbuf cache line can be achieved by making three
> > > > modifications:
> > > >
> > > > a) Move m->tx_offload to the first cache line.
> > > > b) Use an 8 bit pktmbuf mempool index in the first cache line,
> > > > instead of the 64 bit m->pool pointer in the second cache
> line.
> > > > c) Do not access m->next when we know that it is NULL.
> > > > We can use m->nb_segs == 1 or some other invariant as the
> gate.
> > > > It can be implemented by adding an m->next accessor function:
> > > > struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> > > > {
> > > > return m->nb_segs == 1 ? NULL : m->next;
> > > > }
> > > >
> > > > Regarding the priority of this goal, I guess that simple
> forwarding
> > > > of non-segmented packets is probably the path taken by the
> majority
> > > > of packets handled by DPDK.
> > > >
> > > >
> > > > An alternative goal could be:
> > > > Do not touch the second cache line during RX.
> > > > A comment in the mbuf structure says so, but it is not true
> anymore.
> > > >
> > >
> > > The comment should be true for non-scattered RX, I believe.
> >
> > You are correct.
> >
> > My suggestion was unclear: Extend this remark to include segmented
> packets.
> >
> > This could be a priority if the techboard considers RX segmented
> packets more important than my suggestion for single cache line
> forwarding of non-segmented packets.
> >
> >
> > > I'm not aware of any use of second cacheline for the fast-path RXs
> for many drivers.
> > > Am I missing something that has changed recently here?
> >
> > Check out eth_igb_recv_pkts() in the E1000 driver: rxm->next = NULL;
> > Or pmd_rx_burst() in the TAP driver: new_tail->next = seg->next;
> >
> > Perhaps the documentation should describe best practices for
> implementing RX and TX functions in drivers, including
> allocating/freeing mbufs. Or an example dummy Ethernet driver could do
> it.
> >
>
> Yes, perhaps I should be clearer about the "fast-path", because I was
> thinking of the optimized RX/TX paths for those nics at 10G and above.
> Probably the documentation should indeed have an update clarifying
> things a
> bit, since using the first cacheline only possible but not mandatory
> for
> simple RX.
I sometimes look at the source code of the simple drivers for reference, as they are easier to understand than the advanced vector drivers.
I suppose new PMD developers also would. :-)
Anyway, it is probably a good idea to add a clarifying note to the documentation, thus reflecting reality.
Just make sure that it says that the second cache line is supposed to be untouched by RX of high performance drivers, so application developers still consider it cold.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 12:10 4% ` Morten Brørup
2020-11-03 12:25 0% ` Bruce Richardson
@ 2020-11-03 14:02 0% ` Slava Ovsiienko
2020-11-03 15:03 0% ` Morten Brørup
1 sibling, 1 reply; 200+ results
From: Slava Ovsiienko @ 2020-11-03 14:02 UTC (permalink / raw)
To: Morten Brørup, NBU-Contact-Thomas Monjalon, dev, techboard
Cc: Ajit Khaparde, Ananyev, Konstantin, Andrew Rybchenko, dev, Yigit,
Ferruh, david.marchand, Richardson, Bruce, olivier.matz, jerinj,
honnappa.nagarahalli, maxime.coquelin, stephen, hemant.agrawal,
Matan Azrad, Shahaf Shuler
Hi, Morten
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Tuesday, November 3, 2020 14:10
> To: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org;
> techboard@dpdk.org
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>; david.marchand@redhat.com; Richardson, Bruce
> <bruce.richardson@intel.com>; olivier.matz@6wind.com; jerinj@marvell.com;
> Slava Ovsiienko <viacheslavo@nvidia.com>; honnappa.nagarahalli@arm.com;
> maxime.coquelin@redhat.com; stephen@networkplumber.org;
> hemant.agrawal@nxp.com; Slava Ovsiienko <viacheslavo@nvidia.com>; Matan
> Azrad <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>
> Subject: RE: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst
> half
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Monday, November 2, 2020 4:58 PM
> >
> > +Cc techboard
> >
> > We need benchmark numbers in order to take a decision.
> > Please all, prepare some arguments and numbers so we can discuss the
> > mbuf layout in the next techboard meeting.
>
> I propose that the techboard considers this from two angels:
>
> 1. Long term goals and their relative priority. I.e. what can be achieved with
> wide-ranging modifications, requiring yet another ABI break and due notices.
>
> 2. Short term goals, i.e. what can be achieved for this release.
>
>
> My suggestions follow...
>
> 1. Regarding long term goals:
>
> I have argued that simple forwarding of non-segmented packets using only the
> first mbuf cache line can be achieved by making three
> modifications:
>
> a) Move m->tx_offload to the first cache line.
Not all PMDs use this field on Tx. HW might support the checksum offloads
directly, not requiring these fields at all.
> b) Use an 8 bit pktmbuf mempool index in the first cache line,
> instead of the 64 bit m->pool pointer in the second cache line.
256 mpool looks enough, as for me. Regarding the indirect access to the pool
(via some table) - it might introduce some performance impact. For example,
mlx5 PMD strongly relies on pool field for allocating mbufs in Rx datapath.
We're going to update (o-o, we found point to optimize), but for now it does.
> c) Do not access m->next when we know that it is NULL.
> We can use m->nb_segs == 1 or some other invariant as the gate.
> It can be implemented by adding an m->next accessor function:
> struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> {
> return m->nb_segs == 1 ? NULL : m->next;
> }
Sorry, not sure about this. IIRC, nb_segs is valid in the first segment/mbuf only.
If we have the 4 segments in the pkt we see nb_seg=4 in the first one, and the nb_seg=1
in the others. The next field is NULL in the last mbuf only. Am I wrong and miss something ?
> Regarding the priority of this goal, I guess that simple forwarding of non-
> segmented packets is probably the path taken by the majority of packets
> handled by DPDK.
>
> An alternative goal could be:
> Do not touch the second cache line during RX.
> A comment in the mbuf structure says so, but it is not true anymore.
>
> (I guess that regression testing didn't catch this because the tests perform TX
> immediately after RX, so the cache miss just moves from the TX to the RX part
> of the test application.)
>
>
> 2. Regarding short term goals:
>
> The current DPDK source code looks to me like m->next is the most frequently
> accessed field in the second cache line, so it makes sense moving this to the
> first cache line, rather than m->pool.
> Benchmarking may help here.
Moreover, for the segmented packets the packet size is supposed to be large,
and it imposes the relatively low packet rate, so probably optimization of
moving next to the 1st cache line might be negligible at all. Just compare 148Mpps of
64B pkts and 4Mpps of 3000B pkts over 100Gbps link. Currently we are on benchmarking
and did not succeed yet on difference finding. The benefit can't be expressed in mpps delta,
we should measure CPU clocks, but Rx queue is almost always empty - we have an empty
loops. So, if we have the boost - it is extremely hard to catch one.
With best regards, Slava
>
>
> If we - without breaking the ABI - can introduce a gate to avoid accessing m-
> >next when we know that it is NULL, we should keep it in the second cache
> line.
>
> In this case, I would prefer to move m->tx_offload to the first cache line,
> thereby providing a field available for application use, until the application
> prepares the packet for transmission.
>
>
> >
> >
> > 01/11/2020 21:59, Morten Brørup:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Sunday, November 1, 2020 5:38 PM
> > > >
> > > > 01/11/2020 10:12, Morten Brørup:
> > > > > One thing has always puzzled me:
> > > > > Why do we use 64 bits to indicate which memory pool an mbuf
> > > > > belongs to?
> > > > > The portid only uses 16 bits and an indirection index.
> > > > > Why don't we use the same kind of indirection index for mbuf
> > pools?
> > > >
> > > > I wonder what would be the cost of indirection. Probably
> > neglectible.
> > >
> > > Probably. The portid does it, and that indirection is heavily used
> > everywhere.
> > >
> > > The size of mbuf memory pool indirection array should be compile
> > > time
> > configurable, like the size of the portid indirection array.
> > >
> > > And for reference, the indirection array will fit into one cache
> > > line
> > if we default to 8 mbuf pools, thus supporting an 8 CPU socket system
> > with one mbuf pool per CPU socket, or a 4 CPU socket system with two
> > mbuf pools per CPU socket.
> > >
> > > (And as a side note: Our application is optimized for single-socket
> > systems, and we only use one mbuf pool. I guess many applications were
> > developed without carefully optimizing for multi-socket systems, and
> > also just use one mbuf pool. In these cases, the mbuf structure
> > doesn't really need a pool field. But it is still there, and the DPDK
> > libraries use it, so we didn't bother removing it.)
> > >
> > > > I think it is a good proposal...
> > > > ... for next year, after a deprecation notice.
> > > >
> > > > > I can easily imagine using one mbuf pool (or perhaps a few
> > > > > pools) per CPU socket (or per physical memory bus closest to an
> > > > > attached
> > NIC),
> > > > > but not more than 256 mbuf memory pools in total.
> > > > > So, let's introduce an mbufpoolid like the portid, and cut this
> > > > > mbuf field down from 64 to 8 bits.
> >
> > We will need to measure the perf of the solution.
> > There is a chance for the cost to be too much high.
> >
> >
> > > > > If we also cut down m->pkt_len from 32 to 24 bits,
> > > >
> > > > Who is using packets larger than 64k? Are 16 bits enough?
> > >
> > > I personally consider 64k a reasonable packet size limit. Exotic
> > applications with even larger packets would have to live with this
> > constraint. But let's see if there are any objections. For reference,
> > 64k corresponds to ca. 44 Ethernet (1500 byte) packets.
> > >
> > > (The limit could be 65535 bytes, to avoid translation of the value 0
> > into 65536 bytes.)
> > >
> > > This modification would go nicely hand in hand with the mbuf pool
> > indirection modification.
> > >
> > > ... after yet another round of ABI stability discussions,
> > depreciation notices, and so on. :-)
> >
> > After more thoughts, I'm afraid 64k is too small in some cases.
> > And 24-bit manipulation would probably break performance.
> > I'm afraid we are stuck with 32-bit length.
>
> Yes, 24 bit manipulation would probably break performance.
>
> Perhaps a solution exists with 16 bits (least significant bits) for the common
> cases, and 8 bits more (most significant bits) for the less common cases. Just
> thinking out loud here...
>
> >
> > > > > we can get the 8 bit mbuf pool index into the first cache line
> > > > > at no additional cost.
> > > >
> > > > I like the idea.
> > > > It means we don't need to move the pool pointer now, i.e. it does
> > > > not have to replace the timestamp field.
> > >
> > > Agreed! Don't move m->pool to the first cache line; it is not used
> > for RX.
> > >
> > > >
> > > > > In other words: This would free up another 64 bit field in the
> > mbuf
> > > > structure!
> > > >
> > > > That would be great!
> > > >
> > > >
> > > > > And even though the m->next pointer for scattered packets
> > > > > resides in the second cache line, the libraries and application
> > > > > knows that m->next is NULL when m->nb_segs is 1.
> > > > > This proves that my suggestion would make touching the second
> > > > > cache line unnecessary (in simple cases), even for
> > > > > re-initializing the mbuf.
> > > >
> > > > So you think the "next" pointer should stay in the second half of
> > mbuf?
> > > >
> > > > I feel you would like to move the Tx offloads in the first half to
> > > > improve performance of very simple apps.
> > >
> > > "Very simple apps" sounds like a minority of apps. I would rather
> > > say
> > "very simple packet handling scenarios", e.g. forwarding of normal
> > size non-segmented packets. I would guess that the vast majority of
> > packets handled by DPDK applications actually match this scenario. So
> > I'm proposing to optimize for what I think is the most common scenario.
> > >
> > > If segmented packets are common, then m->next could be moved to the
> > first cache line. But it will only improve the pure RX steps of the
> > pipeline. When preparing the packet for TX, m->tx_offloads will need
> > to be set, and the second cache line comes into play. So I'm wondering
> > how big the benefit of having m->next in the first cache line really
> > is - assuming that m->nb_segs will be checked before accessing m->next.
> > >
> > > > I am thinking the opposite: we could have some dynamic fields
> > > > space in the first half to improve performance of complex Rx.
> > > > Note: we can add a flag hint for field registration in this first
> > half.
> > > >
> > >
> > > I have had the same thoughts. However, I would prefer being able to
> > forward ordinary packets without using the second mbuf cache line at
> > all (although only in specific scenarios like my example above).
> > >
> > > Furthermore, the application can abuse the 64 bit m->tx_offload
> > > field
> > for private purposes until it is time to prepare the packet for TX and
> > pass it on to the driver. This hack somewhat resembles a dynamic field
> > in the first cache line, and will not be possible if the m->pool or m-
> > >next field is moved there.
> >
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 13:46 0% ` Morten Brørup
@ 2020-11-03 13:50 0% ` Bruce Richardson
2020-11-03 14:03 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2020-11-03 13:50 UTC (permalink / raw)
To: Morten Brørup
Cc: Thomas Monjalon, dev, techboard, Ajit Khaparde, Ananyev,
Konstantin, Andrew Rybchenko, Yigit, Ferruh, david.marchand,
olivier.matz, jerinj, viacheslavo, honnappa.nagarahalli,
maxime.coquelin, stephen, hemant.agrawal, Matan Azrad,
Shahaf Shuler
On Tue, Nov 03, 2020 at 02:46:17PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, November 3, 2020 1:26 PM
> >
> > On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Monday, November 2, 2020 4:58 PM
> > > >
> > > > +Cc techboard
> > > >
> > > > We need benchmark numbers in order to take a decision.
> > > > Please all, prepare some arguments and numbers so we can discuss
> > > > the mbuf layout in the next techboard meeting.
> > >
> > > I propose that the techboard considers this from two angels:
> > >
> > > 1. Long term goals and their relative priority. I.e. what can be
> > > achieved with wide-ranging modifications, requiring yet another ABI
> > > break and due notices.
> > >
> > > 2. Short term goals, i.e. what can be achieved for this release.
> > >
> > >
> > > My suggestions follow...
> > >
> > > 1. Regarding long term goals:
> > >
> > > I have argued that simple forwarding of non-segmented packets using
> > > only the first mbuf cache line can be achieved by making three
> > > modifications:
> > >
> > > a) Move m->tx_offload to the first cache line.
> > > b) Use an 8 bit pktmbuf mempool index in the first cache line,
> > > instead of the 64 bit m->pool pointer in the second cache line.
> > > c) Do not access m->next when we know that it is NULL.
> > > We can use m->nb_segs == 1 or some other invariant as the gate.
> > > It can be implemented by adding an m->next accessor function:
> > > struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> > > {
> > > return m->nb_segs == 1 ? NULL : m->next;
> > > }
> > >
> > > Regarding the priority of this goal, I guess that simple forwarding
> > > of non-segmented packets is probably the path taken by the majority
> > > of packets handled by DPDK.
> > >
> > >
> > > An alternative goal could be:
> > > Do not touch the second cache line during RX.
> > > A comment in the mbuf structure says so, but it is not true anymore.
> > >
> >
> > The comment should be true for non-scattered RX, I believe.
>
> You are correct.
>
> My suggestion was unclear: Extend this remark to include segmented packets.
>
> This could be a priority if the techboard considers RX segmented packets more important than my suggestion for single cache line forwarding of non-segmented packets.
>
>
> > I'm not aware of any use of second cacheline for the fast-path RXs for many drivers.
> > Am I missing something that has changed recently here?
>
> Check out eth_igb_recv_pkts() in the E1000 driver: rxm->next = NULL;
> Or pmd_rx_burst() in the TAP driver: new_tail->next = seg->next;
>
> Perhaps the documentation should describe best practices for implementing RX and TX functions in drivers, including allocating/freeing mbufs. Or an example dummy Ethernet driver could do it.
>
Yes, perhaps I should be clearer about the "fast-path", because I was
thinking of the optimized RX/TX paths for those nics at 10G and above.
Probably the documentation should indeed have an update clarifying things a
bit, since using the first cacheline only possible but not mandatory for
simple RX.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 12:25 0% ` Bruce Richardson
@ 2020-11-03 13:46 0% ` Morten Brørup
2020-11-03 13:50 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-03 13:46 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, dev, techboard, Ajit Khaparde, Ananyev,
Konstantin, Andrew Rybchenko, Yigit, Ferruh, david.marchand,
olivier.matz, jerinj, viacheslavo, honnappa.nagarahalli,
maxime.coquelin, stephen, hemant.agrawal, Matan Azrad,
Shahaf Shuler
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, November 3, 2020 1:26 PM
>
> On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Monday, November 2, 2020 4:58 PM
> > >
> > > +Cc techboard
> > >
> > > We need benchmark numbers in order to take a decision.
> > > Please all, prepare some arguments and numbers so we can discuss
> > > the mbuf layout in the next techboard meeting.
> >
> > I propose that the techboard considers this from two angels:
> >
> > 1. Long term goals and their relative priority. I.e. what can be
> > achieved with wide-ranging modifications, requiring yet another ABI
> > break and due notices.
> >
> > 2. Short term goals, i.e. what can be achieved for this release.
> >
> >
> > My suggestions follow...
> >
> > 1. Regarding long term goals:
> >
> > I have argued that simple forwarding of non-segmented packets using
> > only the first mbuf cache line can be achieved by making three
> > modifications:
> >
> > a) Move m->tx_offload to the first cache line.
> > b) Use an 8 bit pktmbuf mempool index in the first cache line,
> > instead of the 64 bit m->pool pointer in the second cache line.
> > c) Do not access m->next when we know that it is NULL.
> > We can use m->nb_segs == 1 or some other invariant as the gate.
> > It can be implemented by adding an m->next accessor function:
> > struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> > {
> > return m->nb_segs == 1 ? NULL : m->next;
> > }
> >
> > Regarding the priority of this goal, I guess that simple forwarding
> > of non-segmented packets is probably the path taken by the majority
> > of packets handled by DPDK.
> >
> >
> > An alternative goal could be:
> > Do not touch the second cache line during RX.
> > A comment in the mbuf structure says so, but it is not true anymore.
> >
>
> The comment should be true for non-scattered RX, I believe.
You are correct.
My suggestion was unclear: Extend this remark to include segmented packets.
This could be a priority if the techboard considers RX segmented packets more important than my suggestion for single cache line forwarding of non-segmented packets.
> I'm not aware of any use of second cacheline for the fast-path RXs for many drivers.
> Am I missing something that has changed recently here?
Check out eth_igb_recv_pkts() in the E1000 driver: rxm->next = NULL;
Or pmd_rx_burst() in the TAP driver: new_tail->next = seg->next;
Perhaps the documentation should describe best practices for implementing RX and TX functions in drivers, including allocating/freeing mbufs. Or an example dummy Ethernet driver could do it.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-03 12:10 4% ` Morten Brørup
@ 2020-11-03 12:25 0% ` Bruce Richardson
2020-11-03 13:46 0% ` Morten Brørup
2020-11-03 14:02 0% ` Slava Ovsiienko
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2020-11-03 12:25 UTC (permalink / raw)
To: Morten Brørup
Cc: Thomas Monjalon, dev, techboard, Ajit Khaparde, Ananyev,
Konstantin, Andrew Rybchenko, Yigit, Ferruh, david.marchand,
olivier.matz, jerinj, viacheslavo, honnappa.nagarahalli,
maxime.coquelin, stephen, hemant.agrawal, Matan Azrad,
Shahaf Shuler
On Tue, Nov 03, 2020 at 01:10:05PM +0100, Morten Brørup wrote:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Monday, November 2, 2020 4:58 PM
> >
> > +Cc techboard
> >
> > We need benchmark numbers in order to take a decision.
> > Please all, prepare some arguments and numbers so we can discuss
> > the mbuf layout in the next techboard meeting.
>
> I propose that the techboard considers this from two angels:
>
> 1. Long term goals and their relative priority. I.e. what can be
> achieved with wide-ranging modifications, requiring yet another ABI
> break and due notices.
>
> 2. Short term goals, i.e. what can be achieved for this release.
>
>
> My suggestions follow...
>
> 1. Regarding long term goals:
>
> I have argued that simple forwarding of non-segmented packets using
> only the first mbuf cache line can be achieved by making three
> modifications:
>
> a) Move m->tx_offload to the first cache line.
> b) Use an 8 bit pktmbuf mempool index in the first cache line,
> instead of the 64 bit m->pool pointer in the second cache line.
> c) Do not access m->next when we know that it is NULL.
> We can use m->nb_segs == 1 or some other invariant as the gate.
> It can be implemented by adding an m->next accessor function:
> struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
> {
> return m->nb_segs == 1 ? NULL : m->next;
> }
>
> Regarding the priority of this goal, I guess that simple forwarding
> of non-segmented packets is probably the path taken by the majority
> of packets handled by DPDK.
>
>
> An alternative goal could be:
> Do not touch the second cache line during RX.
> A comment in the mbuf structure says so, but it is not true anymore.
>
The comment should be true for non-scattered RX, I believe. I'm not aware
of any use of second cacheline for the fast-path RXs for many drivers. Am I
missing something that has changed recently here?
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-02 15:58 0% ` Thomas Monjalon
@ 2020-11-03 12:10 4% ` Morten Brørup
2020-11-03 12:25 0% ` Bruce Richardson
2020-11-03 14:02 0% ` Slava Ovsiienko
0 siblings, 2 replies; 200+ results
From: Morten Brørup @ 2020-11-03 12:10 UTC (permalink / raw)
To: Thomas Monjalon, dev, techboard
Cc: Ajit Khaparde, Ananyev, Konstantin, Andrew Rybchenko, dev, Yigit,
Ferruh, david.marchand, Richardson, Bruce, olivier.matz, jerinj,
viacheslavo, honnappa.nagarahalli, maxime.coquelin, stephen,
hemant.agrawal, viacheslavo, Matan Azrad, Shahaf Shuler
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, November 2, 2020 4:58 PM
>
> +Cc techboard
>
> We need benchmark numbers in order to take a decision.
> Please all, prepare some arguments and numbers so we can discuss
> the mbuf layout in the next techboard meeting.
I propose that the techboard considers this from two angels:
1. Long term goals and their relative priority. I.e. what can be
achieved with wide-ranging modifications, requiring yet another ABI
break and due notices.
2. Short term goals, i.e. what can be achieved for this release.
My suggestions follow...
1. Regarding long term goals:
I have argued that simple forwarding of non-segmented packets using
only the first mbuf cache line can be achieved by making three
modifications:
a) Move m->tx_offload to the first cache line.
b) Use an 8 bit pktmbuf mempool index in the first cache line,
instead of the 64 bit m->pool pointer in the second cache line.
c) Do not access m->next when we know that it is NULL.
We can use m->nb_segs == 1 or some other invariant as the gate.
It can be implemented by adding an m->next accessor function:
struct rte_mbuf * rte_mbuf_next(struct rte_mbuf * m)
{
return m->nb_segs == 1 ? NULL : m->next;
}
Regarding the priority of this goal, I guess that simple forwarding
of non-segmented packets is probably the path taken by the majority
of packets handled by DPDK.
An alternative goal could be:
Do not touch the second cache line during RX.
A comment in the mbuf structure says so, but it is not true anymore.
(I guess that regression testing didn't catch this because the tests
perform TX immediately after RX, so the cache miss just moves from
the TX to the RX part of the test application.)
2. Regarding short term goals:
The current DPDK source code looks to me like m->next is the most
frequently accessed field in the second cache line, so it makes sense
moving this to the first cache line, rather than m->pool.
Benchmarking may help here.
If we - without breaking the ABI - can introduce a gate to avoid
accessing m->next when we know that it is NULL, we should keep it in
the second cache line.
In this case, I would prefer to move m->tx_offload to the first cache
line, thereby providing a field available for application use, until
the application prepares the packet for transmission.
>
>
> 01/11/2020 21:59, Morten Brørup:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Sunday, November 1, 2020 5:38 PM
> > >
> > > 01/11/2020 10:12, Morten Brørup:
> > > > One thing has always puzzled me:
> > > > Why do we use 64 bits to indicate which memory pool
> > > > an mbuf belongs to?
> > > > The portid only uses 16 bits and an indirection index.
> > > > Why don't we use the same kind of indirection index for mbuf
> pools?
> > >
> > > I wonder what would be the cost of indirection. Probably
> neglectible.
> >
> > Probably. The portid does it, and that indirection is heavily used
> everywhere.
> >
> > The size of mbuf memory pool indirection array should be compile time
> configurable, like the size of the portid indirection array.
> >
> > And for reference, the indirection array will fit into one cache line
> if we default to 8 mbuf pools, thus supporting an 8 CPU socket system
> with one mbuf pool per CPU socket, or a 4 CPU socket system with two
> mbuf pools per CPU socket.
> >
> > (And as a side note: Our application is optimized for single-socket
> systems, and we only use one mbuf pool. I guess many applications were
> developed without carefully optimizing for multi-socket systems, and
> also just use one mbuf pool. In these cases, the mbuf structure doesn't
> really need a pool field. But it is still there, and the DPDK libraries
> use it, so we didn't bother removing it.)
> >
> > > I think it is a good proposal...
> > > ... for next year, after a deprecation notice.
> > >
> > > > I can easily imagine using one mbuf pool (or perhaps a few pools)
> > > > per CPU socket (or per physical memory bus closest to an attached
> NIC),
> > > > but not more than 256 mbuf memory pools in total.
> > > > So, let's introduce an mbufpoolid like the portid,
> > > > and cut this mbuf field down from 64 to 8 bits.
>
> We will need to measure the perf of the solution.
> There is a chance for the cost to be too much high.
>
>
> > > > If we also cut down m->pkt_len from 32 to 24 bits,
> > >
> > > Who is using packets larger than 64k? Are 16 bits enough?
> >
> > I personally consider 64k a reasonable packet size limit. Exotic
> applications with even larger packets would have to live with this
> constraint. But let's see if there are any objections. For reference,
> 64k corresponds to ca. 44 Ethernet (1500 byte) packets.
> >
> > (The limit could be 65535 bytes, to avoid translation of the value 0
> into 65536 bytes.)
> >
> > This modification would go nicely hand in hand with the mbuf pool
> indirection modification.
> >
> > ... after yet another round of ABI stability discussions,
> depreciation notices, and so on. :-)
>
> After more thoughts, I'm afraid 64k is too small in some cases.
> And 24-bit manipulation would probably break performance.
> I'm afraid we are stuck with 32-bit length.
Yes, 24 bit manipulation would probably break performance.
Perhaps a solution exists with 16 bits (least significant bits) for
the common cases, and 8 bits more (most significant bits) for the less
common cases. Just thinking out loud here...
>
> > > > we can get the 8 bit mbuf pool index into the first cache line
> > > > at no additional cost.
> > >
> > > I like the idea.
> > > It means we don't need to move the pool pointer now,
> > > i.e. it does not have to replace the timestamp field.
> >
> > Agreed! Don't move m->pool to the first cache line; it is not used
> for RX.
> >
> > >
> > > > In other words: This would free up another 64 bit field in the
> mbuf
> > > structure!
> > >
> > > That would be great!
> > >
> > >
> > > > And even though the m->next pointer for scattered packets resides
> > > > in the second cache line, the libraries and application knows
> > > > that m->next is NULL when m->nb_segs is 1.
> > > > This proves that my suggestion would make touching
> > > > the second cache line unnecessary (in simple cases),
> > > > even for re-initializing the mbuf.
> > >
> > > So you think the "next" pointer should stay in the second half of
> mbuf?
> > >
> > > I feel you would like to move the Tx offloads in the first half
> > > to improve performance of very simple apps.
> >
> > "Very simple apps" sounds like a minority of apps. I would rather say
> "very simple packet handling scenarios", e.g. forwarding of normal size
> non-segmented packets. I would guess that the vast majority of packets
> handled by DPDK applications actually match this scenario. So I'm
> proposing to optimize for what I think is the most common scenario.
> >
> > If segmented packets are common, then m->next could be moved to the
> first cache line. But it will only improve the pure RX steps of the
> pipeline. When preparing the packet for TX, m->tx_offloads will need to
> be set, and the second cache line comes into play. So I'm wondering how
> big the benefit of having m->next in the first cache line really is -
> assuming that m->nb_segs will be checked before accessing m->next.
> >
> > > I am thinking the opposite: we could have some dynamic fields space
> > > in the first half to improve performance of complex Rx.
> > > Note: we can add a flag hint for field registration in this first
> half.
> > >
> >
> > I have had the same thoughts. However, I would prefer being able to
> forward ordinary packets without using the second mbuf cache line at
> all (although only in specific scenarios like my example above).
> >
> > Furthermore, the application can abuse the 64 bit m->tx_offload field
> for private purposes until it is time to prepare the packet for TX and
> pass it on to the driver. This hack somewhat resembles a dynamic field
> in the first cache line, and will not be possible if the m->pool or m-
> >next field is moved there.
>
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks
[not found] ` <CAJFAV8wmpft6XLRg1RAL+d4ibbJVrR9C0ghkE-kqyig_q_Meeg@mail.gmail.com>
@ 2020-11-03 10:07 9% ` Kinsella, Ray
2020-11-10 12:53 8% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2020-11-03 10:07 UTC (permalink / raw)
To: David Marchand
Cc: Walsh, Conor, dpdk-dev, Luca Boccassi, Dodji Seketeli, Mcnamara, John
Hi David,
Came across an issue with this.
Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail
is not guaranteed to be 100% compatible with a older versions.
That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release,
or libabigail version depending on how you look at it.
An alter approach suggested by Dodi would be to just archive the binaries somewhere instead,
and regenerate the dumps at build time. That _may_ be feasible,
but you lose some of the benefit (build time saving) compared to archiving the abi dumps.
The most sensible approach to archiving the binaries.
is to use DPDK release os packaging for this, installed to a fs sandbox.
So the next steps are figuring out, which is the better option between
maintaining multiple abi dump archives, one per supported os distro.
or looking at what needs to happen with DPDK os packaging.
So some work still to do here.
Thanks,
Ray K
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] Ionic PMD - can we still get patches into a 20.02 stable?
2020-11-02 16:17 3% [dpdk-dev] Ionic PMD - can we still get patches into a 20.02 stable? Andrew Boyer
2020-11-02 16:25 0% ` Burakov, Anatoly
@ 2020-11-02 16:31 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2020-11-02 16:31 UTC (permalink / raw)
To: Andrew Boyer, dev
On 11/2/2020 4:17 PM, Andrew Boyer wrote:
> Hello DPDK folks,
> I am ready to start submitting some patches to bring the Pensando ionic PMD up to speed. The first batch will be a practice run of some minor things, if that’s acceptable.
>
Hi Andrew,
If you recognized 'ionic' is marked as 'UNMAINTAINED' in the current tree.
I would like to see it to get proper updates and be back up to date.
> It appears that the 20.02 release is no longer being maintained. Is that correct? Is it possible for us to get patches into a new stable release of 20.02? They would only affect our PMD and not affect the ABI or anything.
>
20.02 is no longer maintained.
xx.11 releases are long term stable releases and they are maintained for two years.
v18.11 is almost end of life, with the current release, v20.11, the v19.11 &
v20.11 will be active LTS releases.
> It looks like I have just about missed the boat on 20.11 - would you prefer patches this week or should I hold them until December?
>
As said above I am for getting updates, -rc2 is tomorrow so most probably it is
already too late.
But I am OK to get 'ionic' specific patches for -rc3 too, this gives an
additional week for this release, if it is enough for you.
But let me warn you, we are very close to the release, if something goes wrong
with this last minute code, you many not have enough time to detect and fix it
and driver may be released broken, which won't put you in a better situation.
If there are issues that you can fix and verify with confidence in this short
time frame, lets try to squeeze them, but if the changes are big I suggest
waiting the next release.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] Ionic PMD - can we still get patches into a 20.02 stable?
2020-11-02 16:17 3% [dpdk-dev] Ionic PMD - can we still get patches into a 20.02 stable? Andrew Boyer
@ 2020-11-02 16:25 0% ` Burakov, Anatoly
2020-11-02 16:31 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2020-11-02 16:25 UTC (permalink / raw)
To: Andrew Boyer, dev
On 02-Nov-20 4:17 PM, Andrew Boyer wrote:
> Hello DPDK folks,
> I am ready to start submitting some patches to bring the Pensando ionic PMD up to speed. The first batch will be a practice run of some minor things, if that’s acceptable.
>
> It appears that the 20.02 release is no longer being maintained. Is that correct? Is it possible for us to get patches into a new stable release of 20.02? They would only affect our PMD and not affect the ABI or anything.
>
> It looks like I have just about missed the boat on 20.11 - would you prefer patches this week or should I hold them until December?
>
> Thank you,
> Andrew
> Pensando
>
20.02 is not an LTS so there won't be any more releases.
You can send the patches any time, but at this stage they won't be
pulled in to 20.11. You may help maintainers by creating an account at
patchwork [1] and marking your patches as "Deferred" once you send them.
They will be marked as "New" once the development of the new release
commences.
[1] https://patchwork.dpdk.org
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* [dpdk-dev] Ionic PMD - can we still get patches into a 20.02 stable?
@ 2020-11-02 16:17 3% Andrew Boyer
2020-11-02 16:25 0% ` Burakov, Anatoly
2020-11-02 16:31 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Andrew Boyer @ 2020-11-02 16:17 UTC (permalink / raw)
To: dev
Hello DPDK folks,
I am ready to start submitting some patches to bring the Pensando ionic PMD up to speed. The first batch will be a practice run of some minor things, if that’s acceptable.
It appears that the 20.02 release is no longer being maintained. Is that correct? Is it possible for us to get patches into a new stable release of 20.02? They would only affect our PMD and not affect the ABI or anything.
It looks like I have just about missed the boat on 20.11 - would you prefer patches this week or should I hold them until December?
Thank you,
Andrew
Pensando
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
2020-11-01 20:59 3% ` Morten Brørup
@ 2020-11-02 15:58 0% ` Thomas Monjalon
2020-11-03 12:10 4% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-11-02 15:58 UTC (permalink / raw)
To: dev, techboard
Cc: Ajit Khaparde, Ananyev, Konstantin, Andrew Rybchenko, dev, Yigit,
Ferruh, david.marchand, Richardson, Bruce, olivier.matz, jerinj,
viacheslavo, honnappa.nagarahalli, maxime.coquelin, stephen,
hemant.agrawal, viacheslavo, Matan Azrad, Shahaf Shuler,
Morten Brørup
+Cc techboard
We need benchmark numbers in order to take a decision.
Please all, prepare some arguments and numbers so we can discuss
the mbuf layout in the next techboard meeting.
01/11/2020 21:59, Morten Brørup:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Sunday, November 1, 2020 5:38 PM
> >
> > 01/11/2020 10:12, Morten Brørup:
> > > One thing has always puzzled me:
> > > Why do we use 64 bits to indicate which memory pool
> > > an mbuf belongs to?
> > > The portid only uses 16 bits and an indirection index.
> > > Why don't we use the same kind of indirection index for mbuf pools?
> >
> > I wonder what would be the cost of indirection. Probably neglectible.
>
> Probably. The portid does it, and that indirection is heavily used everywhere.
>
> The size of mbuf memory pool indirection array should be compile time configurable, like the size of the portid indirection array.
>
> And for reference, the indirection array will fit into one cache line if we default to 8 mbuf pools, thus supporting an 8 CPU socket system with one mbuf pool per CPU socket, or a 4 CPU socket system with two mbuf pools per CPU socket.
>
> (And as a side note: Our application is optimized for single-socket systems, and we only use one mbuf pool. I guess many applications were developed without carefully optimizing for multi-socket systems, and also just use one mbuf pool. In these cases, the mbuf structure doesn't really need a pool field. But it is still there, and the DPDK libraries use it, so we didn't bother removing it.)
>
> > I think it is a good proposal...
> > ... for next year, after a deprecation notice.
> >
> > > I can easily imagine using one mbuf pool (or perhaps a few pools)
> > > per CPU socket (or per physical memory bus closest to an attached NIC),
> > > but not more than 256 mbuf memory pools in total.
> > > So, let's introduce an mbufpoolid like the portid,
> > > and cut this mbuf field down from 64 to 8 bits.
We will need to measure the perf of the solution.
There is a chance for the cost to be too much high.
> > > If we also cut down m->pkt_len from 32 to 24 bits,
> >
> > Who is using packets larger than 64k? Are 16 bits enough?
>
> I personally consider 64k a reasonable packet size limit. Exotic applications with even larger packets would have to live with this constraint. But let's see if there are any objections. For reference, 64k corresponds to ca. 44 Ethernet (1500 byte) packets.
>
> (The limit could be 65535 bytes, to avoid translation of the value 0 into 65536 bytes.)
>
> This modification would go nicely hand in hand with the mbuf pool indirection modification.
>
> ... after yet another round of ABI stability discussions, depreciation notices, and so on. :-)
After more thoughts, I'm afraid 64k is too small in some cases.
And 24-bit manipulation would probably break performance.
I'm afraid we are stuck with 32-bit length.
> > > we can get the 8 bit mbuf pool index into the first cache line
> > > at no additional cost.
> >
> > I like the idea.
> > It means we don't need to move the pool pointer now,
> > i.e. it does not have to replace the timestamp field.
>
> Agreed! Don't move m->pool to the first cache line; it is not used for RX.
>
> >
> > > In other words: This would free up another 64 bit field in the mbuf
> > structure!
> >
> > That would be great!
> >
> >
> > > And even though the m->next pointer for scattered packets resides
> > > in the second cache line, the libraries and application knows
> > > that m->next is NULL when m->nb_segs is 1.
> > > This proves that my suggestion would make touching
> > > the second cache line unnecessary (in simple cases),
> > > even for re-initializing the mbuf.
> >
> > So you think the "next" pointer should stay in the second half of mbuf?
> >
> > I feel you would like to move the Tx offloads in the first half
> > to improve performance of very simple apps.
>
> "Very simple apps" sounds like a minority of apps. I would rather say "very simple packet handling scenarios", e.g. forwarding of normal size non-segmented packets. I would guess that the vast majority of packets handled by DPDK applications actually match this scenario. So I'm proposing to optimize for what I think is the most common scenario.
>
> If segmented packets are common, then m->next could be moved to the first cache line. But it will only improve the pure RX steps of the pipeline. When preparing the packet for TX, m->tx_offloads will need to be set, and the second cache line comes into play. So I'm wondering how big the benefit of having m->next in the first cache line really is - assuming that m->nb_segs will be checked before accessing m->next.
>
> > I am thinking the opposite: we could have some dynamic fields space
> > in the first half to improve performance of complex Rx.
> > Note: we can add a flag hint for field registration in this first half.
> >
>
> I have had the same thoughts. However, I would prefer being able to forward ordinary packets without using the second mbuf cache line at all (although only in specific scenarios like my example above).
>
> Furthermore, the application can abuse the 64 bit m->tx_offload field for private purposes until it is time to prepare the packet for TX and pass it on to the driver. This hack somewhat resembles a dynamic field in the first cache line, and will not be possible if the m->pool or m->next field is moved there.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v16 00/23] Add DLB PMD
2020-11-01 23:29 3% ` [dpdk-dev] [PATCH v16 " Timothy McDaniel
@ 2020-11-02 14:07 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2020-11-02 14:07 UTC (permalink / raw)
To: Timothy McDaniel
Cc: dpdk-dev, Erik Gabriel Carrillo, Gage Eads, Van Haaren, Harry,
Jerin Jacob, Thomas Monjalon
On Mon, Nov 2, 2020 at 4:58 AM Timothy McDaniel
<timothy.mcdaniel@intel.com> wrote:
>
> The following patch series adds support for a new eventdev PMD. The DLB
> PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
> The DLB is a PCIe device that provides load-balanced, prioritized
> scheduling of core-to-core communication. The device consists of
> queues and arbiters that connect producer and consumer cores, and
> implements load-balanced queueing features including:
> - Lock-free multi-producer/multi-consumer operation.
> - Multiple priority levels for varying traffic types.
> - 'Direct' traffic (i.e. multi-producer/single-consumer)
> - Simple unordered load-balanced distribution.
> - Atomic lock-free load balancing across multiple consumers.
> - Queue element reordering feature allowing ordered load-balanced
> distribution.
>
> The DLB hardware supports both load balanced and directed ports and
> queues. Unlike other eventdev devices already in the repo, not all
> DLB ports and queues are equally capable. In particular, directed
> ports are limited to a single link, and must be connected to a directed
> queue.
> Additionally, even though LDB ports may link multiple queues, the
> number of queues that may be linked is limited by hardware. Another
> difference is that DLB does not have a straightforward way of carrying
> the flow_id in the queue elements (QE) that the hardware operates on.
>
> While reviewing the code, please be aware that this PMD has full
> control over the DLB hardware. Intel will be extending the DLB PMD
> in the future (not as part of this first series) with a mode that we
> refer to as the bifurcated PMD. The bifurcated PMD communicates with a
> kernel driver to configure the device, ports, and queues, and memory
> maps device MMIO so datapath operations occur purely in user-space.
>
> The framework to support both the PF PMD and bifurcated PMD exists in
> this patchset, and is why the iface.[ch] layer is present.
Series applied to dpdk-next-eventdev/for-main with the following fix. Thanks.
diff --git a/doc/guides/eventdevs/dlb.rst b/doc/guides/eventdevs/dlb.rst
index d44afcdcf..4c4f56b2b 100644
--- a/doc/guides/eventdevs/dlb.rst
+++ b/doc/guides/eventdevs/dlb.rst
@@ -2,7 +2,7 @@
Copyright(c) 2020 Intel Corporation.
Driver for the Intel® Dynamic Load Balancer (DLB)
+=================================================
-==================================================
The DPDK dlb poll mode driver supports the Intel® Dynamic Load Balancer.
>
> Major changes in V16
> ====================
> Address additional comments from David Marchand:
> - converted printfs in dlb/pf/dlb_main.c to DLB_LOG
> - fixed a repeated word error in dlb/pf/base/osdep_bitmap.h
> - caught up with marking the patches that Gage reviewed
>
> Major changes in V15
> ====================
> Address comments from David Marchand:
> - this patch-set is based on Nov 1, 2020 dpdk-next-eventdev
> - fix docs build (doxy-api.conf.in and doxy-api-index.md)
> - restore blank line in MAINTAINERS file
> - move dlb announcement in release_20_11.rst after ethdev
> - use headers = files() for exported meson public headers
> - fix a typo in 'add documentation ..." commit message
> - use eal version of cldemote
> - convert a couple of printfs to LOG messages
> - fix missing "~" in dlb documentation
> - delay introduction of _delayed token pop functions to
> token pop commit (fixes 8 or so unused function errors)
> - all patches build incrementally (gcc), and checkpatches reports
> success
> - I am not able to run clang locally. If clang errors are still
> present I will ask IT to install clang on a build server tomorrow.
>
> Major changes in V14
> ====================
> - Fixed format errors in doc/api/doxy-api-index.md
> - Delayed introduction of dlb2_consume_qe_immediate until
> add-dequeue-and-its-burst-variants.patch
> - Delayed introduction of dlb2_construct_token_pop_qe until
> add-PMD-s-token-pop-public-interface.patch
> - Delayed introduction of dlb_equeue_*_delayed until
> add dequeue and its burst variants.patch
>
> Major changes in V13
> ====================
> - removed now unused functions dlb_umwait and dlb_umonitor
>
> Major changes in V12
> ====================
> - Fix CENTOS build error: use __m128i instead of __v2di with
> _mm_stream_si128
>
> Major changes in V11
> ====================
> - removed unused function, fixing build error
> - fixed typo in port_setup commit message
> - this patch series is based on dpdk-next-eventdev
>
> Major changes in v10
> =====================
> - convert to use rte_power_monitor patches
> - replace __builtin_ia32_movntdq() with _mm_stream_si128()
> - remove unused functions in dlb_selftest.c
>
> Major changes in v9
> =====================
> - fixed a build error due to __rte_cache_aligned being placed after
> the ";" character, instead of before it.
>
> Major changes in v8 after dpdk reviews
> =====================
> - moved introduction of dlb in relnotes_20_11 to first patch in series
> - fixed underlines in dlb.rst that were too short
> - note that the code still uses its private byte-encoded versions of
> umonitor/umwait, rather than the new functions in the power
> patch that are built on top of those intrinsics. This is intentional.
>
> Major changes in v7 after dpdk reviews
> =====================
> - updated MAINTAINERS file to alphabetically insert DLB
> - don't create RTE_ symbols in PMD
> - converted to use version.map scheme
> - converted to use .._master_lcore instead of .._main_lcore
> - this patch set is based on dpdk-next-eventdev
>
> Major changes in v6 after dpdk reviews:
> =====================
> - fixed meson conditional build. Moved test into driver’s meson.build
> file instead of event/meson.build
> - documentation is populated as associated code is introduced
> - add log_register in add dynamic logging patch
> - rename RTE_xxx symbol(s) as DLB2_xxx
> - replaced function ptr enqueue_four with direct call to movdir64b
> - remove unused port_pages
> - broke up probe patch into 3 smaller patches for easier review
> - changed param order of movdir64b/movntdq to match intrinsics
> - added self to MAINTAINERS files
> - squashed announcement of availability into last patch in series
> - correct spelling errors and delete repeated words
> - DPDK_21.0 -> DPDK 21 in map file
> - add experimental banner to public structs and APIs
> - implemented other suggestions from code reviews of DLB2 PMD. The
> software is very similar in form so some DLB2 reviews comments
> were applicable to DLB as well
>
> Major changes in v5 after dpdk reviews and additional internal reviews
> by colleagues at Intel:
> ================
> - implement changes requested in code reviews by Gage Eads and Mike Chen
> - fix a memzone leak
> - convert to use eal rte-cpuflags patch from Liang Ma
>
> Major changes in v4 after dpdk reviews and additional internal reviews
> by colleagues at Intel:
> ================
> - Remove make infrastructure
> - shared code (pf/base) is now added incrementally
> - flexible interface (iface.[ch]) is now added incrementally
> - removed calls to rte_panic
> - do not call pthread_create directly
> - remove unused internal API, os_time
> - convert rte_atomic to __atomic builtins
> - broke out eventdev ABI changes, test/api changes, and new internal PCI
> named probe API
> - relocated enqueue logic to enqueue patch
>
> Major Changes in V3:
> ================
> - Fixed a memory corruption issue due to not allocating enough CQ
> memory for depths < 8. Hardware requires minimum allocation to be
> at least 8 entries.
> - Address review comments from Gage and Mattias.
> - Remove versioning
> - minor formatting changes
>
> Major changes in V2:
> ================
> - Correct ABI break that was present in V1.
> - Address some of the review comments received from Mattias.
> I will address the remaining items identified by Mattias in the next
> patch delivery.
> - General code cleanup based on internal code reviews
>
> Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
>
> Timothy McDaniel (23):
> event/dlb: add documentation and meson infrastructure
> event/dlb: add dynamic logging
> event/dlb: add private data structures and constants
> event/dlb: add definitions shared with LKM or shared code
> event/dlb: add inline functions
> event/dlb: add eventdev probe
> event/dlb: add flexible interface
> event/dlb: add probe-time hardware init
> event/dlb: add xstats
> event/dlb: add infos get and configure
> event/dlb: add queue and port default conf
> event/dlb: add queue setup
> event/dlb: add port setup
> event/dlb: add port link
> event/dlb: add port unlink and port unlinks in progress
> event/dlb: add eventdev start
> event/dlb: add enqueue and its burst variants
> event/dlb: add dequeue and its burst variants
> event/dlb: add eventdev stop and close
> event/dlb: add PMD's token pop public interface
> event/dlb: add PMD self-tests
> event/dlb: add queue and port release
> event/dlb: add timeout ticks entry point
>
> MAINTAINERS | 5 +
> app/test/test_eventdev.c | 7 +
> config/rte_config.h | 6 +
> doc/api/doxy-api-index.md | 3 +-
> doc/api/doxy-api.conf.in | 1 +
> doc/guides/eventdevs/dlb.rst | 341 ++
> doc/guides/eventdevs/index.rst | 1 +
> doc/guides/rel_notes/release_20_11.rst | 5 +
> drivers/event/dlb/dlb.c | 4079 +++++++++++++++
> drivers/event/dlb/dlb_iface.c | 79 +
> drivers/event/dlb/dlb_iface.h | 82 +
> drivers/event/dlb/dlb_inline_fns.h | 36 +
> drivers/event/dlb/dlb_log.h | 25 +
> drivers/event/dlb/dlb_priv.h | 513 ++
> drivers/event/dlb/dlb_selftest.c | 1539 ++++++
> drivers/event/dlb/dlb_user.h | 814 +++
> drivers/event/dlb/dlb_xstats.c | 1217 +++++
> drivers/event/dlb/meson.build | 22 +
> drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
> drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
> drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
> drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
> drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
> drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
> drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
> drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
> drivers/event/dlb/pf/dlb_main.c | 586 +++
> drivers/event/dlb/pf/dlb_main.h | 47 +
> drivers/event/dlb/pf/dlb_pf.c | 750 +++
> drivers/event/dlb/rte_pmd_dlb.c | 38 +
> drivers/event/dlb/rte_pmd_dlb.h | 77 +
> drivers/event/dlb/version.map | 9 +
> drivers/event/meson.build | 2 +-
> 33 files changed, 21677 insertions(+), 2 deletions(-)
> create mode 100644 doc/guides/eventdevs/dlb.rst
> create mode 100644 drivers/event/dlb/dlb.c
> create mode 100644 drivers/event/dlb/dlb_iface.c
> create mode 100644 drivers/event/dlb/dlb_iface.h
> create mode 100644 drivers/event/dlb/dlb_inline_fns.h
> create mode 100644 drivers/event/dlb/dlb_log.h
> create mode 100644 drivers/event/dlb/dlb_priv.h
> create mode 100644 drivers/event/dlb/dlb_selftest.c
> create mode 100644 drivers/event/dlb/dlb_user.h
> create mode 100644 drivers/event/dlb/dlb_xstats.c
> create mode 100644 drivers/event/dlb/meson.build
> create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
> create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
> create mode 100644 drivers/event/dlb/pf/dlb_main.c
> create mode 100644 drivers/event/dlb/pf/dlb_main.h
> create mode 100644 drivers/event/dlb/pf/dlb_pf.c
> create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
> create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
> create mode 100644 drivers/event/dlb/version.map
>
> --
> 2.6.4
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v16 00/23] Add DLB PMD
` (8 preceding siblings ...)
2020-11-01 19:26 3% ` [dpdk-dev] [PATCH v15 " Timothy McDaniel
@ 2020-11-01 23:29 3% ` Timothy McDaniel
2020-11-02 14:07 0% ` Jerin Jacob
9 siblings, 1 reply; 200+ results
From: Timothy McDaniel @ 2020-11-01 23:29 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in V16
====================
Address additional comments from David Marchand:
- converted printfs in dlb/pf/dlb_main.c to DLB_LOG
- fixed a repeated word error in dlb/pf/base/osdep_bitmap.h
- caught up with marking the patches that Gage reviewed
Major changes in V15
====================
Address comments from David Marchand:
- this patch-set is based on Nov 1, 2020 dpdk-next-eventdev
- fix docs build (doxy-api.conf.in and doxy-api-index.md)
- restore blank line in MAINTAINERS file
- move dlb announcement in release_20_11.rst after ethdev
- use headers = files() for exported meson public headers
- fix a typo in 'add documentation ..." commit message
- use eal version of cldemote
- convert a couple of printfs to LOG messages
- fix missing "~" in dlb documentation
- delay introduction of _delayed token pop functions to
token pop commit (fixes 8 or so unused function errors)
- all patches build incrementally (gcc), and checkpatches reports
success
- I am not able to run clang locally. If clang errors are still
present I will ask IT to install clang on a build server tomorrow.
Major changes in V14
====================
- Fixed format errors in doc/api/doxy-api-index.md
- Delayed introduction of dlb2_consume_qe_immediate until
add-dequeue-and-its-burst-variants.patch
- Delayed introduction of dlb2_construct_token_pop_qe until
add-PMD-s-token-pop-public-interface.patch
- Delayed introduction of dlb_equeue_*_delayed until
add dequeue and its burst variants.patch
Major changes in V13
====================
- removed now unused functions dlb_umwait and dlb_umonitor
Major changes in V12
====================
- Fix CENTOS build error: use __m128i instead of __v2di with
_mm_stream_si128
Major changes in V11
====================
- removed unused function, fixing build error
- fixed typo in port_setup commit message
- this patch series is based on dpdk-next-eventdev
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 5 +
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 3 +-
doc/api/doxy-api.conf.in | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4079 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 36 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1217 +++++
drivers/event/dlb/meson.build | 22 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
33 files changed, 21677 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half
@ 2020-11-01 20:59 3% ` Morten Brørup
2020-11-02 15:58 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2020-11-01 20:59 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ajit Khaparde, Ananyev, Konstantin, Andrew Rybchenko, dev,
Yigit, Ferruh, david.marchand, Richardson, Bruce, olivier.matz,
jerinj, viacheslavo, honnappa.nagarahalli, maxime.coquelin,
stephen, hemant.agrawal, viacheslavo, Matan Azrad, Shahaf Shuler
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Sunday, November 1, 2020 5:38 PM
>
> 01/11/2020 10:12, Morten Brørup:
> > One thing has always puzzled me:
> > Why do we use 64 bits to indicate which memory pool
> > an mbuf belongs to?
> > The portid only uses 16 bits and an indirection index.
> > Why don't we use the same kind of indirection index for mbuf pools?
>
> I wonder what would be the cost of indirection. Probably neglectible.
Probably. The portid does it, and that indirection is heavily used everywhere.
The size of mbuf memory pool indirection array should be compile time configurable, like the size of the portid indirection array.
And for reference, the indirection array will fit into one cache line if we default to 8 mbuf pools, thus supporting an 8 CPU socket system with one mbuf pool per CPU socket, or a 4 CPU socket system with two mbuf pools per CPU socket.
(And as a side note: Our application is optimized for single-socket systems, and we only use one mbuf pool. I guess many applications were developed without carefully optimizing for multi-socket systems, and also just use one mbuf pool. In these cases, the mbuf structure doesn't really need a pool field. But it is still there, and the DPDK libraries use it, so we didn't bother removing it.)
> I think it is a good proposal...
> ... for next year, after a deprecation notice.
>
> > I can easily imagine using one mbuf pool (or perhaps a few pools)
> > per CPU socket (or per physical memory bus closest to an attached NIC),
> > but not more than 256 mbuf memory pools in total.
> > So, let's introduce an mbufpoolid like the portid,
> > and cut this mbuf field down from 64 to 8 bits.
> >
> > If we also cut down m->pkt_len from 32 to 24 bits,
>
> Who is using packets larger than 64k? Are 16 bits enough?
I personally consider 64k a reasonable packet size limit. Exotic applications with even larger packets would have to live with this constraint. But let's see if there are any objections. For reference, 64k corresponds to ca. 44 Ethernet (1500 byte) packets.
(The limit could be 65535 bytes, to avoid translation of the value 0 into 65536 bytes.)
This modification would go nicely hand in hand with the mbuf pool indirection modification.
... after yet another round of ABI stability discussions, depreciation notices, and so on. :-)
>
> > we can get the 8 bit mbuf pool index into the first cache line
> > at no additional cost.
>
> I like the idea.
> It means we don't need to move the pool pointer now,
> i.e. it does not have to replace the timestamp field.
Agreed! Don't move m->pool to the first cache line; it is not used for RX.
>
> > In other words: This would free up another 64 bit field in the mbuf
> structure!
>
> That would be great!
>
>
> > And even though the m->next pointer for scattered packets resides
> > in the second cache line, the libraries and application knows
> > that m->next is NULL when m->nb_segs is 1.
> > This proves that my suggestion would make touching
> > the second cache line unnecessary (in simple cases),
> > even for re-initializing the mbuf.
>
> So you think the "next" pointer should stay in the second half of mbuf?
>
> I feel you would like to move the Tx offloads in the first half
> to improve performance of very simple apps.
"Very simple apps" sounds like a minority of apps. I would rather say "very simple packet handling scenarios", e.g. forwarding of normal size non-segmented packets. I would guess that the vast majority of packets handled by DPDK applications actually match this scenario. So I'm proposing to optimize for what I think is the most common scenario.
If segmented packets are common, then m->next could be moved to the first cache line. But it will only improve the pure RX steps of the pipeline. When preparing the packet for TX, m->tx_offloads will need to be set, and the second cache line comes into play. So I'm wondering how big the benefit of having m->next in the first cache line really is - assuming that m->nb_segs will be checked before accessing m->next.
> I am thinking the opposite: we could have some dynamic fields space
> in the first half to improve performance of complex Rx.
> Note: we can add a flag hint for field registration in this first half.
>
I have had the same thoughts. However, I would prefer being able to forward ordinary packets without using the second mbuf cache line at all (although only in specific scenarios like my example above).
Furthermore, the application can abuse the 64 bit m->tx_offload field for private purposes until it is time to prepare the packet for TX and pass it on to the driver. This hack somewhat resembles a dynamic field in the first cache line, and will not be possible if the m->pool or m->next field is moved there.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v15 00/23] Add DLB PMD
` (7 preceding siblings ...)
2020-10-31 18:17 3% ` [dpdk-dev] [PATCH v14 " Timothy McDaniel
@ 2020-11-01 19:26 3% ` Timothy McDaniel
2020-11-01 23:29 3% ` [dpdk-dev] [PATCH v16 " Timothy McDaniel
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-11-01 19:26 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in V15
====================
Address comments from David Marchand:
- this patch-set is based on Nov 1, 2020 dpdk-next-eventdev
- fix docs build (doxy-api.conf.in and doxy-api-index.md)
- restore blank line in MAINTAINERS file
- move dlb announcement in release_20_11.rst after ethdev
- use headers = files() for exported meson public headers
- fix a typo in 'add documentation ..." commit message
- use eal version of cldemote
- convert a couple of printfs to LOG messages
- fix missing "~" in dlb documentation
- delay introduction of _delayed token pop functions to
token pop commit (fixes 8 or so unused function errors)
- all patches build incrementally (gcc), and checkpatches reports
success
- I am not able to run clang locally. If clang errors are still
present I will ask IT to install clang on a build server tomorrow.
Major changes in V14
====================
- Fixed format errors in doc/api/doxy-api-index.md
- Delayed introduction of dlb2_consume_qe_immediate until
add-dequeue-and-its-burst-variants.patch
- Delayed introduction of dlb2_construct_token_pop_qe until
add-PMD-s-token-pop-public-interface.patch
- Delayed introduction of dlb_equeue_*_delayed until
add dequeue and its burst variants.patch
Major changes in V13
====================
- removed now unused functions dlb_umwait and dlb_umonitor
Major changes in V12
====================
- Fix CENTOS build error: use __m128i instead of __v2di with
_mm_stream_si128
Major changes in V11
====================
- removed unused function, fixing build error
- fixed typo in port_setup commit message
- this patch series is based on dpdk-next-eventdev
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 5 +
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 3 +-
doc/api/doxy-api.conf.in | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4079 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 36 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1217 +++++
drivers/event/dlb/meson.build | 22 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
33 files changed, 21677 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate ABI version
2020-10-19 9:41 9% ` [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate " David Marchand
2020-10-27 12:13 4% ` David Marchand
2020-11-01 14:48 4% ` Thomas Monjalon
@ 2020-11-01 15:09 4% ` Raslan Darawsheh
2 siblings, 0 replies; 200+ results
From: Raslan Darawsheh @ 2020-11-01 15:09 UTC (permalink / raw)
To: David Marchand, dev
Cc: NBU-Contact-Thomas Monjalon, Matan Azrad, Shahaf Shuler, Slava Ovsiienko
Hi,
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of David Marchand
> Sent: Monday, October 19, 2020 12:42 PM
> To: dev@dpdk.org
> Cc: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Matan Azrad
> <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>
> Subject: [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate
> ABI version
>
> The glue libraries are tightly bound to the mlx drivers of a dpdk version
> and are packaged with them.
>
> Keeping a separate ABI version prevents us from installing two versions of
> dpdk.
> Maintaining this separate version just adds confusion.
> Align the glue library ABI version to the global ABI version.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> drivers/common/mlx5/linux/meson.build | 2 +-
> drivers/common/mlx5/linux/mlx5_glue.h | 1 -
> drivers/net/mlx4/meson.build | 2 +-
> drivers/net/mlx4/mlx4_glue.h | 1 -
> 4 files changed, 2 insertions(+), 4 deletions(-)
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate ABI version
2020-11-01 14:48 4% ` Thomas Monjalon
@ 2020-11-01 15:02 7% ` Slava Ovsiienko
0 siblings, 0 replies; 200+ results
From: Slava Ovsiienko @ 2020-11-01 15:02 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon, David Marchand
Cc: dev, Matan Azrad, Shahaf Shuler, Raslan Darawsheh, Asaf Penso
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Sunday, November 1, 2020 16:49
> To: David Marchand <david.marchand@redhat.com>
> Cc: dev@dpdk.org; Matan Azrad <matan@nvidia.com>; Shahaf Shuler
> <shahafs@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; Raslan
> Darawsheh <rasland@nvidia.com>; Asaf Penso <asafp@nvidia.com>
> Subject: Re: [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate
> ABI version
>
> 19/10/2020 11:41, David Marchand:
> > The glue libraries are tightly bound to the mlx drivers of a dpdk
> > version and are packaged with them.
> >
> > Keeping a separate ABI version prevents us from installing two
> > versions of dpdk.
> > Maintaining this separate version just adds confusion.
> > Align the glue library ABI version to the global ABI version.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> There was no comment after 2 weeks, it should be merged.
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>
Looks safe and provides an automatic ABI version update for mlx*_glue modules.
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate ABI version
2020-10-19 9:41 9% ` [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate " David Marchand
2020-10-27 12:13 4% ` David Marchand
@ 2020-11-01 14:48 4% ` Thomas Monjalon
2020-11-01 15:02 7% ` Slava Ovsiienko
2020-11-01 15:09 4% ` Raslan Darawsheh
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-11-01 14:48 UTC (permalink / raw)
To: David Marchand
Cc: dev, Matan Azrad, Shahaf Shuler, Viacheslav Ovsiienko, rasland, asafp
19/10/2020 11:41, David Marchand:
> The glue libraries are tightly bound to the mlx drivers of a dpdk version
> and are packaged with them.
>
> Keeping a separate ABI version prevents us from installing two versions of
> dpdk.
> Maintaining this separate version just adds confusion.
> Align the glue library ABI version to the global ABI version.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
There was no comment after 2 weeks, it should be merged.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v14 00/23] Add DLB PMD
` (6 preceding siblings ...)
2020-10-31 2:12 3% ` [dpdk-dev] [PATCH v13 " Timothy McDaniel
@ 2020-10-31 18:17 3% ` Timothy McDaniel
2020-11-01 19:26 3% ` [dpdk-dev] [PATCH v15 " Timothy McDaniel
2020-11-01 23:29 3% ` [dpdk-dev] [PATCH v16 " Timothy McDaniel
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-31 18:17 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in V14
====================
- Fixed format errors in doc/api/doxy-api-index.md
- Delayed introduction of dlb2_consume_qe_immediate until
add-dequeue-and-its-burst-variants.patch
- Delayed introduction of dlb2_construct_token_pop_qe until
add-PMD-s-token-pop-public-interface.patch
- Delayed introduction of dlb_equeue_*_delayed until
add dequeue and its burst variants.patch
Major changes in V13
====================
- removed now unused functions dlb_umwait and dlb_umonitor
Major changes in V12
====================
- Fix CENTOS build error: use __m128i instead of __v2di with
_mm_stream_si128
Major changes in V11
====================
- removed unused function, fixing build error
- fixed typo in port_setup commit message
- this patch series is based on dpdk-next-eventdev
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 3 +-
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4079 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 40 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21684 insertions(+), 3 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v13 00/23] Add DLB PMD
2020-10-31 2:12 3% ` [dpdk-dev] [PATCH v13 " Timothy McDaniel
@ 2020-10-31 12:49 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2020-10-31 12:49 UTC (permalink / raw)
To: Timothy McDaniel
Cc: dpdk-dev, Erik Gabriel Carrillo, Gage Eads, Van Haaren, Harry,
Jerin Jacob, Thomas Monjalon
On Sat, Oct 31, 2020 at 7:41 AM Timothy McDaniel
<timothy.mcdaniel@intel.com> wrote:
>
> The following patch series adds support for a new eventdev PMD. The DLB
> PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
> The DLB is a PCIe device that provides load-balanced, prioritized
> scheduling of core-to-core communication. The device consists of
> queues and arbiters that connect producer and consumer cores, and
> implements load-balanced queueing features including:
> - Lock-free multi-producer/multi-consumer operation.
> - Multiple priority levels for varying traffic types.
> - 'Direct' traffic (i.e. multi-producer/single-consumer)
> - Simple unordered load-balanced distribution.
> - Atomic lock-free load balancing across multiple consumers.
> - Queue element reordering feature allowing ordered load-balanced
> distribution.
>
> The DLB hardware supports both load balanced and directed ports and
> queues. Unlike other eventdev devices already in the repo, not all
> DLB ports and queues are equally capable. In particular, directed
> ports are limited to a single link, and must be connected to a directed
> queue.
> Additionally, even though LDB ports may link multiple queues, the
> number of queues that may be linked is limited by hardware. Another
> difference is that DLB does not have a straightforward way of carrying
> the flow_id in the queue elements (QE) that the hardware operates on.
>
> While reviewing the code, please be aware that this PMD has full
> control over the DLB hardware. Intel will be extending the DLB PMD
> in the future (not as part of this first series) with a mode that we
> refer to as the bifurcated PMD. The bifurcated PMD communicates with a
> kernel driver to configure the device, ports, and queues, and memory
> maps device MMIO so datapath operations occur purely in user-space.
>
> The framework to support both the PF PMD and bifurcated PMD exists in
> this patchset, and is why the iface.[ch] layer is present.
>
> Major changes in V13
> ====================
> - removed now unused functions dlb_umwait and dlb_umonitor
build error with clang at "event/dlb: add enqueue and its burst
variants" patch. Please make sure each patch builds to avoid delay in
merging the patch.
Also, address the David comment on the doc for the next version.
FAILED: drivers/libtmp_rte_event_dlb.a.p/event_dlb_dlb.c.o
ccache clang -Idrivers/libtmp_rte_event_dlb.a.p -Idrivers -I../drivers
-Idrivers/event/dlb -I../drivers/event/dlb -Ilib/librte_eventdev
-I../lib/librte_eventdev -I. -I.. -Iconfig -I../config
-Ilib/librte_eal/include -I../lib/librte_eal/incl
ude -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include
-Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include
-Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal
-I../lib/librte_eal -Ilib/librte_kvargs -I
../lib/librte_kvargs -Ilib/librte_metrics -I../lib/librte_metrics
-Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_ring
-I../lib/librte_ring -Ilib/librte_ethdev -I../lib/librte_ethdev
-Ilib/librte_net -I../lib/librte_net -Ilib/
librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool
-I../lib/librte_mempool -Ilib/librte_meter -I../lib/librte_meter
-Ilib/librte_hash -I../lib/librte_hash -Ilib/librte_rcu
-I../lib/librte_rcu -Ilib/librte_timer -I../lib/librte_timer -Ili
b/librte_cryptodev -I../lib/librte_cryptodev -Ilib/librte_pci
-I../lib/librte_pci -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Xclang -fcolor-diagnostics -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O2 -g
-include rte_config.h -Wextra -Wcast-qual -Wdeprecated
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition
-Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwr
ite-strings -Wno-address-of-packed-member
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -MD -MQ
drivers/libtmp_rte_event_dlb.a.p/event_dlb_dlb.c.o -MF
drivers/libtmp_rte_even
t_dlb.a.p/event_dlb_dlb.c.o.d -o
drivers/libtmp_rte_event_dlb.a.p/event_dlb_dlb.c.o -c
../drivers/event/dlb/dlb.c
../drivers/event/dlb/dlb.c:2777:1: error: unused function
'dlb_event_enqueue_delayed' [-Werror,-Wunused-function]
dlb_event_enqueue_delayed(void *event_port,
^
../drivers/event/dlb/dlb.c:2762:1: error: unused function
'dlb_event_enqueue_burst_delayed' [-Werror,-Wunused-function]
dlb_event_enqueue_burst_delayed(void *event_port,
^
../drivers/event/dlb/dlb.c:2792:1: error: unused function
'dlb_event_enqueue_new_burst_delayed' [-Werror,-Wunused-function]
dlb_event_enqueue_new_burst_delayed(void *event_port,
^
../drivers/event/dlb/dlb.c:2808:1: error: unused function
'dlb_event_enqueue_forward_burst_delayed' [-Werror,-Wunused-function]
dlb_event_enqueue_forward_burst_delayed(void *event_port,
^
../drivers/event/dlb/dlb.c:2605:1: error: unused function
'dlb_construct_token_pop_qe' [-Werror,-Wunused-function]
dlb_construct_token_pop_qe(struct dlb_port *qm_port, int idx)
^
../drivers/event/dlb/dlb.c:2653:1: error: unused function
'dlb_consume_qe_immediate' [-Werror,-Wunused-function]
dlb_consume_qe_immediate(struct dlb_port *qm_port, int num)
^
6 errors generated.
>
> Major changes in V12
> ====================
> - Fix CENTOS build error: use __m128i instead of __v2di with
> _mm_stream_si128
>
> Major changes in V11
> ====================
> - removed unused function, fixing build error
> - fixed typo in port_setup commit message
> - this patch series is based on dpdk-next-eventdev
>
> Major changes in v10
> =====================
> - convert to use rte_power_monitor patches
> - replace __builtin_ia32_movntdq() with _mm_stream_si128()
> - remove unused functions in dlb_selftest.c
>
> Major changes in v9
> =====================
> - fixed a build error due to __rte_cache_aligned being placed after
> the ";" character, instead of before it.
>
> Major changes in v8 after dpdk reviews
> =====================
> - moved introduction of dlb in relnotes_20_11 to first patch in series
> - fixed underlines in dlb.rst that were too short
> - note that the code still uses its private byte-encoded versions of
> umonitor/umwait, rather than the new functions in the power
> patch that are built on top of those intrinsics. This is intentional.
>
> Major changes in v7 after dpdk reviews
> =====================
> - updated MAINTAINERS file to alphabetically insert DLB
> - don't create RTE_ symbols in PMD
> - converted to use version.map scheme
> - converted to use .._master_lcore instead of .._main_lcore
> - this patch set is based on dpdk-next-eventdev
>
> Major changes in v6 after dpdk reviews:
> =====================
> - fixed meson conditional build. Moved test into driver’s meson.build
> file instead of event/meson.build
> - documentation is populated as associated code is introduced
> - add log_register in add dynamic logging patch
> - rename RTE_xxx symbol(s) as DLB2_xxx
> - replaced function ptr enqueue_four with direct call to movdir64b
> - remove unused port_pages
> - broke up probe patch into 3 smaller patches for easier review
> - changed param order of movdir64b/movntdq to match intrinsics
> - added self to MAINTAINERS files
> - squashed announcement of availability into last patch in series
> - correct spelling errors and delete repeated words
> - DPDK_21.0 -> DPDK 21 in map file
> - add experimental banner to public structs and APIs
> - implemented other suggestions from code reviews of DLB2 PMD. The
> software is very similar in form so some DLB2 reviews comments
> were applicable to DLB as well
>
> Major changes in v5 after dpdk reviews and additional internal reviews
> by colleagues at Intel:
> ================
> - implement changes requested in code reviews by Gage Eads and Mike Chen
> - fix a memzone leak
> - convert to use eal rte-cpuflags patch from Liang Ma
>
> Major changes in v4 after dpdk reviews and additional internal reviews
> by colleagues at Intel:
> ================
> - Remove make infrastructure
> - shared code (pf/base) is now added incrementally
> - flexible interface (iface.[ch]) is now added incrementally
> - removed calls to rte_panic
> - do not call pthread_create directly
> - remove unused internal API, os_time
> - convert rte_atomic to __atomic builtins
> - broke out eventdev ABI changes, test/api changes, and new internal PCI
> named probe API
> - relocated enqueue logic to enqueue patch
>
> Major Changes in V3:
> ================
> - Fixed a memory corruption issue due to not allocating enough CQ
> memory for depths < 8. Hardware requires minimum allocation to be
> at least 8 entries.
> - Address review comments from Gage and Mattias.
> - Remove versioning
> - minor formatting changes
>
> Major changes in V2:
> ================
> - Correct ABI break that was present in V1.
> - Address some of the review comments received from Mattias.
> I will address the remaining items identified by Mattias in the next
> patch delivery.
> - General code cleanup based on internal code reviews
>
> Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
>
> Timothy McDaniel (23):
> event/dlb: add documentation and meson infrastructure
> event/dlb: add dynamic logging
> event/dlb: add private data structures and constants
> event/dlb: add definitions shared with LKM or shared code
> event/dlb: add inline functions
> event/dlb: add eventdev probe
> event/dlb: add flexible interface
> event/dlb: add probe-time hardware init
> event/dlb: add xstats
> event/dlb: add infos get and configure
> event/dlb: add queue and port default conf
> event/dlb: add queue setup
> event/dlb: add port setup
> event/dlb: add port link
> event/dlb: add port unlink and port unlinks in progress
> event/dlb: add eventdev start
> event/dlb: add enqueue and its burst variants
> event/dlb: add dequeue and its burst variants
> event/dlb: add eventdev stop and close
> event/dlb: add PMD's token pop public interface
> event/dlb: add PMD self-tests
> event/dlb: add queue and port release
> event/dlb: add timeout ticks entry point
>
> MAINTAINERS | 6 +-
> app/test/test_eventdev.c | 7 +
> config/rte_config.h | 6 +
> doc/api/doxy-api-index.md | 1 +
> doc/guides/eventdevs/dlb.rst | 341 ++
> doc/guides/eventdevs/index.rst | 1 +
> doc/guides/rel_notes/release_20_11.rst | 5 +
> drivers/event/dlb/dlb.c | 4080 +++++++++++++++
> drivers/event/dlb/dlb_iface.c | 79 +
> drivers/event/dlb/dlb_iface.h | 82 +
> drivers/event/dlb/dlb_inline_fns.h | 40 +
> drivers/event/dlb/dlb_log.h | 25 +
> drivers/event/dlb/dlb_priv.h | 513 ++
> drivers/event/dlb/dlb_selftest.c | 1539 ++++++
> drivers/event/dlb/dlb_user.h | 814 +++
> drivers/event/dlb/dlb_xstats.c | 1222 +++++
> drivers/event/dlb/meson.build | 21 +
> drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
> drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
> drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
> drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
> drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
> drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
> drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
> drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
> drivers/event/dlb/pf/dlb_main.c | 586 +++
> drivers/event/dlb/pf/dlb_main.h | 47 +
> drivers/event/dlb/pf/dlb_pf.c | 750 +++
> drivers/event/dlb/rte_pmd_dlb.c | 38 +
> drivers/event/dlb/rte_pmd_dlb.h | 77 +
> drivers/event/dlb/version.map | 9 +
> drivers/event/meson.build | 2 +-
> 32 files changed, 21684 insertions(+), 2 deletions(-)
> create mode 100644 doc/guides/eventdevs/dlb.rst
> create mode 100644 drivers/event/dlb/dlb.c
> create mode 100644 drivers/event/dlb/dlb_iface.c
> create mode 100644 drivers/event/dlb/dlb_iface.h
> create mode 100644 drivers/event/dlb/dlb_inline_fns.h
> create mode 100644 drivers/event/dlb/dlb_log.h
> create mode 100644 drivers/event/dlb/dlb_priv.h
> create mode 100644 drivers/event/dlb/dlb_selftest.c
> create mode 100644 drivers/event/dlb/dlb_user.h
> create mode 100644 drivers/event/dlb/dlb_xstats.c
> create mode 100644 drivers/event/dlb/meson.build
> create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
> create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
> create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
> create mode 100644 drivers/event/dlb/pf/dlb_main.c
> create mode 100644 drivers/event/dlb/pf/dlb_main.h
> create mode 100644 drivers/event/dlb/pf/dlb_pf.c
> create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
> create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
> create mode 100644 drivers/event/dlb/version.map
>
> --
> 2.6.4
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v13 00/23] Add DLB PMD
` (5 preceding siblings ...)
2020-10-31 1:19 3% ` [dpdk-dev] [PATCH v12 " Timothy McDaniel
@ 2020-10-31 2:12 3% ` Timothy McDaniel
2020-10-31 12:49 0% ` Jerin Jacob
2020-10-31 18:17 3% ` [dpdk-dev] [PATCH v14 " Timothy McDaniel
` (2 subsequent siblings)
9 siblings, 1 reply; 200+ results
From: Timothy McDaniel @ 2020-10-31 2:12 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in V13
====================
- removed now unused functions dlb_umwait and dlb_umonitor
Major changes in V12
====================
- Fix CENTOS build error: use __m128i instead of __v2di with
_mm_stream_si128
Major changes in V11
====================
- removed unused function, fixing build error
- fixed typo in port_setup commit message
- this patch series is based on dpdk-next-eventdev
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4080 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 40 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21684 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v12 00/23] Add DLB PMD
` (4 preceding siblings ...)
2020-10-30 23:41 3% ` [dpdk-dev] [PATCH v11 " Timothy McDaniel
@ 2020-10-31 1:19 3% ` Timothy McDaniel
2020-10-31 2:12 3% ` [dpdk-dev] [PATCH v13 " Timothy McDaniel
` (3 subsequent siblings)
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-31 1:19 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in V12
====================
- Fix CENTOS build error: use __m128i instead of __v2di with
_mm_stream_si128
Major changes in V11
====================
- removed unused function, fixing build error
- fixed typo in port_setup commit message
- this patch series is based on dpdk-next-eventdev
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4080 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21703 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v11 00/23] Add DLB PMD
` (3 preceding siblings ...)
2020-10-30 18:27 3% ` [dpdk-dev] [PATCH v10 " Timothy McDaniel
@ 2020-10-30 23:41 3% ` Timothy McDaniel
2020-10-31 1:19 3% ` [dpdk-dev] [PATCH v12 " Timothy McDaniel
` (4 subsequent siblings)
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-30 23:41 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in V11
====================
- removed unused function, fixing build error
- fixed typo in port_setup commit message
- this patch series is based on dpdk-next-eventdev
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4080 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21703 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v10 00/23] Add DLB PMD
` (2 preceding siblings ...)
2020-10-30 12:41 3% ` [dpdk-dev] [PATCH v9 " Timothy McDaniel
@ 2020-10-30 18:27 3% ` Timothy McDaniel
2020-10-30 23:41 3% ` [dpdk-dev] [PATCH v11 " Timothy McDaniel
` (5 subsequent siblings)
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-30 18:27 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in v10
=====================
- convert to use rte_power_monitor patches
- replace __builtin_ia32_movntdq() with _mm_stream_si128()
- remove unused functions in dlb_selftest.c
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Depends-on: patch-79539 ("eal: add new x86 cpuid support for WAITPKG")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4092 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1539 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21715 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-30 4:24 0% ` Gujjar, Abhinandan S
@ 2020-10-30 17:18 0% ` Gujjar, Abhinandan S
0 siblings, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-30 17:18 UTC (permalink / raw)
To: Akhil Goyal, Honnappa Nagarahalli, Richardson, Bruce,
Ray Kinsella, Thomas Monjalon
Cc: Ananyev, Konstantin, dev, Doherty, Declan, techboard, Vangati,
Narender, jerinj, nd
Hi Akhil,
I have sent the v6 patch for RC2.
As discussed, I will get the test app updated for dequeue callback for RC3.
Thanks
Abhinandan
> -----Original Message-----
> From: Gujjar, Abhinandan S
> Sent: Friday, October 30, 2020 9:54 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Ray Kinsella <mdr@ashroe.eu>; Thomas
> Monjalon <thomas@monjalon.net>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>; techboard@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; jerinj@marvell.com; nd
> <nd@arm.com>
> Subject: RE: [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback
> functions
>
>
> Thanks Tech board & Akhil for clarifying the concern.
> Sure. I will send the new version of the patch.
>
> Regards
> Abhinandan
>
> > -----Original Message-----
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > Sent: Thursday, October 29, 2020 7:31 PM
> > To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Honnappa
> > Nagarahalli <Honnappa.Nagarahalli@arm.com>; Richardson, Bruce
> > <bruce.richardson@intel.com>; Ray Kinsella <mdr@ashroe.eu>; Thomas
> > Monjalon <thomas@monjalon.net>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org;
> > Doherty, Declan <declan.doherty@intel.com>; techboard@dpdk.org;
> > Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com; nd
> > <nd@arm.com>
> > Subject: RE: [dpdk-techboard] [v4 1/3] cryptodev: support enqueue
> > callback functions
> >
> > >
> > > Hi Akhil,
> > >
> > > Any updates on this?
> > >
> > There has been no objections for this patch from techboard.
> >
> > @Thomas Monjalon: could you please review the release notes.
> > I believe there should be a bullet for API changes to add 2 new fields
> > in rte_cryptodev.
> > What do you suggest?
> >
> > @Gujjar, Abhinandan S
> > Please send a new version for comments on errno.
> > If possible add cases for deq_cbs as well. If not, send it by next week.
>
> >
> > Regards,
> > Akhil
> > > > + Ray for ABI
> > > >
> > > > <snip>
> > > >
> > > > >
> > > > > On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
> > > > > >
> > > > > > Hi Konstantin,
> > > > > >
> > > > > > > > > Hi Tech board members,
> > > > > > > > >
> > > > > > > > > I have a doubt about the ABI breakage in below addition of field.
> > > > > > > > > Could you please comment.
> > > > > > > > >
> > > > > > > > > > /** The data structure associated with each crypto device.
> > > > > > > > > > */ struct rte_cryptodev {
> > > > > > > > > > dequeue_pkt_burst_t dequeue_burst; @@ -867,6
> +922,10
> > > > > @@
> > > > > > > > > > struct rte_cryptodev {
> > > > > > > > > > __extension__
> > > > > > > > > > uint8_t attached : 1;
> > > > > > > > > > /**< Flag indicating the device is attached */
> > > > > > > > > > +
> > > > > > > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > > > > > > + /**< User application callback for pre enqueue
> > > > > > > > > > +processing */
> > > > > > > > > > +
> > > > > > > > > > } __rte_cache_aligned;
> > > > > > > > >
> > > > > > > > > Here rte_cryptodevs is defined in stable API list in map
> > > > > > > > > file which is a pointer To all rte_cryptodev and the
> > > > > > > > > above change is changing the size of the
> > > > > > > structure.
> > > > > > >
> > > > > > > While this patch adds new fields into rte_cryptodev
> > > > > > > structure, it doesn't change the size of it.
> > > > > > > struct rte_cryptodev is cache line aligned, so it's current size:
> > > > > > > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > > > > > > So for 64-bit we have 47B implicitly reserved, and for
> > > > > > > 32-bit we have 19B reserved.
> > > > > > > That's enough to add two pointers without changing size of this
> struct.
> > > > > > >
> > > > > >
> > > > > > The structure is cache aligned, and if the cache line size in
> > > > > > 32Byte and the compilation is done on 64bit machine, then we
> > > > > > will be left with 15Bytes which is not sufficient for 2 pointers.
> > > > > > Do we have such systems? Am I missing something?
> > > > > >
> > > > >
> > > > > I don't think we support any such systems, so unless someone can
> > > > > point out a specific case where we need to support 32-byte CLs,
> > > > > I'd tend towards ignoring this as a non-issue.
> > > > Agree. I have not come across 32B cache line.
> > > >
> > > > >
> > > > > > The reason I brought this into techboard is to have a
> > > > > > consensus on such change As rte_cryptodev is a very popular and
> stable structure.
> > > > > > Any changes to it may Have impacts which one person cannot
> > > > > > judge all use
> > > > > cases.
> > > > > >
> > > > >
> > > > > Haven't been tracking this discussion much, but from what I read
> > > > > here, this doesn't look like an ABI break and should be ok.
> > > > If we are filling the holes in the cache line with new fields, it
> > > > should not be an ABI break.
> > > >
> > > > >
> > > > > Regards,
> > > > > /Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v9 00/23] Add DLB PMD
2020-10-29 14:57 3% ` [dpdk-dev] [PATCH v7 00/23] Add DLB PMD Timothy McDaniel
2020-10-30 9:40 3% ` [dpdk-dev] [PATCH v8 " Timothy McDaniel
@ 2020-10-30 12:41 3% ` Timothy McDaniel
2020-10-30 18:27 3% ` [dpdk-dev] [PATCH v10 " Timothy McDaniel
` (6 subsequent siblings)
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-30 12:41 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in v9
=====================
- fixed a build error due to __rte_cache_aligned being placed after
the ";" character, instead of before it.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Depends-on: patch-79539 ("eal: add new x86 cpuid support for WAITPKG")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4129 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1551 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21764 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v8 00/23] Add DLB PMD
2020-10-29 14:57 3% ` [dpdk-dev] [PATCH v7 00/23] Add DLB PMD Timothy McDaniel
@ 2020-10-30 9:40 3% ` Timothy McDaniel
2020-10-30 12:41 3% ` [dpdk-dev] [PATCH v9 " Timothy McDaniel
` (7 subsequent siblings)
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-30 9:40 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in v8 after dpdk reviews
=====================
- moved introduction of dlb in relnotes_20_11 to first patch in series
- fixed underlines in dlb.rst that were too short
- note that the code still uses its private byte-encoded versions of
umonitor/umwait, rather than the new functions in the power
patch that are built on top of those intrinsics. This is intentional.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Depends-on: patch-79539 ("eal: add new x86 cpuid support for WAITPKG")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4129 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1551 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21764 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions
@ 2020-10-28 23:10 2% ` Abhinandan Gujjar
0 siblings, 0 replies; 200+ results
From: Abhinandan Gujjar @ 2020-10-28 23:10 UTC (permalink / raw)
To: dev, declan.doherty, akhil.goyal, Honnappa.Nagarahalli,
konstantin.ananyev
Cc: narender.vangati, jerinj, abhinandan.gujjar
This patch adds APIs to add/remove callback functions on crypto
enqueue/dequeue burst. The callback function will be called for
each burst of crypto ops received/sent on a given crypto device
queue pair.
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
config/rte_config.h | 1 +
doc/guides/prog_guide/cryptodev_lib.rst | 47 ++++
doc/guides/rel_notes/release_20_11.rst | 9 +
lib/librte_cryptodev/meson.build | 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 404 +++++++++++++++++++++++++++++++-
lib/librte_cryptodev/rte_cryptodev.h | 260 +++++++++++++++++++-
lib/librte_cryptodev/version.map | 4 +
7 files changed, 724 insertions(+), 3 deletions(-)
diff --git a/config/rte_config.h b/config/rte_config.h
index 8aa46a1..0e3ddbb 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -62,6 +62,7 @@
/* cryptodev defines */
#define RTE_CRYPTO_MAX_DEVS 64
#define RTE_CRYPTODEV_NAME_LEN 64
+#define RTE_CRYPTO_CALLBACKS 1
/* compressdev defines */
#define RTE_COMPRESS_MAX_DEVS 64
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 72129e4..9d0ff59 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -338,6 +338,53 @@ start of private data information. The offset is counted from the start of the
rte_crypto_op including other crypto information such as the IVs (since there can
be an IV also for authentication).
+User callback APIs
+~~~~~~~~~~~~~~~~~~
+The add APIs configures a user callback function to be called for each burst of crypto
+ops received/sent on a given crypto device queue pair. The return value is a pointer
+that can be used later to remove the callback API. Application is expected to register
+a callback function of type ``rte_cryptodev_callback_fn``. Multiple callback functions
+can be added for a given queue pair. API does not restrict on maximum number of
+callbacks.
+
+Callbacks registered by application would not survive rte_cryptodev_configure() as it
+reinitializes the callback list. It is user responsibility to remove all installed
+callbacks before calling rte_cryptodev_configure() to avoid possible memory leakage.
+
+So, application is expected to add user callback after rte_cryptodev_configure().
+The callbacks can also be added at the runtime. These callbacks get executed when
+``rte_cryptodev_enqueue_burst``/``rte_cryptodev_dequeue_burst`` is called.
+
+.. code-block:: c
+
+ struct rte_cryptodev_cb *
+ rte_cryptodev_add_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+ struct rte_cryptodev_cb *
+ rte_cryptodev_add_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+ uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
+ struct rte_crypto_op **ops, uint16_t nb_ops, void *user_param);
+
+The remove API removes a callback function added by
+``rte_cryptodev_add_enq_callback``/``rte_cryptodev_add_deq_callback''.
+
+.. code-block:: c
+
+ int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
+ int rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
Enqueue / Dequeue Burst APIs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index bae39b2..33e190a 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -235,6 +235,12 @@ New Features
enqueue/dequeue operations but does not necessarily depends on
mbufs and cryptodev operation mempools.
+* **Added enqueue & dequeue callback APIs for cryptodev library.**
+
+ Cryptodev library is added with enqueue & dequeue callback APIs to
+ enable applications to add/remove user callbacks which gets called
+ for every enqueue/dequeue operation.
+
* **Updated the aesni_mb crypto PMD.**
* Added support for AES-ECB 128, 192 and 256.
@@ -492,6 +498,9 @@ API Changes
``RTE_CRYPTO_AUTH_LIST_END`` from ``enum rte_crypto_auth_algorithm``
are removed to avoid future ABI breakage while adding new algorithms.
+* cryptodev: The structure ``rte_cryptodev`` has been updated with pointers
+ for adding enqueue and dequeue callbacks.
+
* scheduler: Renamed functions ``rte_cryptodev_scheduler_slave_attach``,
``rte_cryptodev_scheduler_slave_detach`` and
``rte_cryptodev_scheduler_slaves_get`` to
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index c4c6b3b..8c5493f 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
'rte_crypto.h',
'rte_crypto_sym.h',
'rte_crypto_asym.h')
-deps += ['kvargs', 'mbuf']
+deps += ['kvargs', 'mbuf', 'rcu']
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 3d95ac6..eb8c832 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -448,6 +448,124 @@ struct rte_cryptodev_sym_session_pool_private_data {
return 0;
}
+#ifdef RTE_CRYPTO_CALLBACKS
+/* spinlock for crypto device enq callbacks */
+static rte_spinlock_t rte_cryptodev_callback_lock = RTE_SPINLOCK_INITIALIZER;
+
+static void
+cryptodev_cb_cleanup(struct rte_cryptodev *dev)
+{
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb, *next;
+ uint16_t qp_id;
+
+ if (dev->enq_cbs == NULL && dev->deq_cbs == NULL)
+ return;
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->enq_cbs[qp_id];
+ cb = list->next;
+ while (cb != NULL) {
+ next = cb->next;
+ rte_free(cb);
+ cb = next;
+ }
+
+ rte_free(list->qsbr);
+ }
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->deq_cbs[qp_id];
+ cb = list->next;
+ while (cb != NULL) {
+ next = cb->next;
+ rte_free(cb);
+ cb = next;
+ }
+
+ rte_free(list->qsbr);
+ }
+
+ rte_free(dev->enq_cbs);
+ dev->enq_cbs = NULL;
+ rte_free(dev->deq_cbs);
+ dev->deq_cbs = NULL;
+}
+
+static int
+cryptodev_cb_init(struct rte_cryptodev *dev)
+{
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_rcu_qsbr *qsbr;
+ uint16_t qp_id;
+ size_t size;
+
+ /* Max thread set to 1, as one DP thread accessing a queue-pair */
+ const uint32_t max_threads = 1;
+
+ dev->enq_cbs = rte_zmalloc(NULL,
+ sizeof(struct rte_cryptodev_cb_rcu) *
+ dev->data->nb_queue_pairs, 0);
+ if (dev->enq_cbs == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for enq callbacks");
+ return -ENOMEM;
+ }
+
+ dev->deq_cbs = rte_zmalloc(NULL,
+ sizeof(struct rte_cryptodev_cb_rcu) *
+ dev->data->nb_queue_pairs, 0);
+ if (dev->deq_cbs == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for deq callbacks");
+ rte_free(dev->enq_cbs);
+ return -ENOMEM;
+ }
+
+ /* Create RCU QSBR variable */
+ size = rte_rcu_qsbr_get_memsize(max_threads);
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->enq_cbs[qp_id];
+ qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
+ if (qsbr == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ if (rte_rcu_qsbr_init(qsbr, max_threads)) {
+ CDEV_LOG_ERR("Failed to initialize for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ list->qsbr = qsbr;
+ }
+
+ for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+ list = &dev->deq_cbs[qp_id];
+ qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
+ if (qsbr == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ if (rte_rcu_qsbr_init(qsbr, max_threads)) {
+ CDEV_LOG_ERR("Failed to initialize for RCU on "
+ "queue_pair_id=%d", qp_id);
+ goto cb_init_err;
+ }
+
+ list->qsbr = qsbr;
+ }
+
+ return 0;
+
+cb_init_err:
+ cryptodev_cb_cleanup(dev);
+ return -ENOMEM;
+}
+#endif
const char *
rte_cryptodev_get_feature_name(uint64_t flag)
@@ -927,6 +1045,11 @@ struct rte_cryptodev *
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP);
+#ifdef RTE_CRYPTO_CALLBACKS
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ cryptodev_cb_cleanup(dev);
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+#endif
/* Setup new number of queue pairs and reconfigure device. */
diag = rte_cryptodev_queue_pairs_config(dev, config->nb_queue_pairs,
config->socket_id);
@@ -936,11 +1059,19 @@ struct rte_cryptodev *
return diag;
}
+#ifdef RTE_CRYPTO_CALLBACKS
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ diag = cryptodev_cb_init(dev);
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+ if (diag) {
+ CDEV_LOG_ERR("Callback init failed for dev_id=%d", dev_id);
+ return diag;
+ }
+#endif
rte_cryptodev_trace_configure(dev_id, config);
return (*dev->dev_ops->dev_configure)(dev, config);
}
-
int
rte_cryptodev_start(uint8_t dev_id)
{
@@ -1136,6 +1267,277 @@ struct rte_cryptodev *
socket_id);
}
+#ifdef RTE_CRYPTO_CALLBACKS
+struct rte_cryptodev_cb *
+rte_cryptodev_add_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb, *tail;
+
+ if (!cb_fn) {
+ CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+ if (cb == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for callback on "
+ "dev=%d, queue_pair_id=%d", dev_id, qp_id);
+ rte_errno = ENOMEM;
+ return NULL;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+
+ cb->fn = cb_fn;
+ cb->arg = cb_arg;
+
+ /* Add the callbacks in fifo order. */
+ list = &dev->enq_cbs[qp_id];
+ tail = list->next;
+
+ if (tail) {
+ while (tail->next)
+ tail = tail->next;
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
+ } else {
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
+ }
+
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
+ return cb;
+}
+
+int
+rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb **prev_cb, *curr_cb;
+ struct rte_cryptodev_cb_rcu *list;
+ int ret;
+
+ ret = -EINVAL;
+
+ if (!cb) {
+ CDEV_LOG_ERR("Callback is NULL");
+ return -EINVAL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ return -ENODEV;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ if (dev->enq_cbs == NULL) {
+ CDEV_LOG_ERR("Callback not initialized");
+ goto cb_err;
+ }
+
+ list = &dev->enq_cbs[qp_id];
+ if (list == NULL) {
+ CDEV_LOG_ERR("Callback list is NULL");
+ goto cb_err;
+ }
+
+ if (list->qsbr == NULL) {
+ CDEV_LOG_ERR("Rcu qsbr is NULL");
+ goto cb_err;
+ }
+
+ prev_cb = &list->next;
+ for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
+ curr_cb = *prev_cb;
+ if (curr_cb == cb) {
+ /* Remove the user cb from the callback list. */
+ __atomic_store_n(prev_cb, curr_cb->next,
+ __ATOMIC_RELAXED);
+ ret = 0;
+ break;
+ }
+ }
+
+ if (!ret) {
+ /* Call sync with invalid thread id as this is part of
+ * control plane API
+ */
+ rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
+ rte_free(cb);
+ }
+
+cb_err:
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+ return ret;
+}
+
+struct rte_cryptodev_cb *
+rte_cryptodev_add_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb, *tail;
+
+ if (!cb_fn) {
+ CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ rte_errno = ENODEV;
+ return NULL;
+ }
+
+ cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+ if (cb == NULL) {
+ CDEV_LOG_ERR("Failed to allocate memory for callback on "
+ "dev=%d, queue_pair_id=%d", dev_id, qp_id);
+ rte_errno = ENOMEM;
+ return NULL;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+
+ cb->fn = cb_fn;
+ cb->arg = cb_arg;
+
+ /* Add the callbacks in fifo order. */
+ list = &dev->deq_cbs[qp_id];
+ tail = list->next;
+
+ if (tail) {
+ while (tail->next)
+ tail = tail->next;
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
+ } else {
+ /* Stores to cb->fn and cb->param should complete before
+ * cb is visible to data plane.
+ */
+ __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
+ }
+
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
+ return cb;
+}
+
+int
+rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb)
+{
+ struct rte_cryptodev *dev;
+ struct rte_cryptodev_cb **prev_cb, *curr_cb;
+ struct rte_cryptodev_cb_rcu *list;
+ int ret;
+
+ ret = -EINVAL;
+
+ if (!cb) {
+ CDEV_LOG_ERR("Callback is NULL");
+ return -EINVAL;
+ }
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+ if (qp_id >= dev->data->nb_queue_pairs) {
+ CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+ return -ENODEV;
+ }
+
+ rte_spinlock_lock(&rte_cryptodev_callback_lock);
+ if (dev->enq_cbs == NULL) {
+ CDEV_LOG_ERR("Callback not initialized");
+ goto cb_err;
+ }
+
+ list = &dev->deq_cbs[qp_id];
+ if (list == NULL) {
+ CDEV_LOG_ERR("Callback list is NULL");
+ goto cb_err;
+ }
+
+ if (list->qsbr == NULL) {
+ CDEV_LOG_ERR("Rcu qsbr is NULL");
+ goto cb_err;
+ }
+
+ prev_cb = &list->next;
+ for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
+ curr_cb = *prev_cb;
+ if (curr_cb == cb) {
+ /* Remove the user cb from the callback list. */
+ __atomic_store_n(prev_cb, curr_cb->next,
+ __ATOMIC_RELAXED);
+ ret = 0;
+ break;
+ }
+ }
+
+ if (!ret) {
+ /* Call sync with invalid thread id as this is part of
+ * control plane API
+ */
+ rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
+ rte_free(cb);
+ }
+
+cb_err:
+ rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+ return ret;
+}
+#endif
int
rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 0935fd5..e6ab755 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -23,6 +23,7 @@
#include "rte_dev.h"
#include <rte_common.h>
#include <rte_config.h>
+#include <rte_rcu_qsbr.h>
#include "rte_cryptodev_trace_fp.h"
@@ -522,6 +523,32 @@ struct rte_cryptodev_qp_conf {
/**< The mempool for creating sess private data in sessionless mode */
};
+#ifdef RTE_CRYPTO_CALLBACKS
+/**
+ * Function type used for processing crypto ops when enqueue/dequeue burst is
+ * called.
+ *
+ * The callback function is called on enqueue/dequeue burst immediately.
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * enqueued/dequeued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param ops The address of an array of *nb_ops* pointers
+ * to *rte_crypto_op* structures which contain
+ * the crypto operations to be processed.
+ * @param nb_ops The number of operations to process.
+ * @param user_param The arbitrary user parameter passed in by the
+ * application when the callback was originally
+ * registered.
+ * @return The number of ops to be enqueued to the
+ * crypto device.
+ */
+typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
+ struct rte_crypto_op **ops, uint16_t nb_ops, void *user_param);
+#endif
+
/**
* Typedef for application callback function to be registered by application
* software for notification of device events
@@ -822,7 +849,6 @@ struct rte_cryptodev_config {
enum rte_cryptodev_event_type event,
rte_cryptodev_cb_fn cb_fn, void *cb_arg);
-
typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
struct rte_crypto_op **ops, uint16_t nb_ops);
/**< Dequeue processed packets from queue pair of a device. */
@@ -839,6 +865,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
/** Structure to keep track of registered callbacks */
TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
+#ifdef RTE_CRYPTO_CALLBACKS
+/**
+ * @internal
+ * Structure used to hold information about the callbacks to be called for a
+ * queue pair on enqueue/dequeue.
+ */
+struct rte_cryptodev_cb {
+ struct rte_cryptodev_cb *next;
+ /** < Pointer to next callback */
+ rte_cryptodev_callback_fn fn;
+ /** < Pointer to callback function */
+ void *arg;
+ /** < Pointer to argument */
+};
+
+/**
+ * @internal
+ * Structure used to hold information about the RCU for a queue pair.
+ */
+struct rte_cryptodev_cb_rcu {
+ struct rte_cryptodev_cb *next;
+ /** < Pointer to next callback */
+ struct rte_rcu_qsbr *qsbr;
+ /** < RCU QSBR variable per queue pair */
+};
+#endif
+
/** The data structure associated with each crypto device. */
struct rte_cryptodev {
dequeue_pkt_burst_t dequeue_burst;
@@ -867,6 +920,12 @@ struct rte_cryptodev {
__extension__
uint8_t attached : 1;
/**< Flag indicating the device is attached */
+
+ struct rte_cryptodev_cb_rcu *enq_cbs;
+ /**< User application callback for pre enqueue processing */
+
+ struct rte_cryptodev_cb_rcu *deq_cbs;
+ /**< User application callback for post dequeue processing */
} __rte_cache_aligned;
void *
@@ -945,6 +1004,30 @@ struct rte_cryptodev_data {
{
struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
+#ifdef RTE_CRYPTO_CALLBACKS
+ if (unlikely(dev->deq_cbs != NULL)) {
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb;
+
+ /* __ATOMIC_RELEASE memory order was used when the
+ * call back was inserted into the list.
+ * Since there is a clear dependency between loading
+ * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+ * not required.
+ */
+ list = &dev->deq_cbs[qp_id];
+ rte_rcu_qsbr_thread_online(list->qsbr, 0);
+ cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
+
+ while (cb != NULL) {
+ nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
+ cb->arg);
+ cb = cb->next;
+ };
+
+ rte_rcu_qsbr_thread_offline(list->qsbr, 0);
+ }
+#endif
nb_ops = (*dev->dequeue_burst)
(dev->data->queue_pairs[qp_id], ops, nb_ops);
@@ -989,6 +1072,31 @@ struct rte_cryptodev_data {
{
struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
+#ifdef RTE_CRYPTO_CALLBACKS
+ if (unlikely(dev->enq_cbs != NULL)) {
+ struct rte_cryptodev_cb_rcu *list;
+ struct rte_cryptodev_cb *cb;
+
+ /* __ATOMIC_RELEASE memory order was used when the
+ * call back was inserted into the list.
+ * Since there is a clear dependency between loading
+ * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+ * not required.
+ */
+ list = &dev->enq_cbs[qp_id];
+ rte_rcu_qsbr_thread_online(list->qsbr, 0);
+ cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
+
+ while (cb != NULL) {
+ nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
+ cb->arg);
+ cb = cb->next;
+ };
+
+ rte_rcu_qsbr_thread_offline(list->qsbr, 0);
+ }
+#endif
+
rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, nb_ops);
return (*dev->enqueue_burst)(
dev->data->queue_pairs[qp_id], ops, nb_ops);
@@ -1730,6 +1838,156 @@ struct rte_crypto_raw_dp_ctx {
rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
uint32_t n);
+#ifdef RTE_CRYPTO_CALLBACKS
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Add a user callback for a given crypto device and queue pair which will be
+ * called on crypto ops enqueue.
+ *
+ * This API configures a function to be called for each burst of crypto ops
+ * received on a given crypto device queue pair. The return value is a pointer
+ * that can be used later to remove the callback using
+ * rte_cryptodev_remove_enq_callback().
+ *
+ * Callbacks registered by application would not survive
+ * rte_cryptodev_configure() as it reinitializes the callback list.
+ * It is user responsibility to remove all installed callbacks before
+ * calling rte_cryptodev_configure() to avoid possible memory leakage.
+ * Application is expected to call add API after rte_cryptodev_configure().
+ *
+ * Multiple functions can be registered per queue pair & they are called
+ * in the order they were added. The API does not restrict on maximum number
+ * of callbacks.
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be enqueued for processing. The value
+ * must be in the range [0, nb_queue_pairs - 1]
+ * previously supplied to
+ * *rte_cryptodev_configure*.
+ * @param cb_fn The callback function
+ * @param cb_arg A generic pointer parameter which will be passed
+ * to each invocation of the callback function on
+ * this crypto device and queue pair.
+ *
+ * @return
+ * NULL on error & rte_errno will contain the error code.
+ * On success, a pointer value which can later be used to remove the callback.
+ */
+
+__rte_experimental
+struct rte_cryptodev_cb *
+rte_cryptodev_add_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Remove a user callback function for given crypto device and queue pair.
+ *
+ * This function is used to remove enqueue callbacks that were added to a
+ * crypto device queue pair using rte_cryptodev_add_enq_callback().
+ *
+ *
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be enqueued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param cb Pointer to user supplied callback created via
+ * rte_cryptodev_add_enq_callback().
+ *
+ * @return
+ * - 0: Success. Callback was removed.
+ * - <0: The dev_id or the qp_id is out of range, or the callback
+ * is NULL or not found for the crypto device queue pair.
+ */
+
+__rte_experimental
+int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Add a user callback for a given crypto device and queue pair which will be
+ * called on crypto ops dequeue.
+ *
+ * This API configures a function to be called for each burst of crypto ops
+ * received on a given crypto device queue pair. The return value is a pointer
+ * that can be used later to remove the callback using
+ * rte_cryptodev_remove_deq_callback().
+ *
+ * Callbacks registered by application would not survive
+ * rte_cryptodev_configure() as it reinitializes the callback list.
+ * It is user responsibility to remove all installed callbacks before
+ * calling rte_cryptodev_configure() to avoid possible memory leakage.
+ * Application is expected to call add API after rte_cryptodev_configure().
+ *
+ * Multiple functions can be registered per queue pair & they are called
+ * in the order they were added. The API does not restrict on maximum number
+ * of callbacks.
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be dequeued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param cb_fn The callback function
+ * @param cb_arg A generic pointer parameter which will be passed
+ * to each invocation of the callback function on
+ * this crypto device and queue pair.
+ *
+ * @return
+ * NULL on error & rte_errno will contain the error code.
+ * On success, a pointer value which can later be used to remove the callback.
+ */
+
+__rte_experimental
+struct rte_cryptodev_cb *
+rte_cryptodev_add_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ rte_cryptodev_callback_fn cb_fn,
+ void *cb_arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Remove a user callback function for given crypto device and queue pair.
+ *
+ * This function is used to remove dequeue callbacks that were added to a
+ * crypto device queue pair using rte_cryptodev_add_deq_callback().
+ *
+ *
+ *
+ * @param dev_id The identifier of the device.
+ * @param qp_id The index of the queue pair on which ops are
+ * to be dequeued. The value must be in the
+ * range [0, nb_queue_pairs - 1] previously
+ * supplied to *rte_cryptodev_configure*.
+ * @param cb Pointer to user supplied callback created via
+ * rte_cryptodev_add_deq_callback().
+ *
+ * @return
+ * - 0: Success. Callback was removed.
+ * - <0: The dev_id or the qp_id is out of range, or the callback
+ * is NULL or not found for the crypto device queue pair.
+ */
+__rte_experimental
+int rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+ uint16_t qp_id,
+ struct rte_cryptodev_cb *cb);
+#endif
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_cryptodev/version.map b/lib/librte_cryptodev/version.map
index 7e4360f..429b03e 100644
--- a/lib/librte_cryptodev/version.map
+++ b/lib/librte_cryptodev/version.map
@@ -101,6 +101,8 @@ EXPERIMENTAL {
rte_cryptodev_get_qp_status;
# added in 20.11
+ rte_cryptodev_add_deq_callback;
+ rte_cryptodev_add_enq_callback;
rte_cryptodev_configure_raw_dp_ctx;
rte_cryptodev_get_raw_dp_ctx_size;
rte_cryptodev_raw_dequeue;
@@ -109,4 +111,6 @@ EXPERIMENTAL {
rte_cryptodev_raw_enqueue;
rte_cryptodev_raw_enqueue_burst;
rte_cryptodev_raw_enqueue_done;
+ rte_cryptodev_remove_deq_callback;
+ rte_cryptodev_remove_enq_callback;
};
--
1.9.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-29 14:00 0% ` Akhil Goyal
@ 2020-10-30 4:24 0% ` Gujjar, Abhinandan S
2020-10-30 17:18 0% ` Gujjar, Abhinandan S
0 siblings, 1 reply; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-30 4:24 UTC (permalink / raw)
To: Akhil Goyal, Honnappa Nagarahalli, Richardson, Bruce,
Ray Kinsella, Thomas Monjalon
Cc: Ananyev, Konstantin, dev, Doherty, Declan, techboard, Vangati,
Narender, jerinj, nd
Thanks Tech board & Akhil for clarifying the concern.
Sure. I will send the new version of the patch.
Regards
Abhinandan
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Thursday, October 29, 2020 7:31 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Ray Kinsella <mdr@ashroe.eu>; Thomas
> Monjalon <thomas@monjalon.net>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>; techboard@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; jerinj@marvell.com; nd
> <nd@arm.com>
> Subject: RE: [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback
> functions
>
> >
> > Hi Akhil,
> >
> > Any updates on this?
> >
> There has been no objections for this patch from techboard.
>
> @Thomas Monjalon: could you please review the release notes.
> I believe there should be a bullet for API changes to add 2 new fields in
> rte_cryptodev.
> What do you suggest?
>
> @Gujjar, Abhinandan S
> Please send a new version for comments on errno.
> If possible add cases for deq_cbs as well. If not, send it by next week.
>
> Regards,
> Akhil
> > > + Ray for ABI
> > >
> > > <snip>
> > >
> > > >
> > > > On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
> > > > >
> > > > > Hi Konstantin,
> > > > >
> > > > > > > > Hi Tech board members,
> > > > > > > >
> > > > > > > > I have a doubt about the ABI breakage in below addition of field.
> > > > > > > > Could you please comment.
> > > > > > > >
> > > > > > > > > /** The data structure associated with each crypto device.
> > > > > > > > > */ struct rte_cryptodev {
> > > > > > > > > dequeue_pkt_burst_t dequeue_burst; @@ -867,6 +922,10
> > > > @@
> > > > > > > > > struct rte_cryptodev {
> > > > > > > > > __extension__
> > > > > > > > > uint8_t attached : 1;
> > > > > > > > > /**< Flag indicating the device is attached */
> > > > > > > > > +
> > > > > > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > > > > > + /**< User application callback for pre enqueue
> > > > > > > > > +processing */
> > > > > > > > > +
> > > > > > > > > } __rte_cache_aligned;
> > > > > > > >
> > > > > > > > Here rte_cryptodevs is defined in stable API list in map
> > > > > > > > file which is a pointer To all rte_cryptodev and the above
> > > > > > > > change is changing the size of the
> > > > > > structure.
> > > > > >
> > > > > > While this patch adds new fields into rte_cryptodev structure,
> > > > > > it doesn't change the size of it.
> > > > > > struct rte_cryptodev is cache line aligned, so it's current size:
> > > > > > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > > > > > So for 64-bit we have 47B implicitly reserved, and for 32-bit
> > > > > > we have 19B reserved.
> > > > > > That's enough to add two pointers without changing size of this struct.
> > > > > >
> > > > >
> > > > > The structure is cache aligned, and if the cache line size in
> > > > > 32Byte and the compilation is done on 64bit machine, then we
> > > > > will be left with 15Bytes which is not sufficient for 2 pointers.
> > > > > Do we have such systems? Am I missing something?
> > > > >
> > > >
> > > > I don't think we support any such systems, so unless someone can
> > > > point out a specific case where we need to support 32-byte CLs,
> > > > I'd tend towards ignoring this as a non-issue.
> > > Agree. I have not come across 32B cache line.
> > >
> > > >
> > > > > The reason I brought this into techboard is to have a consensus
> > > > > on such change As rte_cryptodev is a very popular and stable structure.
> > > > > Any changes to it may Have impacts which one person cannot judge
> > > > > all use
> > > > cases.
> > > > >
> > > >
> > > > Haven't been tracking this discussion much, but from what I read
> > > > here, this doesn't look like an ABI break and should be ok.
> > > If we are filling the holes in the cache line with new fields, it
> > > should not be an ABI break.
> > >
> > > >
> > > > Regards,
> > > > /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 03/23] event/dlb2: add private data structures and constants
2020-10-29 15:29 3% ` Stephen Hemminger
@ 2020-10-29 16:07 0% ` McDaniel, Timothy
0 siblings, 0 replies; 200+ results
From: McDaniel, Timothy @ 2020-10-29 16:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, Carrillo, Erik G, Eads, Gage, Van Haaren, Harry, jerinj, thomas
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, October 29, 2020 10:29 AM
> To: McDaniel, Timothy <timothy.mcdaniel@intel.com>
> Cc: dev@dpdk.org; Carrillo, Erik G <Erik.G.Carrillo@intel.com>; Eads, Gage
> <gage.eads@intel.com>; Van Haaren, Harry <harry.van.haaren@intel.com>;
> jerinj@marvell.com; thomas@monjalon.net
> Subject: Re: [dpdk-dev] [PATCH v4 03/23] event/dlb2: add private data
> structures and constants
>
> On Thu, 29 Oct 2020 10:24:57 -0500
> Timothy McDaniel <timothy.mcdaniel@intel.com> wrote:
>
> > +
> > + /* marker for array sizing etc. */
> > + _DLB2_NB_ENQ_TYPES
>
> Be careful with this type of array sizing value.
> It becomes a breaking point for any API/ABI changes.
Thanks for the comment Stephen. We do not expect these enums to change in the future.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 03/23] event/dlb2: add private data structures and constants
@ 2020-10-29 15:29 3% ` Stephen Hemminger
2020-10-29 16:07 0% ` McDaniel, Timothy
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2020-10-29 15:29 UTC (permalink / raw)
To: Timothy McDaniel
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
On Thu, 29 Oct 2020 10:24:57 -0500
Timothy McDaniel <timothy.mcdaniel@intel.com> wrote:
> +
> + /* marker for array sizing etc. */
> + _DLB2_NB_ENQ_TYPES
Be careful with this type of array sizing value.
It becomes a breaking point for any API/ABI changes.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 00/23] Add DLB PMD
@ 2020-10-29 14:57 3% ` Timothy McDaniel
2020-10-30 9:40 3% ` [dpdk-dev] [PATCH v8 " Timothy McDaniel
` (8 subsequent siblings)
9 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-29 14:57 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj, thomas
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in v7 after dpdk reviews
=====================
- updated MAINTAINERS file to alphabetically insert DLB
- don't create RTE_ symbols in PMD
- converted to use version.map scheme
- converted to use .._master_lcore instead of .._main_lcore
- this patch set is based on dpdk-next-eventdev
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-82202 ("eventdev: increase MAX QUEUES PER DEV to 255")
Depends-on: patch-79539 ("eal: add new x86 cpuid support for WAITPKG")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 6 +-
app/test/test_eventdev.c | 7 +
config/rte_config.h | 6 +
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4129 +++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1551 ++++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 +++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 +++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 ++++++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 ++++
drivers/event/dlb/pf/dlb_main.c | 586 +++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21764 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotter first half
@ 2020-10-29 14:42 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-29 14:42 UTC (permalink / raw)
To: Thomas Monjalon, dev
Cc: ferruh.yigit, david.marchand, bruce.richardson, olivier.matz,
andrew.rybchenko, jerinj, viacheslavo, Neil Horman
On 29/10/2020 09:27, Thomas Monjalon wrote:
> The mempool pointer in the mbuf struct is moved
> from the second to the first half.
> It should increase performance on most systems having 64-byte cache line,
> i.e. mbuf is split in two cache lines.
> On such system, the first half (also called first cache line) is hotter
> than the second one where the pool pointer was.
>
> Moving this field gives more space to dynfield1.
>
> This is how the mbuf layout looks like (pahole-style):
>
> word type name byte size
> 0 void * buf_addr; /* 0 + 8 */
> 1 rte_iova_t buf_iova /* 8 + 8 */
> /* --- RTE_MARKER64 rearm_data; */
> 2 uint16_t data_off; /* 16 + 2 */
> uint16_t refcnt; /* 18 + 2 */
> uint16_t nb_segs; /* 20 + 2 */
> uint16_t port; /* 22 + 2 */
> 3 uint64_t ol_flags; /* 24 + 8 */
> /* --- RTE_MARKER rx_descriptor_fields1; */
> 4 uint32_t union packet_type; /* 32 + 4 */
> uint32_t pkt_len; /* 36 + 4 */
> 5 uint16_t data_len; /* 40 + 2 */
> uint16_t vlan_tci; /* 42 + 2 */
> 5.5 uint64_t union hash; /* 44 + 8 */
> 6.5 uint16_t vlan_tci_outer; /* 52 + 2 */
> uint16_t buf_len; /* 54 + 2 */
> 7 struct rte_mempool * pool; /* 56 + 8 */
> /* --- RTE_MARKER cacheline1; */
> 8 struct rte_mbuf * next; /* 64 + 8 */
> 9 uint64_t union tx_offload; /* 72 + 8 */
> 10 uint16_t priv_size; /* 80 + 2 */
> uint16_t timesync; /* 82 + 2 */
> uint32_t seqn; /* 84 + 4 */
> 11 struct rte_mbuf_ext_shared_info * shinfo; /* 88 + 8 */
> 12 uint64_t dynfield1[4]; /* 96 + 32 */
> 16 /* --- END 128 */
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 -----
> lib/librte_kni/rte_kni_common.h | 3 ++-
> lib/librte_mbuf/rte_mbuf_core.h | 5 ++---
> 3 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 72dbb25b83..07ca1dcbb2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -88,11 +88,6 @@ Deprecation Notices
>
> - ``seqn``
>
> - As a consequence, the layout of the ``struct rte_mbuf`` will be re-arranged,
> - avoiding impact on vectorized implementation of the driver datapaths,
> - while evaluating performance gains of a better use of the first cache line.
> -
> -
> * ethdev: the legacy filter API, including
> ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
> as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
> diff --git a/lib/librte_kni/rte_kni_common.h b/lib/librte_kni/rte_kni_common.h
> index 36d66e2ffa..ffb3182731 100644
> --- a/lib/librte_kni/rte_kni_common.h
> +++ b/lib/librte_kni/rte_kni_common.h
> @@ -84,10 +84,11 @@ struct rte_kni_mbuf {
> char pad2[4];
> uint32_t pkt_len; /**< Total pkt len: sum of all segment data_len. */
> uint16_t data_len; /**< Amount of data in segment buffer. */
> + char pad3[14];
> + void *pool;
>
> /* fields on second cache line */
> __attribute__((__aligned__(RTE_CACHE_LINE_MIN_SIZE)))
> - void *pool;
> void *next; /**< Physical address of next mbuf in kernel. */
> };
>
> diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h
> index 52ca1c842f..ee185fa32b 100644
> --- a/lib/librte_mbuf/rte_mbuf_core.h
> +++ b/lib/librte_mbuf/rte_mbuf_core.h
> @@ -584,12 +584,11 @@ struct rte_mbuf {
>
> uint16_t buf_len; /**< Length of segment buffer. */
>
> - uint64_t unused;
> + struct rte_mempool *pool; /**< Pool from which mbuf was allocated. */
>
> /* second cache line - fields only used in slow path or on TX */
> RTE_MARKER cacheline1 __rte_cache_min_aligned;
>
> - struct rte_mempool *pool; /**< Pool from which mbuf was allocated. */
> struct rte_mbuf *next; /**< Next segment of scattered packet. */
>
> /* fields to support TX offloads */
> @@ -646,7 +645,7 @@ struct rte_mbuf {
> */
> struct rte_mbuf_ext_shared_info *shinfo;
>
> - uint64_t dynfield1[3]; /**< Reserved for dynamic fields. */
> + uint64_t dynfield1[4]; /**< Reserved for dynamic fields. */
> } __rte_cache_aligned;
>
> /**
>
I will let other chime in on the merits of positioning cache alignment of the
mempool pointer.
From the ABI PoV, depreciate notice has been observed and since mbuf effects
everything doing it outside of a ABI Breakage window is impossible, so it now or
never.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 15:22 4% ` Honnappa Nagarahalli
2020-10-29 13:52 0% ` Gujjar, Abhinandan S
@ 2020-10-29 14:26 3% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-29 14:26 UTC (permalink / raw)
To: Honnappa Nagarahalli, Bruce Richardson, Akhil.goyal@nxp.com
Cc: Ananyev, Konstantin, Gujjar, Abhinandan S, dev, Doherty, Declan,
techboard, Vangati, Narender, jerinj, nd
On 28/10/2020 15:22, Honnappa Nagarahalli wrote:
> + Ray for ABI
>
> <snip>
>
>>
>> On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
>>>
>>> Hi Konstantin,
>>>
>>>>>> Hi Tech board members,
>>>>>>
>>>>>> I have a doubt about the ABI breakage in below addition of field.
>>>>>> Could you please comment.
>>>>>>
>>>>>>> /** The data structure associated with each crypto device. */
>>>>>>> struct rte_cryptodev {
>>>>>>> dequeue_pkt_burst_t dequeue_burst; @@ -867,6 +922,10
>> @@
>>>>>>> struct rte_cryptodev {
>>>>>>> __extension__
>>>>>>> uint8_t attached : 1;
>>>>>>> /**< Flag indicating the device is attached */
>>>>>>> +
>>>>>>> + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
>>>>>>> + /**< User application callback for pre enqueue processing */
>>>>>>> +
>>>>>>> } __rte_cache_aligned;
>>>>>>
>>>>>> Here rte_cryptodevs is defined in stable API list in map file
>>>>>> which is a pointer To all rte_cryptodev and the above change is
>>>>>> changing the size of the
>>>> structure.
>>>>
>>>> While this patch adds new fields into rte_cryptodev structure, it
>>>> doesn't change the size of it.
>>>> struct rte_cryptodev is cache line aligned, so it's current size:
>>>> 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
>>>> So for 64-bit we have 47B implicitly reserved, and for 32-bit we
>>>> have 19B reserved.
>>>> That's enough to add two pointers without changing size of this struct.
>>>>
>>>
>>> The structure is cache aligned, and if the cache line size in 32Byte
>>> and the compilation is done on 64bit machine, then we will be left
>>> with 15Bytes which is not sufficient for 2 pointers.
>>> Do we have such systems? Am I missing something?
>>>
>>
>> I don't think we support any such systems, so unless someone can point out
>> a specific case where we need to support 32-byte CLs, I'd tend towards
>> ignoring this as a non-issue.
> Agree. I have not come across 32B cache line.
>
>>
>>> The reason I brought this into techboard is to have a consensus on
>>> such change As rte_cryptodev is a very popular and stable structure.
>>> Any changes to it may Have impacts which one person cannot judge all use
>> cases.
>>>
>>
>> Haven't been tracking this discussion much, but from what I read here, this
>> doesn't look like an ABI break and should be ok.
> If we are filling the holes in the cache line with new fields, it should not be an ABI break.
Agreed, risk seems minimal ... it is an ABI Breakage window in anycase.
>>
>> Regards,
>> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-29 13:52 0% ` Gujjar, Abhinandan S
@ 2020-10-29 14:00 0% ` Akhil Goyal
2020-10-30 4:24 0% ` Gujjar, Abhinandan S
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2020-10-29 14:00 UTC (permalink / raw)
To: Gujjar, Abhinandan S, Honnappa Nagarahalli, Richardson, Bruce,
Ray Kinsella, Thomas Monjalon
Cc: Ananyev, Konstantin, dev, Doherty, Declan, techboard, Vangati,
Narender, jerinj, nd
>
> Hi Akhil,
>
> Any updates on this?
>
There has been no objections for this patch from techboard.
@Thomas Monjalon: could you please review the release notes.
I believe there should be a bullet for API changes to add 2 new fields in rte_cryptodev.
What do you suggest?
@Gujjar, Abhinandan S
Please send a new version for comments on errno.
If possible add cases for deq_cbs as well. If not, send it by next week.
Regards,
Akhil
> > + Ray for ABI
> >
> > <snip>
> >
> > >
> > > On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
> > > >
> > > > Hi Konstantin,
> > > >
> > > > > > > Hi Tech board members,
> > > > > > >
> > > > > > > I have a doubt about the ABI breakage in below addition of field.
> > > > > > > Could you please comment.
> > > > > > >
> > > > > > > > /** The data structure associated with each crypto device.
> > > > > > > > */ struct rte_cryptodev {
> > > > > > > > dequeue_pkt_burst_t dequeue_burst; @@ -867,6 +922,10
> > > @@
> > > > > > > > struct rte_cryptodev {
> > > > > > > > __extension__
> > > > > > > > uint8_t attached : 1;
> > > > > > > > /**< Flag indicating the device is attached */
> > > > > > > > +
> > > > > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > > > > + /**< User application callback for pre enqueue processing
> > > > > > > > +*/
> > > > > > > > +
> > > > > > > > } __rte_cache_aligned;
> > > > > > >
> > > > > > > Here rte_cryptodevs is defined in stable API list in map file
> > > > > > > which is a pointer To all rte_cryptodev and the above change
> > > > > > > is changing the size of the
> > > > > structure.
> > > > >
> > > > > While this patch adds new fields into rte_cryptodev structure, it
> > > > > doesn't change the size of it.
> > > > > struct rte_cryptodev is cache line aligned, so it's current size:
> > > > > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > > > > So for 64-bit we have 47B implicitly reserved, and for 32-bit we
> > > > > have 19B reserved.
> > > > > That's enough to add two pointers without changing size of this struct.
> > > > >
> > > >
> > > > The structure is cache aligned, and if the cache line size in 32Byte
> > > > and the compilation is done on 64bit machine, then we will be left
> > > > with 15Bytes which is not sufficient for 2 pointers.
> > > > Do we have such systems? Am I missing something?
> > > >
> > >
> > > I don't think we support any such systems, so unless someone can point
> > > out a specific case where we need to support 32-byte CLs, I'd tend
> > > towards ignoring this as a non-issue.
> > Agree. I have not come across 32B cache line.
> >
> > >
> > > > The reason I brought this into techboard is to have a consensus on
> > > > such change As rte_cryptodev is a very popular and stable structure.
> > > > Any changes to it may Have impacts which one person cannot judge all
> > > > use
> > > cases.
> > > >
> > >
> > > Haven't been tracking this discussion much, but from what I read here,
> > > this doesn't look like an ABI break and should be ok.
> > If we are filling the holes in the cache line with new fields, it should not be an
> > ABI break.
> >
> > >
> > > Regards,
> > > /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 15:22 4% ` Honnappa Nagarahalli
@ 2020-10-29 13:52 0% ` Gujjar, Abhinandan S
2020-10-29 14:00 0% ` Akhil Goyal
2020-10-29 14:26 3% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-29 13:52 UTC (permalink / raw)
To: Honnappa Nagarahalli, Richardson, Bruce, Akhil.goyal@nxp.com,
Ray Kinsella
Cc: Ananyev, Konstantin, dev, Doherty, Declan, techboard, Vangati,
Narender, jerinj, nd
Hi Akhil,
Any updates on this?
Thanks
Abhinandan
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Wednesday, October 28, 2020 8:52 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>; Akhil.goyal@nxp.com;
> Ray Kinsella <mdr@ashroe.eu>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Doherty, Declan
> <declan.doherty@intel.com>; techboard@dpdk.org; Vangati, Narender
> <narender.vangati@intel.com>; jerinj@marvell.com; nd <nd@arm.com>
> Subject: RE: [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback
> functions
>
> + Ray for ABI
>
> <snip>
>
> >
> > On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
> > >
> > > Hi Konstantin,
> > >
> > > > > > Hi Tech board members,
> > > > > >
> > > > > > I have a doubt about the ABI breakage in below addition of field.
> > > > > > Could you please comment.
> > > > > >
> > > > > > > /** The data structure associated with each crypto device.
> > > > > > > */ struct rte_cryptodev {
> > > > > > > dequeue_pkt_burst_t dequeue_burst; @@ -867,6 +922,10
> > @@
> > > > > > > struct rte_cryptodev {
> > > > > > > __extension__
> > > > > > > uint8_t attached : 1;
> > > > > > > /**< Flag indicating the device is attached */
> > > > > > > +
> > > > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > > > + /**< User application callback for pre enqueue processing
> > > > > > > +*/
> > > > > > > +
> > > > > > > } __rte_cache_aligned;
> > > > > >
> > > > > > Here rte_cryptodevs is defined in stable API list in map file
> > > > > > which is a pointer To all rte_cryptodev and the above change
> > > > > > is changing the size of the
> > > > structure.
> > > >
> > > > While this patch adds new fields into rte_cryptodev structure, it
> > > > doesn't change the size of it.
> > > > struct rte_cryptodev is cache line aligned, so it's current size:
> > > > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > > > So for 64-bit we have 47B implicitly reserved, and for 32-bit we
> > > > have 19B reserved.
> > > > That's enough to add two pointers without changing size of this struct.
> > > >
> > >
> > > The structure is cache aligned, and if the cache line size in 32Byte
> > > and the compilation is done on 64bit machine, then we will be left
> > > with 15Bytes which is not sufficient for 2 pointers.
> > > Do we have such systems? Am I missing something?
> > >
> >
> > I don't think we support any such systems, so unless someone can point
> > out a specific case where we need to support 32-byte CLs, I'd tend
> > towards ignoring this as a non-issue.
> Agree. I have not come across 32B cache line.
>
> >
> > > The reason I brought this into techboard is to have a consensus on
> > > such change As rte_cryptodev is a very popular and stable structure.
> > > Any changes to it may Have impacts which one person cannot judge all
> > > use
> > cases.
> > >
> >
> > Haven't been tracking this discussion much, but from what I read here,
> > this doesn't look like an ABI break and should be ok.
> If we are filling the holes in the cache line with new fields, it should not be an
> ABI break.
>
> >
> > Regards,
> > /Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK Release Status Meeting 29/10/2020
@ 2020-10-29 12:22 3% Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2020-10-29 12:22 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon
Meeting minutes of 29 October 2020
----------------------------------
Agenda:
* Release Dates
* -rc1 status
* Subtrees
Participants:
* Arm
* Debian/Microsoft
* Intel
* Marvell
* Nvidia
* NXP
* Red Hat
Release Dates
-------------
* v20.11 dates
* -rc2 pushed to *Tuesday, 3 November 2020*
* -rc3: Thursday, 12 November 2020
* Release: Wednesday, 25 November 2020
-rc1 status
-----------
* Intel test report shared, many issues reported but no critical/showstopper
issue:
https://mails.dpdk.org/archives/dev/2020-October/189618.html
* Red Hat sent a test report, all looks good
https://mails.dpdk.org/archives/dev/2020-October/189872.html
Subtrees
--------
* main
* Thomas was busy with mbuf patchset, please review
* https://patches.dpdk.org/project/dpdk/list/?series=13454
* https://patches.dpdk.org/project/dpdk/list/?series=13416
* Power patchset eal part can be merged to enable DLB eventdev drivers
* The ethdev patch requires new version with more documentation
* Ferruh & Jerin will try to review the ethdev patch
* fibs patchset merged
* Working on
* Ring series from Honnappa
* replace blacklist/whitelist with allow/block from Stephen
* There is a makefile for the kmods repo, please review
* https://patches.dpdk.org/patch/79999/
* There is a GSO API behavior change without deprecation notice
* https://patches.dpdk.org/patch/82163/
* Requires techboard approval
* There is a patch to add MMIO support to PIO map
* Can it be handled in virtio level? more review please
* https://patches.dpdk.org/project/dpdk/list/?series=13220
* next-net
* Andrew was covering next-net for past a few days
* Will get ethdev patch to remove legacy filter support
* https://patches.dpdk.org/project/dpdk/list/?series=13207&state=*
* There is a dependency to tep-term example removal
* https://patches.dpdk.org/patch/82169/
* https://patches.dpdk.org/project/dpdk/list/?series=13211&state=*
* Will pull from all sub-trees
* next-crypto
* Merged most of the patches, 7-8 left
* enqueue & dequeue callback functions series from Intel remaining
* Was suspicions that it can be ABI break
* Will ask for new version
* Planning to merge if there is not objection
* next-eventdev
* Waiting new version for DLB PMDs
* eal libraries may be merged very soon, if so new version can be done
as rebased on top of it
* Need the new version soon (today/tomorrow), to be able to review and
merge it for the -rc2
* next-virtio
* Pull request sent for -rc2
* No more patch expected for -rc2
* next-net-intel
* Some patches already merged and waiting for pull
* next-net-mlx
* There can be more features for -rc2
* Some patches already merged and waiting for pull
* next-net-mrvl
* There will be two more patches for -rc2, they will be processed soon
* next-net-brcm
* Some patches already merged and waiting for pull
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursdays at 8:30 UTC. on https://meet.jit.si/DPDK
If you wish to attend just send an email to
"John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 15:11 3% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2020-10-28 15:22 4% ` Honnappa Nagarahalli
2020-10-29 13:52 0% ` Gujjar, Abhinandan S
2020-10-29 14:26 3% ` Kinsella, Ray
0 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2020-10-28 15:22 UTC (permalink / raw)
To: Bruce Richardson, Akhil.goyal@nxp.com, Ray Kinsella
Cc: Ananyev, Konstantin, Gujjar, Abhinandan S, dev, Doherty, Declan,
techboard, Vangati, Narender, jerinj, nd
+ Ray for ABI
<snip>
>
> On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
> >
> > Hi Konstantin,
> >
> > > > > Hi Tech board members,
> > > > >
> > > > > I have a doubt about the ABI breakage in below addition of field.
> > > > > Could you please comment.
> > > > >
> > > > > > /** The data structure associated with each crypto device. */
> > > > > > struct rte_cryptodev {
> > > > > > dequeue_pkt_burst_t dequeue_burst; @@ -867,6 +922,10
> @@
> > > > > > struct rte_cryptodev {
> > > > > > __extension__
> > > > > > uint8_t attached : 1;
> > > > > > /**< Flag indicating the device is attached */
> > > > > > +
> > > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > > + /**< User application callback for pre enqueue processing */
> > > > > > +
> > > > > > } __rte_cache_aligned;
> > > > >
> > > > > Here rte_cryptodevs is defined in stable API list in map file
> > > > > which is a pointer To all rte_cryptodev and the above change is
> > > > > changing the size of the
> > > structure.
> > >
> > > While this patch adds new fields into rte_cryptodev structure, it
> > > doesn't change the size of it.
> > > struct rte_cryptodev is cache line aligned, so it's current size:
> > > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > > So for 64-bit we have 47B implicitly reserved, and for 32-bit we
> > > have 19B reserved.
> > > That's enough to add two pointers without changing size of this struct.
> > >
> >
> > The structure is cache aligned, and if the cache line size in 32Byte
> > and the compilation is done on 64bit machine, then we will be left
> > with 15Bytes which is not sufficient for 2 pointers.
> > Do we have such systems? Am I missing something?
> >
>
> I don't think we support any such systems, so unless someone can point out
> a specific case where we need to support 32-byte CLs, I'd tend towards
> ignoring this as a non-issue.
Agree. I have not come across 32B cache line.
>
> > The reason I brought this into techboard is to have a consensus on
> > such change As rte_cryptodev is a very popular and stable structure.
> > Any changes to it may Have impacts which one person cannot judge all use
> cases.
> >
>
> Haven't been tracking this discussion much, but from what I read here, this
> doesn't look like an ABI break and should be ok.
If we are filling the holes in the cache line with new fields, it should not be an ABI break.
>
> Regards,
> /Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 14:28 0% ` Akhil Goyal
2020-10-28 14:52 0% ` Ananyev, Konstantin
@ 2020-10-28 15:11 3% ` Bruce Richardson
2020-10-28 15:22 4% ` Honnappa Nagarahalli
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2020-10-28 15:11 UTC (permalink / raw)
To: Akhil Goyal
Cc: Ananyev, Konstantin, Gujjar, Abhinandan S, dev, Doherty, Declan,
Honnappa.Nagarahalli, techboard, Vangati, Narender, jerinj
On Wed, Oct 28, 2020 at 02:28:43PM +0000, Akhil Goyal wrote:
>
> Hi Konstantin,
>
> > > > Hi Tech board members,
> > > >
> > > > I have a doubt about the ABI breakage in below addition of field.
> > > > Could you please comment.
> > > >
> > > > > /** The data structure associated with each crypto device. */ struct
> > > > > rte_cryptodev {
> > > > > dequeue_pkt_burst_t dequeue_burst;
> > > > > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > > > > __extension__
> > > > > uint8_t attached : 1;
> > > > > /**< Flag indicating the device is attached */
> > > > > +
> > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > + /**< User application callback for pre enqueue processing */
> > > > > +
> > > > > } __rte_cache_aligned;
> > > >
> > > > Here rte_cryptodevs is defined in stable API list in map file which is a pointer
> > > > To all rte_cryptodev and the above change is changing the size of the
> > structure.
> >
> > While this patch adds new fields into rte_cryptodev structure,
> > it doesn't change the size of it.
> > struct rte_cryptodev is cache line aligned, so it's current size:
> > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > So for 64-bit we have 47B implicitly reserved, and for 32-bit we have 19B
> > reserved.
> > That's enough to add two pointers without changing size of this struct.
> >
>
> The structure is cache aligned, and if the cache line size in 32Byte and the compilation
> is done on 64bit machine, then we will be left with 15Bytes which is not sufficient for 2
> pointers.
> Do we have such systems? Am I missing something?
>
I don't think we support any such systems, so unless someone can point out
a specific case where we need to support 32-byte CLs, I'd tend towards
ignoring this as a non-issue.
> The reason I brought this into techboard is to have a consensus on such change
> As rte_cryptodev is a very popular and stable structure. Any changes to it may
> Have impacts which one person cannot judge all use cases.
>
Haven't been tracking this discussion much, but from what I read here, this
doesn't look like an ABI break and should be ok.
Regards,
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 14:28 0% ` Akhil Goyal
@ 2020-10-28 14:52 0% ` Ananyev, Konstantin
2020-10-28 15:11 3% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2020-10-28 14:52 UTC (permalink / raw)
To: Akhil Goyal, Gujjar, Abhinandan S, dev, Doherty, Declan,
Honnappa.Nagarahalli, techboard
Cc: Vangati, Narender, jerinj
Hi Akhil,
> Hi Konstantin,
>
> > > > Hi Tech board members,
> > > >
> > > > I have a doubt about the ABI breakage in below addition of field.
> > > > Could you please comment.
> > > >
> > > > > /** The data structure associated with each crypto device. */ struct
> > > > > rte_cryptodev {
> > > > > dequeue_pkt_burst_t dequeue_burst;
> > > > > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > > > > __extension__
> > > > > uint8_t attached : 1;
> > > > > /**< Flag indicating the device is attached */
> > > > > +
> > > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > > + /**< User application callback for pre enqueue processing */
> > > > > +
> > > > > } __rte_cache_aligned;
> > > >
> > > > Here rte_cryptodevs is defined in stable API list in map file which is a pointer
> > > > To all rte_cryptodev and the above change is changing the size of the
> > structure.
> >
> > While this patch adds new fields into rte_cryptodev structure,
> > it doesn't change the size of it.
> > struct rte_cryptodev is cache line aligned, so it's current size:
> > 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> > So for 64-bit we have 47B implicitly reserved, and for 32-bit we have 19B
> > reserved.
> > That's enough to add two pointers without changing size of this struct.
> >
>
> The structure is cache aligned, and if the cache line size in 32Byte and the compilation
> is done on 64bit machine, then we will be left with 15Bytes which is not sufficient for 2
> pointers.
> Do we have such systems?
AFAIK - no, minimal supported cache-line size: 64B:
lib/librte_eal/include/rte_common.h:#define RTE_CACHE_LINE_MIN_SIZE 64
> Am I missing something?
> The reason I brought this into techboard is to have a consensus on such change
> As rte_cryptodev is a very popular and stable structure. Any changes to it may
> Have impacts which one person cannot judge all use cases.
+1 here.
I also think it would be good to get other TB members opinion about proposed changes.
> > > > IMO, it seems an ABI breakage, but not sure. So wanted to double check.
> > > > Now if it is an ABI breakage, then can we allow it? There was no deprecation
> > > > notice Prior to this release.
> >
> > Yes, there was no deprecation note in advance.
> > Though I think the risk is minimal - size of the struct will remain unchanged (see
> > above).
> > My vote to let it in for 20.11.
> >
> > > > Also I think if we are allowing the above change, then we should also add
> > > > another Field for deq_cbs also for post crypto processing in this patch only.
> >
> > +1 for this.
> > I think it was already addressed in v5.
> >
> > Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 12:55 0% ` Ananyev, Konstantin
@ 2020-10-28 14:28 0% ` Akhil Goyal
2020-10-28 14:52 0% ` Ananyev, Konstantin
2020-10-28 15:11 3% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2020-10-28 14:28 UTC (permalink / raw)
To: Ananyev, Konstantin, Gujjar, Abhinandan S, dev, Doherty, Declan,
Honnappa.Nagarahalli, techboard
Cc: Vangati, Narender, jerinj
Hi Konstantin,
> > > Hi Tech board members,
> > >
> > > I have a doubt about the ABI breakage in below addition of field.
> > > Could you please comment.
> > >
> > > > /** The data structure associated with each crypto device. */ struct
> > > > rte_cryptodev {
> > > > dequeue_pkt_burst_t dequeue_burst;
> > > > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > > > __extension__
> > > > uint8_t attached : 1;
> > > > /**< Flag indicating the device is attached */
> > > > +
> > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > + /**< User application callback for pre enqueue processing */
> > > > +
> > > > } __rte_cache_aligned;
> > >
> > > Here rte_cryptodevs is defined in stable API list in map file which is a pointer
> > > To all rte_cryptodev and the above change is changing the size of the
> structure.
>
> While this patch adds new fields into rte_cryptodev structure,
> it doesn't change the size of it.
> struct rte_cryptodev is cache line aligned, so it's current size:
> 128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
> So for 64-bit we have 47B implicitly reserved, and for 32-bit we have 19B
> reserved.
> That's enough to add two pointers without changing size of this struct.
>
The structure is cache aligned, and if the cache line size in 32Byte and the compilation
is done on 64bit machine, then we will be left with 15Bytes which is not sufficient for 2
pointers.
Do we have such systems? Am I missing something?
The reason I brought this into techboard is to have a consensus on such change
As rte_cryptodev is a very popular and stable structure. Any changes to it may
Have impacts which one person cannot judge all use cases.
> > > IMO, it seems an ABI breakage, but not sure. So wanted to double check.
> > > Now if it is an ABI breakage, then can we allow it? There was no deprecation
> > > notice Prior to this release.
>
> Yes, there was no deprecation note in advance.
> Though I think the risk is minimal - size of the struct will remain unchanged (see
> above).
> My vote to let it in for 20.11.
>
> > > Also I think if we are allowing the above change, then we should also add
> > > another Field for deq_cbs also for post crypto processing in this patch only.
>
> +1 for this.
> I think it was already addressed in v5.
>
> Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-28 8:20 0% ` Gujjar, Abhinandan S
@ 2020-10-28 12:55 0% ` Ananyev, Konstantin
2020-10-28 14:28 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2020-10-28 12:55 UTC (permalink / raw)
To: Gujjar, Abhinandan S, Akhil Goyal, dev, Doherty, Declan,
Honnappa.Nagarahalli, techboard
Cc: Vangati, Narender, jerinj
>
> Hi Tech board members,
>
> Could you please clarify the concern?
> The latest patch (https://patches.dpdk.org/patch/82536/) supports both enqueue and dequeue callback functionality.
>
> Thanks
> Abhinandan
>
> > -----Original Message-----
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > Sent: Tuesday, October 27, 2020 11:59 PM
> > To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Doherty, Declan <declan.doherty@intel.com>;
> > Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; techboard@dpdk.org
> > Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> > Subject: RE: [v4 1/3] cryptodev: support enqueue callback functions
> >
> > Hi Tech board members,
> >
> > I have a doubt about the ABI breakage in below addition of field.
> > Could you please comment.
> >
> > > /** The data structure associated with each crypto device. */ struct
> > > rte_cryptodev {
> > > dequeue_pkt_burst_t dequeue_burst;
> > > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > > __extension__
> > > uint8_t attached : 1;
> > > /**< Flag indicating the device is attached */
> > > +
> > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > + /**< User application callback for pre enqueue processing */
> > > +
> > > } __rte_cache_aligned;
> >
> > Here rte_cryptodevs is defined in stable API list in map file which is a pointer
> > To all rte_cryptodev and the above change is changing the size of the structure.
While this patch adds new fields into rte_cryptodev structure,
it doesn't change the size of it.
struct rte_cryptodev is cache line aligned, so it's current size:
128B for 64-bit systems, and 64B(/128B) for 32-bit systems.
So for 64-bit we have 47B implicitly reserved, and for 32-bit we have 19B reserved.
That's enough to add two pointers without changing size of this struct.
> > IMO, it seems an ABI breakage, but not sure. So wanted to double check.
> > Now if it is an ABI breakage, then can we allow it? There was no deprecation
> > notice Prior to this release.
Yes, there was no deprecation note in advance.
Though I think the risk is minimal - size of the struct will remain unchanged (see above).
My vote to let it in for 20.11.
> > Also I think if we are allowing the above change, then we should also add
> > another Field for deq_cbs also for post crypto processing in this patch only.
+1 for this.
I think it was already addressed in v5.
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-27 18:28 4% ` Akhil Goyal
@ 2020-10-28 8:20 0% ` Gujjar, Abhinandan S
2020-10-28 12:55 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-28 8:20 UTC (permalink / raw)
To: Akhil Goyal, dev, Doherty, Declan, Honnappa.Nagarahalli, Ananyev,
Konstantin, techboard
Cc: Vangati, Narender, jerinj
Hi Tech board members,
Could you please clarify the concern?
The latest patch (https://patches.dpdk.org/patch/82536/) supports both enqueue and dequeue callback functionality.
Thanks
Abhinandan
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, October 27, 2020 11:59 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; techboard@dpdk.org
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v4 1/3] cryptodev: support enqueue callback functions
>
> Hi Tech board members,
>
> I have a doubt about the ABI breakage in below addition of field.
> Could you please comment.
>
> > /** The data structure associated with each crypto device. */ struct
> > rte_cryptodev {
> > dequeue_pkt_burst_t dequeue_burst;
> > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > __extension__
> > uint8_t attached : 1;
> > /**< Flag indicating the device is attached */
> > +
> > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > + /**< User application callback for pre enqueue processing */
> > +
> > } __rte_cache_aligned;
>
> Here rte_cryptodevs is defined in stable API list in map file which is a pointer
> To all rte_cryptodev and the above change is changing the size of the structure.
> IMO, it seems an ABI breakage, but not sure. So wanted to double check.
> Now if it is an ABI breakage, then can we allow it? There was no deprecation
> notice Prior to this release.
>
> Also I think if we are allowing the above change, then we should also add
> another Field for deq_cbs also for post crypto processing in this patch only.
>
> Regards,
> Akhil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to
2020-10-26 6:47 3% [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to yang_y_yi
2020-10-27 19:55 0% ` Ananyev, Konstantin
@ 2020-10-28 0:51 0% ` Hu, Jiayu
1 sibling, 0 replies; 200+ results
From: Hu, Jiayu @ 2020-10-28 0:51 UTC (permalink / raw)
To: yang_y_yi, dev; +Cc: Ananyev, Konstantin, techboard, thomas, yangyi01
Acked-by: Jiayu Hu <jiayu.hu@intel.com>
> -----Original Message-----
> From: yang_y_yi@163.com <yang_y_yi@163.com>
> Sent: Monday, October 26, 2020 2:47 PM
> To: dev@dpdk.org
> Cc: Hu, Jiayu <jiayu.hu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; techboard@dpdk.org;
> thomas@monjalon.net; yangyi01@inspur.com; yang_y_yi@163.com
> Subject: [PATCH v3] gso: fix free issue of mbuf gso segments attach to
>
> From: Yi Yang <yangyi01@inspur.com>
>
> rte_gso_segment decreased refcnt of pkt by one, but
> it is wrong if pkt is external mbuf, pkt won't be
> freed because of incorrect refcnt, the result is
> application can't allocate mbuf from mempool because
> mbufs in mempool are run out of.
>
> One correct way is application should call
> rte_pktmbuf_free after calling rte_gso_segment to free
> pkt explicitly. rte_gso_segment mustn't handle it, this
> should be responsibility of application.
>
> This commit changed rte_gso_segment in functional behavior
> and return value, so the application must take appropriate
> actions according to return values, "ret < 0" means it
> should free and drop 'pkt', "ret == 0" means 'pkt' isn't
> GSOed but 'pkt' can be transimmitted as a normal packet,
> "ret > 0" means 'pkt' has been GSOed into two or multiple
> segments, it should use "pkts_out" to transmit these
> segments. The application must free 'pkt' after call
> rte_gso_segment when return value isn't equal to 0.
>
> Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO")
> Signed-off-by: Yi Yang <yangyi01@inspur.com>
> ---
> Changelog:
>
> v2->v3:
> - add release notes to emphasize behavior and return
> value changes of rte_gso_segment().
> - update return value description of rte_gso_segment().
> - modify related code to adapt to the changes.
>
> v1->v2:
> - update description of rte_gso_segment().
> - change code which calls rte_gso_segment() to
> fix free issue.
>
> ---
> app/test-pmd/csumonly.c | 12 ++++++++++--
> .../prog_guide/generic_segmentation_offload_lib.rst | 7 +++++--
> doc/guides/rel_notes/release_20_11.rst | 7 +++++++
> drivers/net/tap/rte_eth_tap.c | 12 ++++++++++--
> lib/librte_gso/gso_tcp4.c | 6 ++----
> lib/librte_gso/gso_tunnel_tcp4.c | 14 +++++---------
> lib/librte_gso/gso_udp4.c | 6 ++----
> lib/librte_gso/rte_gso.c | 15 +++------------
> lib/librte_gso/rte_gso.h | 8 ++++++--
> 9 files changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index 3d7d244..d813d4f 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -1080,9 +1080,17 @@ struct simple_gre_hdr {
> ret = rte_gso_segment(pkts_burst[i], gso_ctx,
> &gso_segments[nb_segments],
> GSO_MAX_PKT_BURST -
> nb_segments);
> - if (ret >= 0)
> + if (ret >= 1) {
> + /* pkts_burst[i] can be freed safely here. */
> + rte_pktmbuf_free(pkts_burst[i]);
> nb_segments += ret;
> - else {
> + } else if (ret == 0) {
> + /* 0 means it can be transmitted directly
> + * without gso.
> + */
> + gso_segments[nb_segments] = pkts_burst[i];
> + nb_segments += 1;
> + } else {
> TESTPMD_LOG(DEBUG, "Unable to segment
> packet");
> rte_pktmbuf_free(pkts_burst[i]);
> }
> diff --git a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> index 205cb8a..8577572 100644
> --- a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> +++ b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> @@ -25,8 +25,9 @@ Bearing that in mind, the GSO library enables DPDK
> applications to segment
> packets in software. Note however, that GSO is implemented as a
> standalone
> library, and not via a 'fallback' mechanism (i.e. for when TSO is unsupported
> in the underlying hardware); that is, applications must explicitly invoke the
> -GSO library to segment packets. The size of GSO segments ``(segsz)`` is
> -configurable by the application.
> +GSO library to segment packets, they also must call ``rte_pktmbuf_free()`` to
> +free mbuf GSO segments attach to after calling ``rte_gso_segment()``. The
> size
> +of GSO segments ``(segsz)`` is configurable by the application.
>
> Limitations
> -----------
> @@ -233,6 +234,8 @@ To segment an outgoing packet, an application must:
>
> #. Invoke the GSO segmentation API, ``rte_gso_segment()``.
>
> +#. Call ``rte_pktmbuf_free()`` to free mbuf ``rte_gso_segment()`` segments.
> +
> #. If required, update the L3 and L4 checksums of the newly-created
> segments.
> For tunneled packets, the outer IPv4 headers' checksums should also be
> updated. Alternatively, the application may offload checksum calculation
> diff --git a/doc/guides/rel_notes/release_20_11.rst
> b/doc/guides/rel_notes/release_20_11.rst
> index d8ac359..da77396 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -543,6 +543,13 @@ API Changes
> * sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
> from ``struct rte_sched_subport_params``.
>
> +* **Changed ``rte_gso_segment`` in functional behavior and return value.**
> +
> + * Don't save pkt to pkts_out[0] if it isn't GSOed in case of ret == 1.
> + * Return 0 instead of 1 for the above case.
> + * ``rte_gso_segment`` won't free pkt no matter whether it is GSOed, the
> + application has responsibility to free it after call ``rte_gso_segment``.
> +
>
> ABI Changes
> -----------
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 81c6884..2f8abb1 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -751,8 +751,16 @@ struct ipc_queues {
> if (num_tso_mbufs < 0)
> break;
>
> - mbuf = gso_mbufs;
> - num_mbufs = num_tso_mbufs;
> + if (num_tso_mbufs >= 1) {
> + mbuf = gso_mbufs;
> + num_mbufs = num_tso_mbufs;
> + } else {
> + /* 0 means it can be transmitted directly
> + * without gso.
> + */
> + mbuf = &mbuf_in;
> + num_mbufs = 1;
> + }
> } else {
> /* stats.errs will be incremented */
> if (rte_pktmbuf_pkt_len(mbuf_in) > max_size)
> diff --git a/lib/librte_gso/gso_tcp4.c b/lib/librte_gso/gso_tcp4.c
> index ade172a..d31feaf 100644
> --- a/lib/librte_gso/gso_tcp4.c
> +++ b/lib/librte_gso/gso_tcp4.c
> @@ -50,15 +50,13 @@
> pkt->l2_len);
> frag_off = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
> if (unlikely(IS_FRAGMENTED(frag_off))) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> /* Don't process the packet without data */
> hdr_offset = pkt->l2_len + pkt->l3_len + pkt->l4_len;
> if (unlikely(hdr_offset >= pkt->pkt_len)) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> pyld_unit_size = gso_size - hdr_offset;
> diff --git a/lib/librte_gso/gso_tunnel_tcp4.c
> b/lib/librte_gso/gso_tunnel_tcp4.c
> index e0384c2..166aace 100644
> --- a/lib/librte_gso/gso_tunnel_tcp4.c
> +++ b/lib/librte_gso/gso_tunnel_tcp4.c
> @@ -62,7 +62,7 @@
> {
> struct rte_ipv4_hdr *inner_ipv4_hdr;
> uint16_t pyld_unit_size, hdr_offset, frag_off;
> - int ret = 1;
> + int ret;
>
> hdr_offset = pkt->outer_l2_len + pkt->outer_l3_len + pkt->l2_len;
> inner_ipv4_hdr = (struct rte_ipv4_hdr *)(rte_pktmbuf_mtod(pkt,
> char *) +
> @@ -73,25 +73,21 @@
> */
> frag_off = rte_be_to_cpu_16(inner_ipv4_hdr->fragment_offset);
> if (unlikely(IS_FRAGMENTED(frag_off))) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> hdr_offset += pkt->l3_len + pkt->l4_len;
> /* Don't process the packet without data */
> if (hdr_offset >= pkt->pkt_len) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
> pyld_unit_size = gso_size - hdr_offset;
>
> /* Segment the payload */
> ret = gso_do_segment(pkt, hdr_offset, pyld_unit_size, direct_pool,
> indirect_pool, pkts_out, nb_pkts_out);
> - if (ret <= 1)
> - return ret;
> -
> - update_tunnel_ipv4_tcp_headers(pkt, ipid_delta, pkts_out, ret);
> + if (ret > 1)
> + update_tunnel_ipv4_tcp_headers(pkt, ipid_delta, pkts_out,
> ret);
>
> return ret;
> }
> diff --git a/lib/librte_gso/gso_udp4.c b/lib/librte_gso/gso_udp4.c
> index 6fa68f2..5d0186a 100644
> --- a/lib/librte_gso/gso_udp4.c
> +++ b/lib/librte_gso/gso_udp4.c
> @@ -52,8 +52,7 @@
> pkt->l2_len);
> frag_off = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
> if (unlikely(IS_FRAGMENTED(frag_off))) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> /*
> @@ -65,8 +64,7 @@
>
> /* Don't process the packet without data. */
> if (unlikely(hdr_offset + pkt->l4_len >= pkt->pkt_len)) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> /* pyld_unit_size must be a multiple of 8 because frag_off
> diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c
> index 751b5b6..896350e 100644
> --- a/lib/librte_gso/rte_gso.c
> +++ b/lib/librte_gso/rte_gso.c
> @@ -30,7 +30,6 @@
> uint16_t nb_pkts_out)
> {
> struct rte_mempool *direct_pool, *indirect_pool;
> - struct rte_mbuf *pkt_seg;
> uint64_t ol_flags;
> uint16_t gso_size;
> uint8_t ipid_delta;
> @@ -44,8 +43,7 @@
>
> if (gso_ctx->gso_size >= pkt->pkt_len) {
> pkt->ol_flags &= (~(PKT_TX_TCP_SEG | PKT_TX_UDP_SEG));
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> direct_pool = gso_ctx->direct_pool;
> @@ -75,18 +73,11 @@
> indirect_pool, pkts_out, nb_pkts_out);
> } else {
> /* unsupported packet, skip */
> - pkts_out[0] = pkt;
> RTE_LOG(DEBUG, GSO, "Unsupported packet type\n");
> - return 1;
> + ret = 0;
> }
>
> - if (ret > 1) {
> - pkt_seg = pkt;
> - while (pkt_seg) {
> - rte_mbuf_refcnt_update(pkt_seg, -1);
> - pkt_seg = pkt_seg->next;
> - }
> - } else if (ret < 0) {
> + if (ret < 0) {
> /* Revert the ol_flags in the event of failure. */
> pkt->ol_flags = ol_flags;
> }
> diff --git a/lib/librte_gso/rte_gso.h b/lib/librte_gso/rte_gso.h
> index 3aab297..af480ee 100644
> --- a/lib/librte_gso/rte_gso.h
> +++ b/lib/librte_gso/rte_gso.h
> @@ -89,8 +89,11 @@ struct rte_gso_ctx {
> * the GSO segments are sent to should support transmission of multi-
> segment
> * packets.
> *
> - * If the input packet is GSO'd, its mbuf refcnt reduces by 1. Therefore,
> - * when all GSO segments are freed, the input packet is freed automatically.
> + * If the input packet is GSO'd, all the indirect segments are attached to the
> + * input packet.
> + *
> + * rte_gso_segment() will not free the input packet no matter whether it is
> + * GSO'd or not, the application should free it after call rte_gso_segment().
> *
> * If the memory space in pkts_out or MBUF pools is insufficient, this
> * function fails, and it returns (-1) * errno. Otherwise, GSO succeeds,
> @@ -109,6 +112,7 @@ struct rte_gso_ctx {
> *
> * @return
> * - The number of GSO segments filled in pkts_out on success.
> + * - Return 0 if it needn't GSOed.
> * - Return -ENOMEM if run out of memory in MBUF pools.
> * - Return -EINVAL for invalid parameters.
> */
> --
> 1.8.3.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to
2020-10-26 6:47 3% [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to yang_y_yi
@ 2020-10-27 19:55 0% ` Ananyev, Konstantin
2020-10-28 0:51 0% ` Hu, Jiayu
1 sibling, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2020-10-27 19:55 UTC (permalink / raw)
To: yang_y_yi, dev; +Cc: Hu, Jiayu, techboard, thomas, yangyi01
> -----Original Message-----
> From: yang_y_yi@163.com <yang_y_yi@163.com>
> Sent: Monday, October 26, 2020 6:47 AM
> To: dev@dpdk.org
> Cc: Hu, Jiayu <jiayu.hu@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; techboard@dpdk.org; thomas@monjalon.net;
> yangyi01@inspur.com; yang_y_yi@163.com
> Subject: [PATCH v3] gso: fix free issue of mbuf gso segments attach to>
> From: Yi Yang <yangyi01@inspur.com>
>
> rte_gso_segment decreased refcnt of pkt by one, but
> it is wrong if pkt is external mbuf, pkt won't be
> freed because of incorrect refcnt, the result is
> application can't allocate mbuf from mempool because
> mbufs in mempool are run out of.
>
> One correct way is application should call
> rte_pktmbuf_free after calling rte_gso_segment to free
> pkt explicitly. rte_gso_segment mustn't handle it, this
> should be responsibility of application.
>
> This commit changed rte_gso_segment in functional behavior
> and return value, so the application must take appropriate
> actions according to return values, "ret < 0" means it
> should free and drop 'pkt', "ret == 0" means 'pkt' isn't
> GSOed but 'pkt' can be transimmitted as a normal packet,
> "ret > 0" means 'pkt' has been GSOed into two or multiple
> segments, it should use "pkts_out" to transmit these
> segments. The application must free 'pkt' after call
> rte_gso_segment when return value isn't equal to 0.
Tech-board members: this is not a formal API breakage,
but it is a functional change (i.e. all code that uses that API will need to be changed).
There was no deprecation note in advance.
So please provide your input: are you ok with such change or not.
I am ok with the proposed changes.
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO")
> Signed-off-by: Yi Yang <yangyi01@inspur.com>
> ---
> Changelog:
>
> v2->v3:
> - add release notes to emphasize behavior and return
> value changes of rte_gso_segment().
> - update return value description of rte_gso_segment().
> - modify related code to adapt to the changes.
>
> v1->v2:
> - update description of rte_gso_segment().
> - change code which calls rte_gso_segment() to
> fix free issue.
>
> ---
> app/test-pmd/csumonly.c | 12 ++++++++++--
> .../prog_guide/generic_segmentation_offload_lib.rst | 7 +++++--
> doc/guides/rel_notes/release_20_11.rst | 7 +++++++
> drivers/net/tap/rte_eth_tap.c | 12 ++++++++++--
> lib/librte_gso/gso_tcp4.c | 6 ++----
> lib/librte_gso/gso_tunnel_tcp4.c | 14 +++++---------
> lib/librte_gso/gso_udp4.c | 6 ++----
> lib/librte_gso/rte_gso.c | 15 +++------------
> lib/librte_gso/rte_gso.h | 8 ++++++--
> 9 files changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index 3d7d244..d813d4f 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -1080,9 +1080,17 @@ struct simple_gre_hdr {
> ret = rte_gso_segment(pkts_burst[i], gso_ctx,
> &gso_segments[nb_segments],
> GSO_MAX_PKT_BURST - nb_segments);
> - if (ret >= 0)
> + if (ret >= 1) {
> + /* pkts_burst[i] can be freed safely here. */
> + rte_pktmbuf_free(pkts_burst[i]);
> nb_segments += ret;
> - else {
> + } else if (ret == 0) {
> + /* 0 means it can be transmitted directly
> + * without gso.
> + */
> + gso_segments[nb_segments] = pkts_burst[i];
> + nb_segments += 1;
> + } else {
> TESTPMD_LOG(DEBUG, "Unable to segment packet");
> rte_pktmbuf_free(pkts_burst[i]);
> }
> diff --git a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> index 205cb8a..8577572 100644
> --- a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> +++ b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
> @@ -25,8 +25,9 @@ Bearing that in mind, the GSO library enables DPDK applications to segment
> packets in software. Note however, that GSO is implemented as a standalone
> library, and not via a 'fallback' mechanism (i.e. for when TSO is unsupported
> in the underlying hardware); that is, applications must explicitly invoke the
> -GSO library to segment packets. The size of GSO segments ``(segsz)`` is
> -configurable by the application.
> +GSO library to segment packets, they also must call ``rte_pktmbuf_free()`` to
> +free mbuf GSO segments attach to after calling ``rte_gso_segment()``. The size
> +of GSO segments ``(segsz)`` is configurable by the application.
>
> Limitations
> -----------
> @@ -233,6 +234,8 @@ To segment an outgoing packet, an application must:
>
> #. Invoke the GSO segmentation API, ``rte_gso_segment()``.
>
> +#. Call ``rte_pktmbuf_free()`` to free mbuf ``rte_gso_segment()`` segments.
> +
> #. If required, update the L3 and L4 checksums of the newly-created segments.
> For tunneled packets, the outer IPv4 headers' checksums should also be
> updated. Alternatively, the application may offload checksum calculation
> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
> index d8ac359..da77396 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -543,6 +543,13 @@ API Changes
> * sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
> from ``struct rte_sched_subport_params``.
>
> +* **Changed ``rte_gso_segment`` in functional behavior and return value.**
> +
> + * Don't save pkt to pkts_out[0] if it isn't GSOed in case of ret == 1.
> + * Return 0 instead of 1 for the above case.
> + * ``rte_gso_segment`` won't free pkt no matter whether it is GSOed, the
> + application has responsibility to free it after call ``rte_gso_segment``.
> +
>
> ABI Changes
> -----------
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index 81c6884..2f8abb1 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -751,8 +751,16 @@ struct ipc_queues {
> if (num_tso_mbufs < 0)
> break;
>
> - mbuf = gso_mbufs;
> - num_mbufs = num_tso_mbufs;
> + if (num_tso_mbufs >= 1) {
> + mbuf = gso_mbufs;
> + num_mbufs = num_tso_mbufs;
> + } else {
> + /* 0 means it can be transmitted directly
> + * without gso.
> + */
> + mbuf = &mbuf_in;
> + num_mbufs = 1;
> + }
> } else {
> /* stats.errs will be incremented */
> if (rte_pktmbuf_pkt_len(mbuf_in) > max_size)
> diff --git a/lib/librte_gso/gso_tcp4.c b/lib/librte_gso/gso_tcp4.c
> index ade172a..d31feaf 100644
> --- a/lib/librte_gso/gso_tcp4.c
> +++ b/lib/librte_gso/gso_tcp4.c
> @@ -50,15 +50,13 @@
> pkt->l2_len);
> frag_off = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
> if (unlikely(IS_FRAGMENTED(frag_off))) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> /* Don't process the packet without data */
> hdr_offset = pkt->l2_len + pkt->l3_len + pkt->l4_len;
> if (unlikely(hdr_offset >= pkt->pkt_len)) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> pyld_unit_size = gso_size - hdr_offset;
> diff --git a/lib/librte_gso/gso_tunnel_tcp4.c b/lib/librte_gso/gso_tunnel_tcp4.c
> index e0384c2..166aace 100644
> --- a/lib/librte_gso/gso_tunnel_tcp4.c
> +++ b/lib/librte_gso/gso_tunnel_tcp4.c
> @@ -62,7 +62,7 @@
> {
> struct rte_ipv4_hdr *inner_ipv4_hdr;
> uint16_t pyld_unit_size, hdr_offset, frag_off;
> - int ret = 1;
> + int ret;
>
> hdr_offset = pkt->outer_l2_len + pkt->outer_l3_len + pkt->l2_len;
> inner_ipv4_hdr = (struct rte_ipv4_hdr *)(rte_pktmbuf_mtod(pkt, char *) +
> @@ -73,25 +73,21 @@
> */
> frag_off = rte_be_to_cpu_16(inner_ipv4_hdr->fragment_offset);
> if (unlikely(IS_FRAGMENTED(frag_off))) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> hdr_offset += pkt->l3_len + pkt->l4_len;
> /* Don't process the packet without data */
> if (hdr_offset >= pkt->pkt_len) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
> pyld_unit_size = gso_size - hdr_offset;
>
> /* Segment the payload */
> ret = gso_do_segment(pkt, hdr_offset, pyld_unit_size, direct_pool,
> indirect_pool, pkts_out, nb_pkts_out);
> - if (ret <= 1)
> - return ret;
> -
> - update_tunnel_ipv4_tcp_headers(pkt, ipid_delta, pkts_out, ret);
> + if (ret > 1)
> + update_tunnel_ipv4_tcp_headers(pkt, ipid_delta, pkts_out, ret);
>
> return ret;
> }
> diff --git a/lib/librte_gso/gso_udp4.c b/lib/librte_gso/gso_udp4.c
> index 6fa68f2..5d0186a 100644
> --- a/lib/librte_gso/gso_udp4.c
> +++ b/lib/librte_gso/gso_udp4.c
> @@ -52,8 +52,7 @@
> pkt->l2_len);
> frag_off = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
> if (unlikely(IS_FRAGMENTED(frag_off))) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> /*
> @@ -65,8 +64,7 @@
>
> /* Don't process the packet without data. */
> if (unlikely(hdr_offset + pkt->l4_len >= pkt->pkt_len)) {
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> /* pyld_unit_size must be a multiple of 8 because frag_off
> diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c
> index 751b5b6..896350e 100644
> --- a/lib/librte_gso/rte_gso.c
> +++ b/lib/librte_gso/rte_gso.c
> @@ -30,7 +30,6 @@
> uint16_t nb_pkts_out)
> {
> struct rte_mempool *direct_pool, *indirect_pool;
> - struct rte_mbuf *pkt_seg;
> uint64_t ol_flags;
> uint16_t gso_size;
> uint8_t ipid_delta;
> @@ -44,8 +43,7 @@
>
> if (gso_ctx->gso_size >= pkt->pkt_len) {
> pkt->ol_flags &= (~(PKT_TX_TCP_SEG | PKT_TX_UDP_SEG));
> - pkts_out[0] = pkt;
> - return 1;
> + return 0;
> }
>
> direct_pool = gso_ctx->direct_pool;
> @@ -75,18 +73,11 @@
> indirect_pool, pkts_out, nb_pkts_out);
> } else {
> /* unsupported packet, skip */
> - pkts_out[0] = pkt;
> RTE_LOG(DEBUG, GSO, "Unsupported packet type\n");
> - return 1;
> + ret = 0;
> }
>
> - if (ret > 1) {
> - pkt_seg = pkt;
> - while (pkt_seg) {
> - rte_mbuf_refcnt_update(pkt_seg, -1);
> - pkt_seg = pkt_seg->next;
> - }
> - } else if (ret < 0) {
> + if (ret < 0) {
> /* Revert the ol_flags in the event of failure. */
> pkt->ol_flags = ol_flags;
> }
> diff --git a/lib/librte_gso/rte_gso.h b/lib/librte_gso/rte_gso.h
> index 3aab297..af480ee 100644
> --- a/lib/librte_gso/rte_gso.h
> +++ b/lib/librte_gso/rte_gso.h
> @@ -89,8 +89,11 @@ struct rte_gso_ctx {
> * the GSO segments are sent to should support transmission of multi-segment
> * packets.
> *
> - * If the input packet is GSO'd, its mbuf refcnt reduces by 1. Therefore,
> - * when all GSO segments are freed, the input packet is freed automatically.
> + * If the input packet is GSO'd, all the indirect segments are attached to the
> + * input packet.
> + *
> + * rte_gso_segment() will not free the input packet no matter whether it is
> + * GSO'd or not, the application should free it after call rte_gso_segment().
> *
> * If the memory space in pkts_out or MBUF pools is insufficient, this
> * function fails, and it returns (-1) * errno. Otherwise, GSO succeeds,
> @@ -109,6 +112,7 @@ struct rte_gso_ctx {
> *
> * @return
> * - The number of GSO segments filled in pkts_out on success.
> + * - Return 0 if it needn't GSOed.
> * - Return -ENOMEM if run out of memory in MBUF pools.
> * - Return -EINVAL for invalid parameters.
> */
> --
> 1.8.3.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-27 19:26 0% ` Akhil Goyal
@ 2020-10-27 19:41 0% ` Gujjar, Abhinandan S
0 siblings, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-27 19:41 UTC (permalink / raw)
To: Akhil Goyal, dev, Doherty, Declan, Honnappa.Nagarahalli, Ananyev,
Konstantin
Cc: Vangati, Narender, jerinj
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Wednesday, October 28, 2020 12:56 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v4 1/3] cryptodev: support enqueue callback functions
>
> Hi Abhinandan,
>
> > > > +static int
> > > > +cryptodev_cb_init(struct rte_cryptodev *dev) {
> > > > + struct rte_cryptodev_enq_cb_rcu *list;
> > > > + struct rte_rcu_qsbr *qsbr;
> > > > + uint16_t qp_id;
> > > > + size_t size;
> > > > +
> > > > + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> > > > + const uint32_t max_threads = 1;
> > > > +
> > > > + dev->enq_cbs = rte_zmalloc(NULL,
> > > > + sizeof(struct rte_cryptodev_enq_cb_rcu) *
> > > > + dev->data->nb_queue_pairs, 0);
> > > > + if (dev->enq_cbs == NULL) {
> > > > + CDEV_LOG_ERR("Failed to allocate memory for callbacks");
> > > > + rte_errno = ENOMEM;
> > > > + return -1;
> > > > + }
> > >
> > > Why not return ENOMEM here? You are not using rte_errno while
> > > returning from this function, so setting it does not have any meaning.
> > This is a internal function. The caller is returning ENOMEM.
>
> The caller can return the returned value from cryptodev_cb_init, instead of
> explicitly Returning ENOMEM.
> There is no point of setting rte_errno here.
Ok. I will update the patch.
>
>
> > > > /** The data structure associated with each crypto device. */
> > > > struct rte_cryptodev {
> > > > dequeue_pkt_burst_t dequeue_burst; @@ -867,6 +922,10 @@ struct
> > > > rte_cryptodev {
> > > > __extension__
> > > > uint8_t attached : 1;
> > > > /**< Flag indicating the device is attached */
> > > > +
> > > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > > + /**< User application callback for pre enqueue processing */
> > > > +
> > > Extra line
> > ok
> > >
> > > We should add support for post dequeue callbacks also. Since this is
> > > an LTS release And we wont be very flexible in future quarterly
> > > release, we should do all the changes In one go.
> > This patch set is driven by requirement. Recently, we have a
> > requirement to have callback for dequeue as well. Looking at code
> > freeze date, I am not sure we can target that as well. Let this patch
> > go in and I will send a separate patch for dequeue callback.
> >
>
> We may not be able to change the rte_cryptodev structure so frequently.
> It may be allowed to change it 21.11 release. Which is too far.
> I think atleast the cryptodev changes can go in RC2 and test app for deq cbs
> Can go in RC3 if not RC2.
" cryptodev changes " -> Is it rte_cryptodev structure changes alone or supporting
dequeue callback as well in RC2? And then have test app changes in RC3?
If it is about adding dequeue callback support in RC2, I will try.
If it does not work, hope we can still the get the enqueue callback + rte_cryptodev structure
changes to support dequeue callbacks in the next patch set.
>
> > > I believe we should also double check with techboard if this is an ABI
> breakage.
> > > IMO, it is ABI breakage, rte_cryprodevs is part of stable APIs, but not sure.
> > >
> > > > } __rte_cache_aligned;
> > > >
>
>
>
> > > >
> > > > +#ifdef RTE_CRYPTO_CALLBACKS
> > > > +/**
> > > > + * @warning
> > > > + * @b EXPERIMENTAL: this API may change without prior notice
> > > > + *
> > > > + * Add a user callback for a given crypto device and queue pair
> > > > +which will be
> > > > + * called on crypto ops enqueue.
> > > > + *
> > > > + * This API configures a function to be called for each burst of
> > > > +crypto ops
> > > > + * received on a given crypto device queue pair. The return value
> > > > +is a pointer
> > > > + * that can be used later to remove the callback using
> > > > + * rte_cryptodev_remove_enq_callback().
> > > > + *
> > > > + * Multiple functions are called in the order that they are added.
> > >
> > > Is there a limit for the number of cbs that can be added? Better to
> > > add a Comment here.
>
> I think you missed this comment.
There is not limitation as of now. I will add a comment on the same.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-27 19:16 0% ` Gujjar, Abhinandan S
@ 2020-10-27 19:26 0% ` Akhil Goyal
2020-10-27 19:41 0% ` Gujjar, Abhinandan S
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2020-10-27 19:26 UTC (permalink / raw)
To: Gujjar, Abhinandan S, dev, Doherty, Declan, Honnappa.Nagarahalli,
Ananyev, Konstantin
Cc: Vangati, Narender, jerinj
Hi Abhinandan,
> > > +static int
> > > +cryptodev_cb_init(struct rte_cryptodev *dev) {
> > > + struct rte_cryptodev_enq_cb_rcu *list;
> > > + struct rte_rcu_qsbr *qsbr;
> > > + uint16_t qp_id;
> > > + size_t size;
> > > +
> > > + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> > > + const uint32_t max_threads = 1;
> > > +
> > > + dev->enq_cbs = rte_zmalloc(NULL,
> > > + sizeof(struct rte_cryptodev_enq_cb_rcu) *
> > > + dev->data->nb_queue_pairs, 0);
> > > + if (dev->enq_cbs == NULL) {
> > > + CDEV_LOG_ERR("Failed to allocate memory for callbacks");
> > > + rte_errno = ENOMEM;
> > > + return -1;
> > > + }
> >
> > Why not return ENOMEM here? You are not using rte_errno while returning
> > from this function, so setting it does not have any meaning.
> This is a internal function. The caller is returning ENOMEM.
The caller can return the returned value from cryptodev_cb_init, instead of explicitly
Returning ENOMEM.
There is no point of setting rte_errno here.
> > > /** The data structure associated with each crypto device. */ struct
> > > rte_cryptodev {
> > > dequeue_pkt_burst_t dequeue_burst;
> > > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > > __extension__
> > > uint8_t attached : 1;
> > > /**< Flag indicating the device is attached */
> > > +
> > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > + /**< User application callback for pre enqueue processing */
> > > +
> > Extra line
> ok
> >
> > We should add support for post dequeue callbacks also. Since this is an LTS
> > release And we wont be very flexible in future quarterly release, we should do
> > all the changes In one go.
> This patch set is driven by requirement. Recently, we have a requirement to have
> callback for dequeue as well. Looking at code freeze date, I am not sure we can
> target that as well. Let this patch go in and I will send a separate patch for
> dequeue callback.
>
We may not be able to change the rte_cryptodev structure so frequently.
It may be allowed to change it 21.11 release. Which is too far.
I think atleast the cryptodev changes can go in RC2 and test app for deq cbs
Can go in RC3 if not RC2.
> > I believe we should also double check with techboard if this is an ABI breakage.
> > IMO, it is ABI breakage, rte_cryprodevs is part of stable APIs, but not sure.
> >
> > > } __rte_cache_aligned;
> > >
> > >
> > > +#ifdef RTE_CRYPTO_CALLBACKS
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this API may change without prior notice
> > > + *
> > > + * Add a user callback for a given crypto device and queue pair which
> > > +will be
> > > + * called on crypto ops enqueue.
> > > + *
> > > + * This API configures a function to be called for each burst of
> > > +crypto ops
> > > + * received on a given crypto device queue pair. The return value is
> > > +a pointer
> > > + * that can be used later to remove the callback using
> > > + * rte_cryptodev_remove_enq_callback().
> > > + *
> > > + * Multiple functions are called in the order that they are added.
> >
> > Is there a limit for the number of cbs that can be added? Better to add a
> > Comment here.
I think you missed this comment.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-27 18:19 4% ` Akhil Goyal
@ 2020-10-27 19:16 0% ` Gujjar, Abhinandan S
2020-10-27 19:26 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-27 19:16 UTC (permalink / raw)
To: Akhil Goyal, dev, Doherty, Declan, Honnappa.Nagarahalli, Ananyev,
Konstantin
Cc: Vangati, Narender, jerinj
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, October 27, 2020 11:49 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v4 1/3] cryptodev: support enqueue callback functions
>
> Hi Abhinandan,
> > Subject: [v4 1/3] cryptodev: support enqueue callback functions
> >
> > This patch adds APIs to add/remove callback functions. The callback
> > function will be called for each burst of crypto ops received on a
> > given crypto device queue pair.
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > config/rte_config.h | 1 +
> > lib/librte_cryptodev/meson.build | 2 +-
> > lib/librte_cryptodev/rte_cryptodev.c | 230
> +++++++++++++++++++++++++
> > lib/librte_cryptodev/rte_cryptodev.h | 158 ++++++++++++++++-
> > lib/librte_cryptodev/rte_cryptodev_version.map | 2 +
> > 5 files changed, 391 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/rte_config.h b/config/rte_config.h index
> > 03d90d7..e999d93 100644
> > --- a/config/rte_config.h
> > +++ b/config/rte_config.h
> > @@ -61,6 +61,7 @@
> > /* cryptodev defines */
> > #define RTE_CRYPTO_MAX_DEVS 64
> > #define RTE_CRYPTODEV_NAME_LEN 64
> > +#define RTE_CRYPTO_CALLBACKS 1
> >
> > /* compressdev defines */
> > #define RTE_COMPRESS_MAX_DEVS 64
> > diff --git a/lib/librte_cryptodev/meson.build
> > b/lib/librte_cryptodev/meson.build
> > index c4c6b3b..8c5493f 100644
> > --- a/lib/librte_cryptodev/meson.build
> > +++ b/lib/librte_cryptodev/meson.build
> > @@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
> > 'rte_crypto.h',
> > 'rte_crypto_sym.h',
> > 'rte_crypto_asym.h')
> > -deps += ['kvargs', 'mbuf']
> > +deps += ['kvargs', 'mbuf', 'rcu']
> > diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> > b/lib/librte_cryptodev/rte_cryptodev.c
> > index 3d95ac6..0880d9b 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.c
> > +++ b/lib/librte_cryptodev/rte_cryptodev.c
> > @@ -448,6 +448,91 @@ struct
> > rte_cryptodev_sym_session_pool_private_data
> > {
> > return 0;
> > }
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/* spinlock for crypto device enq callbacks */ static rte_spinlock_t
> > +rte_cryptodev_callback_lock =
> > RTE_SPINLOCK_INITIALIZER;
> > +
> > +static void
> > +cryptodev_cb_cleanup(struct rte_cryptodev *dev) {
> > + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + uint16_t qp_id;
> > +
> > + if (dev->enq_cbs == NULL)
> > + return;
> > +
> > + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> > + list = &dev->enq_cbs[qp_id];
> > + prev_cb = &list->next;
> > +
> > + while (*prev_cb != NULL) {
> > + curr_cb = *prev_cb;
> > + /* Remove the user cb from the callback list. */
> > + __atomic_store_n(prev_cb, curr_cb->next,
> > + __ATOMIC_RELAXED);
> > + rte_rcu_qsbr_synchronize(list->qsbr,
> > + RTE_QSBR_THRID_INVALID);
> > + rte_free(curr_cb);
> > + }
> > +
> > + rte_free(list->qsbr);
> > + }
> > +
> > + rte_free(dev->enq_cbs);
> > + dev->enq_cbs = NULL;
> > +}
> > +
> > +static int
> > +cryptodev_cb_init(struct rte_cryptodev *dev) {
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + struct rte_rcu_qsbr *qsbr;
> > + uint16_t qp_id;
> > + size_t size;
> > +
> > + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> > + const uint32_t max_threads = 1;
> > +
> > + dev->enq_cbs = rte_zmalloc(NULL,
> > + sizeof(struct rte_cryptodev_enq_cb_rcu) *
> > + dev->data->nb_queue_pairs, 0);
> > + if (dev->enq_cbs == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for callbacks");
> > + rte_errno = ENOMEM;
> > + return -1;
> > + }
>
> Why not return ENOMEM here? You are not using rte_errno while returning
> from this function, so setting it does not have any meaning.
This is a internal function. The caller is returning ENOMEM.
>
> > +
> > + /* Create RCU QSBR variable */
> > + size = rte_rcu_qsbr_get_memsize(max_threads);
> > +
> > + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> > + list = &dev->enq_cbs[qp_id];
> > + qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> > + if (qsbr == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for RCU
> on
> > "
> > + "queue_pair_id=%d", qp_id);
> > + goto cb_init_err;
> > + }
> > +
> > + if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> > + CDEV_LOG_ERR("Failed to initialize for RCU on "
> > + "queue_pair_id=%d", qp_id);
> > + goto cb_init_err;
> > + }
> > +
> > + list->qsbr = qsbr;
> > + }
> > +
> > + return 0;
> > +
> > +cb_init_err:
> > + rte_errno = ENOMEM;
> > + cryptodev_cb_cleanup(dev);
> > + return -1;
> Same here, return -ENOMEM
Same as above
>
> > +
> Extra line
ok
>
> > +}
> > +#endif
> >
> > const char *
> > rte_cryptodev_get_feature_name(uint64_t flag) @@ -927,6 +1012,11 @@
> > struct rte_cryptodev *
> >
> > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -
> ENOTSUP);
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> > + cryptodev_cb_cleanup(dev);
> > + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> > +#endif
> > /* Setup new number of queue pairs and reconfigure device. */
> > diag = rte_cryptodev_queue_pairs_config(dev, config-
> >nb_queue_pairs,
> > config->socket_id);
> > @@ -936,6 +1026,15 @@ struct rte_cryptodev *
> > return diag;
> > }
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> > + diag = cryptodev_cb_init(dev);
> > + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> > + if (diag) {
> > + CDEV_LOG_ERR("Callback init failed for dev_id=%d", dev_id);
> > + return -ENOMEM;
> > + }
> > +#endif
> > rte_cryptodev_trace_configure(dev_id, config);
> > return (*dev->dev_ops->dev_configure)(dev, config); } @@ -1136,6
> > +1235,137 @@ struct rte_cryptodev *
> > socket_id);
> > }
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +struct rte_cryptodev_cb *
> > +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + rte_cryptodev_callback_fn cb_fn,
> > + void *cb_arg)
> > +{
> > + struct rte_cryptodev *dev;
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + struct rte_cryptodev_cb *cb, *tail;
> > +
> > + if (!cb_fn)
> > + return NULL;
> > +
> > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> > + return NULL;
> > + }
> > +
> > + dev = &rte_crypto_devices[dev_id];
> > + if (qp_id >= dev->data->nb_queue_pairs) {
> > + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> > + return NULL;
> > + }
>
> Errno is not set before above three returns.
I will update it in the next version of the patch.
>
> > +
> > + cb = rte_zmalloc(NULL, sizeof(*cb), 0);
> > + if (cb == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for callback on "
> > + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > + rte_errno = ENOMEM;
> > + return NULL;
> > + }
> > +
> > + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> > +
> > + cb->fn = cb_fn;
> > + cb->arg = cb_arg;
> > +
> > + /* Add the callbacks in fifo order. */
> > + list = &dev->enq_cbs[qp_id];
> > + tail = list->next;
> > +
> > + if (tail) {
> > + while (tail->next)
> > + tail = tail->next;
> > + /* Stores to cb->fn and cb->param should complete before
> > + * cb is visible to data plane.
> > + */
> > + __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
> > + } else {
> > + /* Stores to cb->fn and cb->param should complete before
> > + * cb is visible to data plane.
> > + */
> > + __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
> > + }
> > +
> > + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> > +
> > + return cb;
> > +}
> > +
> > +int
> > +rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + struct rte_cryptodev_cb *cb)
> > +{
> > + struct rte_cryptodev *dev;
> > + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + int ret;
> > +
> > + ret = -EINVAL;
> No need to set EINVAL here. You are returning same value everywhere.
> The error numbers can be different at each exit.
Sure. I will take care returning different error numbers.
The initialized is required because of below during just before calling
Rcu sync.
>
> > +
> > + if (!cb) {
> > + CDEV_LOG_ERR("cb is NULL");
> > + return ret;
> You should directly return -EINVAL here and in below cases as well.
>
> > + }
> > +
> > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> > + return ret;
> Here return value should be -ENODEV
>
>
> > + }
> > +
> > + dev = &rte_crypto_devices[dev_id];
> > + if (qp_id >= dev->data->nb_queue_pairs) {
> > + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> > + return ret;
> > + }
> > +
> > + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> > + if (dev->enq_cbs == NULL) {
> > + CDEV_LOG_ERR("Callback not initialized");
> > + goto cb_err;
> > + }
> > +
> > + list = &dev->enq_cbs[qp_id];
> > + if (list == NULL) {
> > + CDEV_LOG_ERR("Callback list is NULL");
> > + goto cb_err;
> > + }
> > +
> > + if (list->qsbr == NULL) {
> > + CDEV_LOG_ERR("Rcu qsbr is NULL");
> > + goto cb_err;
> > + }
> > +
> > + prev_cb = &list->next;
> > + for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
> > + curr_cb = *prev_cb;
> > + if (curr_cb == cb) {
> > + /* Remove the user cb from the callback list. */
> > + __atomic_store_n(prev_cb, curr_cb->next,
> > + __ATOMIC_RELAXED);
> > + ret = 0;
> > + break;
> > + }
> > + }
> > +
> > + if (!ret) {
> > + /* Call sync with invalid thread id as this is part of
> > + * control plane API
> > + */
> > + rte_rcu_qsbr_synchronize(list->qsbr,
> > RTE_QSBR_THRID_INVALID);
> > + rte_free(cb);
> > + }
> > +
> > +cb_err:
> > + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> > + return ret;
> > +}
> > +#endif
> >
> > int
> > rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats
> > *stats) diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> > b/lib/librte_cryptodev/rte_cryptodev.h
> > index 0935fd5..1b7d7ef 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -23,6 +23,7 @@
> > #include "rte_dev.h"
> > #include <rte_common.h>
> > #include <rte_config.h>
> > +#include <rte_rcu_qsbr.h>
> >
> > #include "rte_cryptodev_trace_fp.h"
> >
> > @@ -522,6 +523,34 @@ struct rte_cryptodev_qp_conf {
> > /**< The mempool for creating sess private data in sessionless mode
> > */ };
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * Function type used for pre processing crypto ops when enqueue
> > +burst is
> > + * called.
> > + *
> > + * The callback function is called on enqueue burst immediately
> > + * before the crypto ops are put onto the hardware queue for processing.
> > + *
> > + * @param dev_id The identifier of the device.
> > + * @param qp_id The index of the queue pair in which ops are
> > + * to be enqueued for processing. The value
> > + * must be in the range [0, nb_queue_pairs - 1]
> > + * previously supplied to
> > + * *rte_cryptodev_configure*.
> > + * @param ops The address of an array of *nb_ops* pointers
> > + * to *rte_crypto_op* structures which contain
> > + * the crypto operations to be processed.
> > + * @param nb_ops The number of operations to process.
> > + * @param user_param The arbitrary user parameter passed in by the
> > + * application when the callback was originally
> > + * registered.
> > + * @return The number of ops to be enqueued to the
> > + * crypto device.
> > + */
> > +typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t
> qp_id,
> > + struct rte_crypto_op **ops, uint16_t nb_ops, void
> > *user_param);
> > +#endif
> > +
> > /**
> > * Typedef for application callback function to be registered by application
> > * software for notification of device events @@ -822,7 +851,6 @@
> > struct rte_cryptodev_config {
> > enum rte_cryptodev_event_type event,
> > rte_cryptodev_cb_fn cb_fn, void *cb_arg);
> >
> > -
> > typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
> > struct rte_crypto_op **ops, uint16_t nb_ops);
> > /**< Dequeue processed packets from queue pair of a device. */ @@
> > -839,6 +867,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
> > /** Structure to keep track of registered callbacks */
> > TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * @internal
> > + * Structure used to hold information about the callbacks to be
> > +called for a
> > + * queue pair on enqueue.
> > + */
> > +struct rte_cryptodev_cb {
> > + struct rte_cryptodev_cb *next;
> > + /** < Pointer to next callback */
> > + rte_cryptodev_callback_fn fn;
> > + /** < Pointer to callback function */
> > + void *arg;
> > + /** < Pointer to argument */
> > +};
> > +
> > +/**
> > + * @internal
> > + * Structure used to hold information about the RCU for a queue pair.
> > + */
> > +struct rte_cryptodev_enq_cb_rcu {
> > + struct rte_cryptodev_cb *next;
> > + /** < Pointer to next callback */
> > + struct rte_rcu_qsbr *qsbr;
> > + /** < RCU QSBR variable per queue pair */ }; #endif
> > +
> > /** The data structure associated with each crypto device. */ struct
> > rte_cryptodev {
> > dequeue_pkt_burst_t dequeue_burst;
> > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > __extension__
> > uint8_t attached : 1;
> > /**< Flag indicating the device is attached */
> > +
> > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > + /**< User application callback for pre enqueue processing */
> > +
> Extra line
ok
>
> We should add support for post dequeue callbacks also. Since this is an LTS
> release And we wont be very flexible in future quarterly release, we should do
> all the changes In one go.
This patch set is driven by requirement. Recently, we have a requirement to have
callback for dequeue as well. Looking at code freeze date, I am not sure we can
target that as well. Let this patch go in and I will send a separate patch for
dequeue callback.
> I believe we should also double check with techboard if this is an ABI breakage.
> IMO, it is ABI breakage, rte_cryprodevs is part of stable APIs, but not sure.
>
> > } __rte_cache_aligned;
> >
> > void *
> > @@ -989,6 +1048,31 @@ struct rte_cryptodev_data { {
> > struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > + if (unlikely(dev->enq_cbs != NULL)) {
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + struct rte_cryptodev_cb *cb;
> > +
> > + /* __ATOMIC_RELEASE memory order was used when the
> > + * call back was inserted into the list.
> > + * Since there is a clear dependency between loading
> > + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order
> > is
> > + * not required.
> > + */
> > + list = &dev->enq_cbs[qp_id];
> > + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> > + cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
> > +
> > + while (cb != NULL) {
> > + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> > + cb->arg);
> > + cb = cb->next;
> > + };
> > +
> > + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> > + }
> > +#endif
> > +
> > rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops,
> > nb_ops);
> > return (*dev->enqueue_burst)(
> > dev->data->queue_pairs[qp_id], ops, nb_ops); @@ -
> 1730,6 +1814,78
> > @@ struct rte_crypto_raw_dp_ctx {
> > rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
> > uint32_t n);
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Add a user callback for a given crypto device and queue pair which
> > +will be
> > + * called on crypto ops enqueue.
> > + *
> > + * This API configures a function to be called for each burst of
> > +crypto ops
> > + * received on a given crypto device queue pair. The return value is
> > +a pointer
> > + * that can be used later to remove the callback using
> > + * rte_cryptodev_remove_enq_callback().
> > + *
> > + * Multiple functions are called in the order that they are added.
>
> Is there a limit for the number of cbs that can be added? Better to add a
> Comment here.
>
> > + *
> > + * @param dev_id The identifier of the device.
> > + * @param qp_id The index of the queue pair in which ops are
> > + * to be enqueued for processing. The value
> > + * must be in the range [0, nb_queue_pairs - 1]
> > + * previously supplied to
> > + * *rte_cryptodev_configure*.
> > + * @param cb_fn The callback function
> > + * @param cb_arg A generic pointer parameter which will be
> > passed
> > + * to each invocation of the callback function on
> > + * this crypto device and queue pair.
> > + *
> > + * @return
> > + * NULL on error.
> > + * On success, a pointer value which can later be used to remove the
> callback.
> > + */
> > +
> > +__rte_experimental
> > +struct rte_cryptodev_cb *
> > +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + rte_cryptodev_callback_fn cb_fn,
> > + void *cb_arg);
> > +
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Remove a user callback function for given crypto device and queue pair.
> > + *
> > + * This function is used to removed callbacks that were added to a
> > +crypto
> > + * device queue pair using rte_cryptodev_add_enq_callback().
> > + *
> > + *
> > + *
> > + * @param dev_id The identifier of the device.
> > + * @param qp_id The index of the queue pair in which ops are
> > + * to be enqueued for processing. The value
> > + * must be in the range [0, nb_queue_pairs - 1]
> > + * previously supplied to
> > + * *rte_cryptodev_configure*.
> > + * @param cb Pointer to user supplied callback created via
> > + * rte_cryptodev_add_enq_callback().
> > + *
> > + * @return
> > + * - 0: Success. Callback was removed.
> > + * - -EINVAL: The dev_id or the qp_id is out of range, or the callback
> > + * is NULL or not found for the crypto device queue pair.
> > + */
> > +
> > +__rte_experimental
> > +int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + struct rte_cryptodev_cb *cb);
> > +
> > +#endif
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map
> > b/lib/librte_cryptodev/rte_cryptodev_version.map
> > index 7e4360f..5d8d6b0 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev_version.map
> > +++ b/lib/librte_cryptodev/rte_cryptodev_version.map
> > @@ -101,6 +101,7 @@ EXPERIMENTAL {
> > rte_cryptodev_get_qp_status;
> >
> > # added in 20.11
> > + rte_cryptodev_add_enq_callback;
> > rte_cryptodev_configure_raw_dp_ctx;
> > rte_cryptodev_get_raw_dp_ctx_size;
> > rte_cryptodev_raw_dequeue;
> > @@ -109,4 +110,5 @@ EXPERIMENTAL {
> > rte_cryptodev_raw_enqueue;
> > rte_cryptodev_raw_enqueue_burst;
> > rte_cryptodev_raw_enqueue_done;
> > + rte_cryptodev_remove_enq_callback;
> > };
> > --
> > 1.9.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
2020-10-27 18:19 4% ` Akhil Goyal
@ 2020-10-27 18:28 4% ` Akhil Goyal
2020-10-28 8:20 0% ` Gujjar, Abhinandan S
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2020-10-27 18:28 UTC (permalink / raw)
To: Abhinandan Gujjar, dev, declan.doherty, Honnappa.Nagarahalli,
konstantin.ananyev, techboard
Cc: narender.vangati, jerinj
Hi Tech board members,
I have a doubt about the ABI breakage in below addition of field.
Could you please comment.
> /** The data structure associated with each crypto device. */
> struct rte_cryptodev {
> dequeue_pkt_burst_t dequeue_burst;
> @@ -867,6 +922,10 @@ struct rte_cryptodev {
> __extension__
> uint8_t attached : 1;
> /**< Flag indicating the device is attached */
> +
> + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> + /**< User application callback for pre enqueue processing */
> +
> } __rte_cache_aligned;
Here rte_cryptodevs is defined in stable API list in map file which is a pointer
To all rte_cryptodev and the above change is changing the size of the structure.
IMO, it seems an ABI breakage, but not sure. So wanted to double check.
Now if it is an ABI breakage, then can we allow it? There was no deprecation notice
Prior to this release.
Also I think if we are allowing the above change, then we should also add another
Field for deq_cbs also for post crypto processing in this patch only.
Regards,
Akhil
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions
@ 2020-10-27 18:19 4% ` Akhil Goyal
2020-10-27 19:16 0% ` Gujjar, Abhinandan S
2020-10-27 18:28 4% ` Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2020-10-27 18:19 UTC (permalink / raw)
To: Abhinandan Gujjar, dev, declan.doherty, Honnappa.Nagarahalli,
konstantin.ananyev
Cc: narender.vangati, jerinj
Hi Abhinandan,
> Subject: [v4 1/3] cryptodev: support enqueue callback functions
>
> This patch adds APIs to add/remove callback functions. The callback
> function will be called for each burst of crypto ops received on a
> given crypto device queue pair.
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> config/rte_config.h | 1 +
> lib/librte_cryptodev/meson.build | 2 +-
> lib/librte_cryptodev/rte_cryptodev.c | 230 +++++++++++++++++++++++++
> lib/librte_cryptodev/rte_cryptodev.h | 158 ++++++++++++++++-
> lib/librte_cryptodev/rte_cryptodev_version.map | 2 +
> 5 files changed, 391 insertions(+), 2 deletions(-)
>
> diff --git a/config/rte_config.h b/config/rte_config.h
> index 03d90d7..e999d93 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -61,6 +61,7 @@
> /* cryptodev defines */
> #define RTE_CRYPTO_MAX_DEVS 64
> #define RTE_CRYPTODEV_NAME_LEN 64
> +#define RTE_CRYPTO_CALLBACKS 1
>
> /* compressdev defines */
> #define RTE_COMPRESS_MAX_DEVS 64
> diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
> index c4c6b3b..8c5493f 100644
> --- a/lib/librte_cryptodev/meson.build
> +++ b/lib/librte_cryptodev/meson.build
> @@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
> 'rte_crypto.h',
> 'rte_crypto_sym.h',
> 'rte_crypto_asym.h')
> -deps += ['kvargs', 'mbuf']
> +deps += ['kvargs', 'mbuf', 'rcu']
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index 3d95ac6..0880d9b 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -448,6 +448,91 @@ struct rte_cryptodev_sym_session_pool_private_data
> {
> return 0;
> }
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/* spinlock for crypto device enq callbacks */
> +static rte_spinlock_t rte_cryptodev_callback_lock =
> RTE_SPINLOCK_INITIALIZER;
> +
> +static void
> +cryptodev_cb_cleanup(struct rte_cryptodev *dev)
> +{
> + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> + struct rte_cryptodev_enq_cb_rcu *list;
> + uint16_t qp_id;
> +
> + if (dev->enq_cbs == NULL)
> + return;
> +
> + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> + list = &dev->enq_cbs[qp_id];
> + prev_cb = &list->next;
> +
> + while (*prev_cb != NULL) {
> + curr_cb = *prev_cb;
> + /* Remove the user cb from the callback list. */
> + __atomic_store_n(prev_cb, curr_cb->next,
> + __ATOMIC_RELAXED);
> + rte_rcu_qsbr_synchronize(list->qsbr,
> + RTE_QSBR_THRID_INVALID);
> + rte_free(curr_cb);
> + }
> +
> + rte_free(list->qsbr);
> + }
> +
> + rte_free(dev->enq_cbs);
> + dev->enq_cbs = NULL;
> +}
> +
> +static int
> +cryptodev_cb_init(struct rte_cryptodev *dev)
> +{
> + struct rte_cryptodev_enq_cb_rcu *list;
> + struct rte_rcu_qsbr *qsbr;
> + uint16_t qp_id;
> + size_t size;
> +
> + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> + const uint32_t max_threads = 1;
> +
> + dev->enq_cbs = rte_zmalloc(NULL,
> + sizeof(struct rte_cryptodev_enq_cb_rcu) *
> + dev->data->nb_queue_pairs, 0);
> + if (dev->enq_cbs == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for callbacks");
> + rte_errno = ENOMEM;
> + return -1;
> + }
Why not return ENOMEM here? You are not using rte_errno while returning
from this function, so setting it does not have any meaning.
> +
> + /* Create RCU QSBR variable */
> + size = rte_rcu_qsbr_get_memsize(max_threads);
> +
> + for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
> + list = &dev->enq_cbs[qp_id];
> + qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> + if (qsbr == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for RCU on
> "
> + "queue_pair_id=%d", qp_id);
> + goto cb_init_err;
> + }
> +
> + if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> + CDEV_LOG_ERR("Failed to initialize for RCU on "
> + "queue_pair_id=%d", qp_id);
> + goto cb_init_err;
> + }
> +
> + list->qsbr = qsbr;
> + }
> +
> + return 0;
> +
> +cb_init_err:
> + rte_errno = ENOMEM;
> + cryptodev_cb_cleanup(dev);
> + return -1;
Same here, return -ENOMEM
> +
Extra line
> +}
> +#endif
>
> const char *
> rte_cryptodev_get_feature_name(uint64_t flag)
> @@ -927,6 +1012,11 @@ struct rte_cryptodev *
>
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -
> ENOTSUP);
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + cryptodev_cb_cleanup(dev);
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> +#endif
> /* Setup new number of queue pairs and reconfigure device. */
> diag = rte_cryptodev_queue_pairs_config(dev, config->nb_queue_pairs,
> config->socket_id);
> @@ -936,6 +1026,15 @@ struct rte_cryptodev *
> return diag;
> }
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + diag = cryptodev_cb_init(dev);
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> + if (diag) {
> + CDEV_LOG_ERR("Callback init failed for dev_id=%d", dev_id);
> + return -ENOMEM;
> + }
> +#endif
> rte_cryptodev_trace_configure(dev_id, config);
> return (*dev->dev_ops->dev_configure)(dev, config);
> }
> @@ -1136,6 +1235,137 @@ struct rte_cryptodev *
> socket_id);
> }
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_enq_cb_rcu *list;
> + struct rte_cryptodev_cb *cb, *tail;
> +
> + if (!cb_fn)
> + return NULL;
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + return NULL;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + return NULL;
> + }
Errno is not set before above three returns.
> +
> + cb = rte_zmalloc(NULL, sizeof(*cb), 0);
> + if (cb == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for callback on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> +
> + cb->fn = cb_fn;
> + cb->arg = cb_arg;
> +
> + /* Add the callbacks in fifo order. */
> + list = &dev->enq_cbs[qp_id];
> + tail = list->next;
> +
> + if (tail) {
> + while (tail->next)
> + tail = tail->next;
> + /* Stores to cb->fn and cb->param should complete before
> + * cb is visible to data plane.
> + */
> + __atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
> + } else {
> + /* Stores to cb->fn and cb->param should complete before
> + * cb is visible to data plane.
> + */
> + __atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
> + }
> +
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> +
> + return cb;
> +}
> +
> +int
> +rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> + struct rte_cryptodev_enq_cb_rcu *list;
> + int ret;
> +
> + ret = -EINVAL;
No need to set EINVAL here. You are returning same value everywhere.
The error numbers can be different at each exit.
> +
> + if (!cb) {
> + CDEV_LOG_ERR("cb is NULL");
> + return ret;
You should directly return -EINVAL here and in below cases as well.
> + }
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + return ret;
Here return value should be -ENODEV
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + return ret;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_callback_lock);
> + if (dev->enq_cbs == NULL) {
> + CDEV_LOG_ERR("Callback not initialized");
> + goto cb_err;
> + }
> +
> + list = &dev->enq_cbs[qp_id];
> + if (list == NULL) {
> + CDEV_LOG_ERR("Callback list is NULL");
> + goto cb_err;
> + }
> +
> + if (list->qsbr == NULL) {
> + CDEV_LOG_ERR("Rcu qsbr is NULL");
> + goto cb_err;
> + }
> +
> + prev_cb = &list->next;
> + for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
> + curr_cb = *prev_cb;
> + if (curr_cb == cb) {
> + /* Remove the user cb from the callback list. */
> + __atomic_store_n(prev_cb, curr_cb->next,
> + __ATOMIC_RELAXED);
> + ret = 0;
> + break;
> + }
> + }
> +
> + if (!ret) {
> + /* Call sync with invalid thread id as this is part of
> + * control plane API
> + */
> + rte_rcu_qsbr_synchronize(list->qsbr,
> RTE_QSBR_THRID_INVALID);
> + rte_free(cb);
> + }
> +
> +cb_err:
> + rte_spinlock_unlock(&rte_cryptodev_callback_lock);
> + return ret;
> +}
> +#endif
>
> int
> rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats)
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index 0935fd5..1b7d7ef 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -23,6 +23,7 @@
> #include "rte_dev.h"
> #include <rte_common.h>
> #include <rte_config.h>
> +#include <rte_rcu_qsbr.h>
>
> #include "rte_cryptodev_trace_fp.h"
>
> @@ -522,6 +523,34 @@ struct rte_cryptodev_qp_conf {
> /**< The mempool for creating sess private data in sessionless mode */
> };
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/**
> + * Function type used for pre processing crypto ops when enqueue burst is
> + * called.
> + *
> + * The callback function is called on enqueue burst immediately
> + * before the crypto ops are put onto the hardware queue for processing.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair in which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param ops The address of an array of *nb_ops* pointers
> + * to *rte_crypto_op* structures which contain
> + * the crypto operations to be processed.
> + * @param nb_ops The number of operations to process.
> + * @param user_param The arbitrary user parameter passed in by the
> + * application when the callback was originally
> + * registered.
> + * @return The number of ops to be enqueued to the
> + * crypto device.
> + */
> +typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
> + struct rte_crypto_op **ops, uint16_t nb_ops, void
> *user_param);
> +#endif
> +
> /**
> * Typedef for application callback function to be registered by application
> * software for notification of device events
> @@ -822,7 +851,6 @@ struct rte_cryptodev_config {
> enum rte_cryptodev_event_type event,
> rte_cryptodev_cb_fn cb_fn, void *cb_arg);
>
> -
> typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
> struct rte_crypto_op **ops, uint16_t nb_ops);
> /**< Dequeue processed packets from queue pair of a device. */
> @@ -839,6 +867,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
> /** Structure to keep track of registered callbacks */
> TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/**
> + * @internal
> + * Structure used to hold information about the callbacks to be called for a
> + * queue pair on enqueue.
> + */
> +struct rte_cryptodev_cb {
> + struct rte_cryptodev_cb *next;
> + /** < Pointer to next callback */
> + rte_cryptodev_callback_fn fn;
> + /** < Pointer to callback function */
> + void *arg;
> + /** < Pointer to argument */
> +};
> +
> +/**
> + * @internal
> + * Structure used to hold information about the RCU for a queue pair.
> + */
> +struct rte_cryptodev_enq_cb_rcu {
> + struct rte_cryptodev_cb *next;
> + /** < Pointer to next callback */
> + struct rte_rcu_qsbr *qsbr;
> + /** < RCU QSBR variable per queue pair */
> +};
> +#endif
> +
> /** The data structure associated with each crypto device. */
> struct rte_cryptodev {
> dequeue_pkt_burst_t dequeue_burst;
> @@ -867,6 +922,10 @@ struct rte_cryptodev {
> __extension__
> uint8_t attached : 1;
> /**< Flag indicating the device is attached */
> +
> + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> + /**< User application callback for pre enqueue processing */
> +
Extra line
We should add support for post dequeue callbacks also. Since this is an LTS release
And we wont be very flexible in future quarterly release, we should do all the changes
In one go.
I believe we should also double check with techboard if this is an ABI breakage.
IMO, it is ABI breakage, rte_cryprodevs is part of stable APIs, but not sure.
> } __rte_cache_aligned;
>
> void *
> @@ -989,6 +1048,31 @@ struct rte_cryptodev_data {
> {
> struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> + if (unlikely(dev->enq_cbs != NULL)) {
> + struct rte_cryptodev_enq_cb_rcu *list;
> + struct rte_cryptodev_cb *cb;
> +
> + /* __ATOMIC_RELEASE memory order was used when the
> + * call back was inserted into the list.
> + * Since there is a clear dependency between loading
> + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order
> is
> + * not required.
> + */
> + list = &dev->enq_cbs[qp_id];
> + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> + cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
> +
> + while (cb != NULL) {
> + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> + cb->arg);
> + cb = cb->next;
> + };
> +
> + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> + }
> +#endif
> +
> rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops,
> nb_ops);
> return (*dev->enqueue_burst)(
> dev->data->queue_pairs[qp_id], ops, nb_ops);
> @@ -1730,6 +1814,78 @@ struct rte_crypto_raw_dp_ctx {
> rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
> uint32_t n);
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Add a user callback for a given crypto device and queue pair which will be
> + * called on crypto ops enqueue.
> + *
> + * This API configures a function to be called for each burst of crypto ops
> + * received on a given crypto device queue pair. The return value is a pointer
> + * that can be used later to remove the callback using
> + * rte_cryptodev_remove_enq_callback().
> + *
> + * Multiple functions are called in the order that they are added.
Is there a limit for the number of cbs that can be added? Better to add a
Comment here.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair in which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param cb_fn The callback function
> + * @param cb_arg A generic pointer parameter which will be
> passed
> + * to each invocation of the callback function on
> + * this crypto device and queue pair.
> + *
> + * @return
> + * NULL on error.
> + * On success, a pointer value which can later be used to remove the callback.
> + */
> +
> +__rte_experimental
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg);
> +
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Remove a user callback function for given crypto device and queue pair.
> + *
> + * This function is used to removed callbacks that were added to a crypto
> + * device queue pair using rte_cryptodev_add_enq_callback().
> + *
> + *
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair in which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param cb Pointer to user supplied callback created via
> + * rte_cryptodev_add_enq_callback().
> + *
> + * @return
> + * - 0: Success. Callback was removed.
> + * - -EINVAL: The dev_id or the qp_id is out of range, or the callback
> + * is NULL or not found for the crypto device queue pair.
> + */
> +
> +__rte_experimental
> +int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb);
> +
> +#endif
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map
> b/lib/librte_cryptodev/rte_cryptodev_version.map
> index 7e4360f..5d8d6b0 100644
> --- a/lib/librte_cryptodev/rte_cryptodev_version.map
> +++ b/lib/librte_cryptodev/rte_cryptodev_version.map
> @@ -101,6 +101,7 @@ EXPERIMENTAL {
> rte_cryptodev_get_qp_status;
>
> # added in 20.11
> + rte_cryptodev_add_enq_callback;
> rte_cryptodev_configure_raw_dp_ctx;
> rte_cryptodev_get_raw_dp_ctx_size;
> rte_cryptodev_raw_dequeue;
> @@ -109,4 +110,5 @@ EXPERIMENTAL {
> rte_cryptodev_raw_enqueue;
> rte_cryptodev_raw_enqueue_burst;
> rte_cryptodev_raw_enqueue_done;
> + rte_cryptodev_remove_enq_callback;
> };
> --
> 1.9.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate ABI version
2020-10-19 9:41 9% ` [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate " David Marchand
@ 2020-10-27 12:13 4% ` David Marchand
2020-11-01 14:48 4% ` Thomas Monjalon
2020-11-01 15:09 4% ` Raslan Darawsheh
2 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-10-27 12:13 UTC (permalink / raw)
To: Thomas Monjalon, Matan Azrad, Shahaf Shuler, Raslan Darawsheh
Cc: Viacheslav Ovsiienko, dev
On Mon, Oct 19, 2020 at 11:42 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> The glue libraries are tightly bound to the mlx drivers of a dpdk version
> and are packaged with them.
>
> Keeping a separate ABI version prevents us from installing two versions of
> dpdk.
> Maintaining this separate version just adds confusion.
> Align the glue library ABI version to the global ABI version.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Review?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] doc: update abi version references
2020-10-26 19:31 33% ` [dpdk-dev] [PATCH v3] " Ray Kinsella
@ 2020-10-27 11:40 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-10-27 11:40 UTC (permalink / raw)
To: Ray Kinsella; +Cc: Neil Horman, Thomas Monjalon, Mcnamara, John, dev
On Mon, Oct 26, 2020 at 8:35 PM Ray Kinsella <mdr@ashroe.eu> wrote:
>
> Updated references to abi versions in the contributors guide.
> Fixed an inaccurate reference to a symbol in the policy.
>
> Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
Applied, thanks Ray.
--
David Marchand
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] doc: update abi version references
2020-10-23 16:07 33% [dpdk-dev] [PATCH v1] doc: update abi version references Ray Kinsella
2020-10-23 16:51 7% ` David Marchand
2020-10-26 19:23 33% ` [dpdk-dev] [PATCH] " Ray Kinsella
@ 2020-10-26 19:31 33% ` Ray Kinsella
2020-10-27 11:40 4% ` David Marchand
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2020-10-26 19:31 UTC (permalink / raw)
To: Ray Kinsella, Neil Horman; +Cc: thomas, david.marchand, john.mcnamara, dev
Updated references to abi versions in the contributors guide.
Fixed an inaccurate reference to a symbol in the policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/contributing/abi_policy.rst | 56 +++++-----
doc/guides/contributing/abi_versioning.rst | 120 ++++++++++-----------
2 files changed, 88 insertions(+), 88 deletions(-)
---
* v2 -> v3: Missed the version prepend on the v2.
* v1 -> v2: Fixed references to 19.11, and a typo in the policy
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index e17758a107..4ad87dbfed 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -78,15 +78,15 @@ The DPDK ABI policy
-------------------
A new major ABI version is declared no more frequently than yearly, with
-declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
+declarations usually aligning with a LTS release, e.g. ABI 21 for DPDK 20.11.
Compatibility with the major ABI version is then mandatory in subsequent
-releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
-20.11.
+releases until the next major ABI version is declared, e.g. ABI 22 for DPDK
+21.11.
At the declaration of a major ABI version, major version numbers encoded in
libraries' sonames are bumped to indicate the new version, with the minor
-version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
-``librte_eal.so.21.0``.
+version reset to ``0``. An example would be ``librte_eal.so.21.3`` would become
+``librte_eal.so.22.0``.
The ABI may then change multiple times, without warning, between the last major
ABI version increment and the HEAD label of the git tree, with the condition
@@ -95,8 +95,8 @@ sonames do not change.
Minor versions are incremented to indicate the release of a new ABI compatible
DPDK release, typically the DPDK quarterly releases. An example of this, might
-be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
-release, following the declaration of the new major ABI version ``20``.
+be that ``librte_eal.so.21.1`` would indicate the first ABI compatible DPDK
+release, following the declaration of the new major ABI version ``21``.
An ABI version is supported in all new releases until the next major ABI version
is declared. When changing the major ABI version, the release notes will detail
@@ -222,11 +222,11 @@ Examples of ABI Changes
The following are examples of allowable ABI changes occurring between
declarations of major ABI versions.
-* DPDK 19.11 release defines the function ``rte_foo()`` ; ``rte_foo()``
- is part of the major ABI version ``20``.
+* DPDK 20.11 release defines the function ``rte_foo()`` ; ``rte_foo()``
+ is part of the major ABI version ``21``.
-* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``.
- This is not a problem as long as the symbol ``rte_foo@DPDK20`` is
+* DPDK 21.02 release defines a new function ``rte_foo(uint8_t bar)``.
+ This is not a problem as long as the symbol ``rte_foo@DPDK_21`` is
preserved through :ref:`abi_versioning`.
- The new function may be marked with the ``__rte_experimental`` tag for a
@@ -235,21 +235,21 @@ declarations of major ABI versions.
- Once ``rte_foo(uint8_t bar)`` becomes non-experimental, ``rte_foo()`` is
declared as ``__rte_deprecated`` and an deprecation notice is provided.
-* DPDK 19.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
- version of ``rte_foo`` only exists from DPDK 20.02 onwards as described in the
+* DPDK 20.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
+ version of ``rte_foo`` only exists from DPDK 21.02 onwards as described in the
:ref:`note on forward-only compatibility<forward-only>`.
-* DPDK 20.02 release defines the experimental function ``__rte_experimental
- rte_baz()``. This function may or may not exist in the DPDK 20.05 release.
+* DPDK 21.02 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in the DPDK 21.05 release.
* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
- declaration of the DPDK ``21`` major ABI version. The application can only
- ensure its runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ declaration of the DPDK ``22`` major ABI version. The application can only
+ ensure its runtime dependencies are met by specifying ``DPDK (>= 21.2)`` as
an explicit package dependency, as the soname can only indicate the
supported major ABI version.
-* At the release of DPDK 20.11, the function ``rte_foo(uint8_t bar)`` becomes
- formally part of then new major ABI version DPDK ``21`` and ``rte_foo()`` may be
+* At the release of DPDK 21.11, the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of then new major ABI version DPDK ``22`` and ``rte_foo()`` may be
removed.
.. _deprecation_notices:
@@ -261,25 +261,25 @@ The following are some examples of ABI deprecation notices which would be
added to the Release Notes:
* The Macro ``#RTE_FOO`` is deprecated and will be removed with ABI version
- 21, to be replaced with the inline function ``rte_foo()``.
+ 22, to be replaced with the inline function ``rte_foo()``.
* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 20.2. Backwards compatibility will be maintained for this function
- until the release of the new DPDK major ABI version 21, in DPDK version
- 20.11.
+ in version 21.2. Backwards compatibility will be maintained for this function
+ until the release of the new DPDK major ABI version 22, in DPDK version
+ 21.11.
-* The members of ``struct rte_foo`` have been reorganized in DPDK 20.02 for
+* The members of ``struct rte_foo`` have been reorganized in DPDK 21.02 for
performance reasons. Existing binary applications will have backwards
- compatibility in release 20.02, while newly built binaries will need to
+ compatibility in release 21.02, while newly built binaries will need to
reference the new structure variant ``struct rte_foo2``. Compatibility will be
- removed in release 20.11, and all applications will require updating and
+ removed in release 21.11, and all applications will require updating and
rebuilding to the new structure at that time, which will be renamed to the
original ``struct rte_foo``.
* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 20.02 will not contain these changes, but release 20.11 will,
+ upcoming release 21.02 will not contain these changes, but release 21.11 will,
and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to ABI version 21 will
+ these changes. Binaries using this library built prior to ABI version 22 will
require updating and recompilation.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index b8b35761e2..91ada18dd7 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -14,22 +14,22 @@ What is a library's soname?
---------------------------
System libraries usually adopt the familiar major and minor version naming
-convention, where major versions (e.g. ``librte_eal 20.x, 21.x``) are presumed
+convention, where major versions (e.g. ``librte_eal 21.x, 22.x``) are presumed
to be ABI incompatible with each other and minor versions (e.g. ``librte_eal
-20.1, 20.2``) are presumed to be ABI compatible. A library's `soname
+21.1, 21.2``) are presumed to be ABI compatible. A library's `soname
<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
compatibility information about a given library, describing the lowest common
denominator ABI supported by the library. The soname or logical name for the
library, is typically comprised of the library's name and major version e.g.
-``librte_eal.so.20``.
+``librte_eal.so.21``.
During an application's build process, a library's soname is noted as a runtime
dependency of the application. This information is then used by the `dynamic
linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
applications dependencies at runtime, to load a library supporting the correct
ABI version. The library loaded at runtime therefore, may be a minor revision
-supporting the same major ABI version (e.g. ``librte_eal.20.2``), as the library
-used to link the application (e.g ``librte_eal.20.0``).
+supporting the same major ABI version (e.g. ``librte_eal.21.2``), as the library
+used to link the application (e.g ``librte_eal.21.0``).
.. _major_abi_versions:
@@ -59,41 +59,41 @@ persists over multiple releases.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
$ head ./lib/librte_eal/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
When an ABI change is made between major ABI versions to a given library, a new
section is added to that library's version map describing the impending new ABI
version, as described in the section :ref:`example_abi_macro_usage`. The
-library's soname and filename however do not change, e.g. ``libacl.so.20``, as
+library's soname and filename however do not change, e.g. ``libacl.so.21``, as
ABI compatibility with the last major ABI version continues to be preserved for
that library.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
- DPDK_21 {
+ DPDK_22 {
global:
- } DPDK_20;
+ } DPDK_21;
...
$ head ./lib/librte_eal/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
-However when a new ABI version is declared, for example DPDK ``21``, old
+However when a new ABI version is declared, for example DPDK ``22``, old
depreciated functions may be safely removed at this point and the entire old
major ABI version removed, see the section :ref:`deprecating_entire_abi` on
how this may be done.
@@ -101,12 +101,12 @@ how this may be done.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_21 {
+ DPDK_22 {
global:
...
$ head ./lib/librte_eal/version.map
- DPDK_21 {
+ DPDK_22 {
global:
...
@@ -216,7 +216,7 @@ library looks like this
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -242,7 +242,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -264,15 +264,15 @@ This file needs to be modified as follows
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
The addition of the new block tells the linker that a new version node
-``DPDK_21`` is available, which contains the symbol rte_acl_create, and inherits
-the symbols from the DPDK_20 node. This list is directly translated into a
+``DPDK_22`` is available, which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_21 node. This list is directly translated into a
list of exported symbols when DPDK is compiled as a shared library.
Next, we need to specify in the code which function maps to the rte_acl_create
@@ -285,7 +285,7 @@ with the public symbol name
-struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param)
+struct rte_acl_ctx * __vsym
- +rte_acl_create_v20(const struct rte_acl_param *param)
+ +rte_acl_create_v21(const struct rte_acl_param *param)
{
size_t sz;
struct rte_acl_ctx *ctx;
@@ -294,7 +294,7 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols and we have annotated the function as
``__vsym``, an implementation of a versioned symbol . That is our next step,
-mapping this new symbol name to the initial symbol name at version node 20.
+mapping this new symbol name to the initial symbol name at version node 21.
Immediately after the function, we add the VERSION_SYMBOL macro.
.. code-block:: c
@@ -302,26 +302,26 @@ Immediately after the function, we add the VERSION_SYMBOL macro.
#include <rte_function_versioning.h>
...
- VERSION_SYMBOL(rte_acl_create, _v20, 20);
+ VERSION_SYMBOL(rte_acl_create, _v21, 21);
Remembering to also add the rte_function_versioning.h header to the requisite c
file where these changes are being made. The macro instructs the linker to
-create a new symbol ``rte_acl_create@DPDK_20``, which matches the symbol created
+create a new symbol ``rte_acl_create@DPDK_21``, which matches the symbol created
in older builds, but now points to the above newly named function. We have now
mapped the original rte_acl_create symbol to the original function (but with a
new name).
Please see the section :ref:`Enabling versioning macros
<enabling_versioning_macros>` to enable this macro in the meson/ninja build.
-Next, we need to create the new ``v21`` version of the symbol. We create a new
-function name, with the ``v21`` suffix, and implement it appropriately.
+Next, we need to create the new ``v22`` version of the symbol. We create a new
+function name, with the ``v22`` suffix, and implement it appropriately.
.. code-block:: c
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug);
{
- struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
+ struct rte_acl_ctx *ctx = rte_acl_create_v21(param);
ctx->debug = debug;
@@ -330,7 +330,7 @@ function name, with the ``v21`` suffix, and implement it appropriately.
This code serves as our new API call. Its the same as our old call, but adds the
new parameter in place. Next we need to map this function to the new default
-symbol ``rte_acl_create@DPDK_21``. To do this, immediately after the function,
+symbol ``rte_acl_create@DPDK_22``. To do this, immediately after the function,
we add the BIND_DEFAULT_SYMBOL macro.
.. code-block:: c
@@ -338,10 +338,10 @@ we add the BIND_DEFAULT_SYMBOL macro.
#include <rte_function_versioning.h>
...
- BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
The macro instructs the linker to create the new default symbol
-``rte_acl_create@DPDK_21``, which points to the above newly named function.
+``rte_acl_create@DPDK_22``, which points to the above newly named function.
We finally modify the prototype of the call in the public header file,
such that it contains both versions of the symbol and the public API.
@@ -352,15 +352,15 @@ such that it contains both versions of the symbol and the public API.
rte_acl_create(const struct rte_acl_param *param);
struct rte_acl_ctx * __vsym
- rte_acl_create_v20(const struct rte_acl_param *param);
+ rte_acl_create_v21(const struct rte_acl_param *param);
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug);
And that's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_20 version, used by previously built applications,
-and a new DPDK_21 version, used by future built applications.
+rte_acl_create, an old DPDK_21 version, used by previously built applications,
+and a new DPDK_22 version, used by future built applications.
.. note::
@@ -385,21 +385,21 @@ this code in a position of no longer having a symbol simply named
To correct this, we can simply map a function of our choosing back to the public
symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
assumption is that the most recent version of the symbol is the one you want to
-map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
+map. So, back in the C file where, immediately after ``rte_acl_create_v22`` is
defined, we add this
.. code-block:: c
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug)
{
...
}
- MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v22);
That tells the compiler that, when building a static library, any calls to the
-symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
+symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v22``
.. _enabling_versioning_macros:
@@ -456,7 +456,7 @@ version node.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
@@ -486,22 +486,22 @@ When we promote the symbol to the stable ABI, we simply strip the
}
We then update the map file, adding the symbol ``rte_acl_create``
-to the ``DPDK_21`` version node.
+to the ``DPDK_22`` version node.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
Although there are strictly no guarantees or commitments associated with
@@ -509,7 +509,7 @@ Although there are strictly no guarantees or commitments associated with
an alias to experimental. The process to add an alias to experimental,
is similar to the symbol versioning process. Assuming we have an experimental
symbol as before, we now add the symbol to both the ``EXPERIMENTAL``
-and ``DPDK_21`` version nodes.
+and ``DPDK_22`` version nodes.
.. code-block:: c
@@ -535,29 +535,29 @@ and ``DPDK_21`` version nodes.
VERSION_SYMBOL_EXPERIMENTAL(rte_acl_create, _e);
struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param)
+ rte_acl_create_v22(const struct rte_acl_param *param)
{
return rte_acl_create(param);
}
- BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
In the map file, we map the symbol to both the ``EXPERIMENTAL``
-and ``DPDK_21`` version nodes.
+and ``DPDK_22`` version nodes.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
EXPERIMENTAL {
global:
@@ -585,7 +585,7 @@ file:
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -607,21 +607,21 @@ file:
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
Next remove the corresponding versioned export.
.. code-block:: c
- -VERSION_SYMBOL(rte_acl_create, _v20, 20);
+ -VERSION_SYMBOL(rte_acl_create, _v21, 21);
Note that the internal function definition could also be removed, but its used
-in our example by the newer version ``v21``, so we leave it in place and declare
+in our example by the newer version ``v22``, so we leave it in place and declare
it as static. This is a coding style choice.
.. _deprecating_entire_abi:
@@ -642,7 +642,7 @@ In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_add_rules;
@@ -670,8 +670,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
Lastly, any VERSION_SYMBOL macros that point to the old version nodes
should be removed, taking care to preserve any code that is shared
--
2.23.0
^ permalink raw reply [relevance 33%]
* [dpdk-dev] [PATCH] doc: update abi version references
2020-10-23 16:07 33% [dpdk-dev] [PATCH v1] doc: update abi version references Ray Kinsella
2020-10-23 16:51 7% ` David Marchand
@ 2020-10-26 19:23 33% ` Ray Kinsella
2020-10-26 19:31 33% ` [dpdk-dev] [PATCH v3] " Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2020-10-26 19:23 UTC (permalink / raw)
To: Ray Kinsella, Neil Horman; +Cc: thomas, david.marchand, john.mcnamara, dev
Updated references to abi versions in the contributors guide.
Fixed an inaccurate reference to a symbol in the policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/contributing/abi_policy.rst | 56 +++++-----
doc/guides/contributing/abi_versioning.rst | 120 ++++++++++-----------
2 files changed, 88 insertions(+), 88 deletions(-)
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index e17758a107..4ad87dbfed 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -78,15 +78,15 @@ The DPDK ABI policy
-------------------
A new major ABI version is declared no more frequently than yearly, with
-declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
+declarations usually aligning with a LTS release, e.g. ABI 21 for DPDK 20.11.
Compatibility with the major ABI version is then mandatory in subsequent
-releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
-20.11.
+releases until the next major ABI version is declared, e.g. ABI 22 for DPDK
+21.11.
At the declaration of a major ABI version, major version numbers encoded in
libraries' sonames are bumped to indicate the new version, with the minor
-version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
-``librte_eal.so.21.0``.
+version reset to ``0``. An example would be ``librte_eal.so.21.3`` would become
+``librte_eal.so.22.0``.
The ABI may then change multiple times, without warning, between the last major
ABI version increment and the HEAD label of the git tree, with the condition
@@ -95,8 +95,8 @@ sonames do not change.
Minor versions are incremented to indicate the release of a new ABI compatible
DPDK release, typically the DPDK quarterly releases. An example of this, might
-be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
-release, following the declaration of the new major ABI version ``20``.
+be that ``librte_eal.so.21.1`` would indicate the first ABI compatible DPDK
+release, following the declaration of the new major ABI version ``21``.
An ABI version is supported in all new releases until the next major ABI version
is declared. When changing the major ABI version, the release notes will detail
@@ -222,11 +222,11 @@ Examples of ABI Changes
The following are examples of allowable ABI changes occurring between
declarations of major ABI versions.
-* DPDK 19.11 release defines the function ``rte_foo()`` ; ``rte_foo()``
- is part of the major ABI version ``20``.
+* DPDK 20.11 release defines the function ``rte_foo()`` ; ``rte_foo()``
+ is part of the major ABI version ``21``.
-* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``.
- This is not a problem as long as the symbol ``rte_foo@DPDK20`` is
+* DPDK 21.02 release defines a new function ``rte_foo(uint8_t bar)``.
+ This is not a problem as long as the symbol ``rte_foo@DPDK_21`` is
preserved through :ref:`abi_versioning`.
- The new function may be marked with the ``__rte_experimental`` tag for a
@@ -235,21 +235,21 @@ declarations of major ABI versions.
- Once ``rte_foo(uint8_t bar)`` becomes non-experimental, ``rte_foo()`` is
declared as ``__rte_deprecated`` and an deprecation notice is provided.
-* DPDK 19.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
- version of ``rte_foo`` only exists from DPDK 20.02 onwards as described in the
+* DPDK 20.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
+ version of ``rte_foo`` only exists from DPDK 21.02 onwards as described in the
:ref:`note on forward-only compatibility<forward-only>`.
-* DPDK 20.02 release defines the experimental function ``__rte_experimental
- rte_baz()``. This function may or may not exist in the DPDK 20.05 release.
+* DPDK 21.02 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in the DPDK 21.05 release.
* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
- declaration of the DPDK ``21`` major ABI version. The application can only
- ensure its runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ declaration of the DPDK ``22`` major ABI version. The application can only
+ ensure its runtime dependencies are met by specifying ``DPDK (>= 21.2)`` as
an explicit package dependency, as the soname can only indicate the
supported major ABI version.
-* At the release of DPDK 20.11, the function ``rte_foo(uint8_t bar)`` becomes
- formally part of then new major ABI version DPDK ``21`` and ``rte_foo()`` may be
+* At the release of DPDK 21.11, the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of then new major ABI version DPDK ``22`` and ``rte_foo()`` may be
removed.
.. _deprecation_notices:
@@ -261,25 +261,25 @@ The following are some examples of ABI deprecation notices which would be
added to the Release Notes:
* The Macro ``#RTE_FOO`` is deprecated and will be removed with ABI version
- 21, to be replaced with the inline function ``rte_foo()``.
+ 22, to be replaced with the inline function ``rte_foo()``.
* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 20.2. Backwards compatibility will be maintained for this function
- until the release of the new DPDK major ABI version 21, in DPDK version
- 20.11.
+ in version 21.2. Backwards compatibility will be maintained for this function
+ until the release of the new DPDK major ABI version 22, in DPDK version
+ 21.11.
-* The members of ``struct rte_foo`` have been reorganized in DPDK 20.02 for
+* The members of ``struct rte_foo`` have been reorganized in DPDK 21.02 for
performance reasons. Existing binary applications will have backwards
- compatibility in release 20.02, while newly built binaries will need to
+ compatibility in release 21.02, while newly built binaries will need to
reference the new structure variant ``struct rte_foo2``. Compatibility will be
- removed in release 20.11, and all applications will require updating and
+ removed in release 21.11, and all applications will require updating and
rebuilding to the new structure at that time, which will be renamed to the
original ``struct rte_foo``.
* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 20.02 will not contain these changes, but release 20.11 will,
+ upcoming release 21.02 will not contain these changes, but release 21.11 will,
and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to ABI version 21 will
+ these changes. Binaries using this library built prior to ABI version 22 will
require updating and recompilation.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index b8b35761e2..91ada18dd7 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -14,22 +14,22 @@ What is a library's soname?
---------------------------
System libraries usually adopt the familiar major and minor version naming
-convention, where major versions (e.g. ``librte_eal 20.x, 21.x``) are presumed
+convention, where major versions (e.g. ``librte_eal 21.x, 22.x``) are presumed
to be ABI incompatible with each other and minor versions (e.g. ``librte_eal
-20.1, 20.2``) are presumed to be ABI compatible. A library's `soname
+21.1, 21.2``) are presumed to be ABI compatible. A library's `soname
<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
compatibility information about a given library, describing the lowest common
denominator ABI supported by the library. The soname or logical name for the
library, is typically comprised of the library's name and major version e.g.
-``librte_eal.so.20``.
+``librte_eal.so.21``.
During an application's build process, a library's soname is noted as a runtime
dependency of the application. This information is then used by the `dynamic
linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
applications dependencies at runtime, to load a library supporting the correct
ABI version. The library loaded at runtime therefore, may be a minor revision
-supporting the same major ABI version (e.g. ``librte_eal.20.2``), as the library
-used to link the application (e.g ``librte_eal.20.0``).
+supporting the same major ABI version (e.g. ``librte_eal.21.2``), as the library
+used to link the application (e.g ``librte_eal.21.0``).
.. _major_abi_versions:
@@ -59,41 +59,41 @@ persists over multiple releases.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
$ head ./lib/librte_eal/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
When an ABI change is made between major ABI versions to a given library, a new
section is added to that library's version map describing the impending new ABI
version, as described in the section :ref:`example_abi_macro_usage`. The
-library's soname and filename however do not change, e.g. ``libacl.so.20``, as
+library's soname and filename however do not change, e.g. ``libacl.so.21``, as
ABI compatibility with the last major ABI version continues to be preserved for
that library.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
- DPDK_21 {
+ DPDK_22 {
global:
- } DPDK_20;
+ } DPDK_21;
...
$ head ./lib/librte_eal/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
-However when a new ABI version is declared, for example DPDK ``21``, old
+However when a new ABI version is declared, for example DPDK ``22``, old
depreciated functions may be safely removed at this point and the entire old
major ABI version removed, see the section :ref:`deprecating_entire_abi` on
how this may be done.
@@ -101,12 +101,12 @@ how this may be done.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_21 {
+ DPDK_22 {
global:
...
$ head ./lib/librte_eal/version.map
- DPDK_21 {
+ DPDK_22 {
global:
...
@@ -216,7 +216,7 @@ library looks like this
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -242,7 +242,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -264,15 +264,15 @@ This file needs to be modified as follows
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
The addition of the new block tells the linker that a new version node
-``DPDK_21`` is available, which contains the symbol rte_acl_create, and inherits
-the symbols from the DPDK_20 node. This list is directly translated into a
+``DPDK_22`` is available, which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_21 node. This list is directly translated into a
list of exported symbols when DPDK is compiled as a shared library.
Next, we need to specify in the code which function maps to the rte_acl_create
@@ -285,7 +285,7 @@ with the public symbol name
-struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param)
+struct rte_acl_ctx * __vsym
- +rte_acl_create_v20(const struct rte_acl_param *param)
+ +rte_acl_create_v21(const struct rte_acl_param *param)
{
size_t sz;
struct rte_acl_ctx *ctx;
@@ -294,7 +294,7 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols and we have annotated the function as
``__vsym``, an implementation of a versioned symbol . That is our next step,
-mapping this new symbol name to the initial symbol name at version node 20.
+mapping this new symbol name to the initial symbol name at version node 21.
Immediately after the function, we add the VERSION_SYMBOL macro.
.. code-block:: c
@@ -302,26 +302,26 @@ Immediately after the function, we add the VERSION_SYMBOL macro.
#include <rte_function_versioning.h>
...
- VERSION_SYMBOL(rte_acl_create, _v20, 20);
+ VERSION_SYMBOL(rte_acl_create, _v21, 21);
Remembering to also add the rte_function_versioning.h header to the requisite c
file where these changes are being made. The macro instructs the linker to
-create a new symbol ``rte_acl_create@DPDK_20``, which matches the symbol created
+create a new symbol ``rte_acl_create@DPDK_21``, which matches the symbol created
in older builds, but now points to the above newly named function. We have now
mapped the original rte_acl_create symbol to the original function (but with a
new name).
Please see the section :ref:`Enabling versioning macros
<enabling_versioning_macros>` to enable this macro in the meson/ninja build.
-Next, we need to create the new ``v21`` version of the symbol. We create a new
-function name, with the ``v21`` suffix, and implement it appropriately.
+Next, we need to create the new ``v22`` version of the symbol. We create a new
+function name, with the ``v22`` suffix, and implement it appropriately.
.. code-block:: c
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug);
{
- struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
+ struct rte_acl_ctx *ctx = rte_acl_create_v21(param);
ctx->debug = debug;
@@ -330,7 +330,7 @@ function name, with the ``v21`` suffix, and implement it appropriately.
This code serves as our new API call. Its the same as our old call, but adds the
new parameter in place. Next we need to map this function to the new default
-symbol ``rte_acl_create@DPDK_21``. To do this, immediately after the function,
+symbol ``rte_acl_create@DPDK_22``. To do this, immediately after the function,
we add the BIND_DEFAULT_SYMBOL macro.
.. code-block:: c
@@ -338,10 +338,10 @@ we add the BIND_DEFAULT_SYMBOL macro.
#include <rte_function_versioning.h>
...
- BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
The macro instructs the linker to create the new default symbol
-``rte_acl_create@DPDK_21``, which points to the above newly named function.
+``rte_acl_create@DPDK_22``, which points to the above newly named function.
We finally modify the prototype of the call in the public header file,
such that it contains both versions of the symbol and the public API.
@@ -352,15 +352,15 @@ such that it contains both versions of the symbol and the public API.
rte_acl_create(const struct rte_acl_param *param);
struct rte_acl_ctx * __vsym
- rte_acl_create_v20(const struct rte_acl_param *param);
+ rte_acl_create_v21(const struct rte_acl_param *param);
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug);
And that's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_20 version, used by previously built applications,
-and a new DPDK_21 version, used by future built applications.
+rte_acl_create, an old DPDK_21 version, used by previously built applications,
+and a new DPDK_22 version, used by future built applications.
.. note::
@@ -385,21 +385,21 @@ this code in a position of no longer having a symbol simply named
To correct this, we can simply map a function of our choosing back to the public
symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
assumption is that the most recent version of the symbol is the one you want to
-map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
+map. So, back in the C file where, immediately after ``rte_acl_create_v22`` is
defined, we add this
.. code-block:: c
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug)
{
...
}
- MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v22);
That tells the compiler that, when building a static library, any calls to the
-symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
+symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v22``
.. _enabling_versioning_macros:
@@ -456,7 +456,7 @@ version node.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
@@ -486,22 +486,22 @@ When we promote the symbol to the stable ABI, we simply strip the
}
We then update the map file, adding the symbol ``rte_acl_create``
-to the ``DPDK_21`` version node.
+to the ``DPDK_22`` version node.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
Although there are strictly no guarantees or commitments associated with
@@ -509,7 +509,7 @@ Although there are strictly no guarantees or commitments associated with
an alias to experimental. The process to add an alias to experimental,
is similar to the symbol versioning process. Assuming we have an experimental
symbol as before, we now add the symbol to both the ``EXPERIMENTAL``
-and ``DPDK_21`` version nodes.
+and ``DPDK_22`` version nodes.
.. code-block:: c
@@ -535,29 +535,29 @@ and ``DPDK_21`` version nodes.
VERSION_SYMBOL_EXPERIMENTAL(rte_acl_create, _e);
struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param)
+ rte_acl_create_v22(const struct rte_acl_param *param)
{
return rte_acl_create(param);
}
- BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
In the map file, we map the symbol to both the ``EXPERIMENTAL``
-and ``DPDK_21`` version nodes.
+and ``DPDK_22`` version nodes.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
EXPERIMENTAL {
global:
@@ -585,7 +585,7 @@ file:
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -607,21 +607,21 @@ file:
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
Next remove the corresponding versioned export.
.. code-block:: c
- -VERSION_SYMBOL(rte_acl_create, _v20, 20);
+ -VERSION_SYMBOL(rte_acl_create, _v21, 21);
Note that the internal function definition could also be removed, but its used
-in our example by the newer version ``v21``, so we leave it in place and declare
+in our example by the newer version ``v22``, so we leave it in place and declare
it as static. This is a coding style choice.
.. _deprecating_entire_abi:
@@ -642,7 +642,7 @@ In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_add_rules;
@@ -670,8 +670,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
Lastly, any VERSION_SYMBOL macros that point to the old version nodes
should be removed, taking care to preserve any code that is shared
--
2.23.0
^ permalink raw reply [relevance 33%]
* Re: [dpdk-dev] [PATCH v1] doc: update abi version references
2020-10-23 16:51 7% ` David Marchand
@ 2020-10-26 18:27 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-26 18:27 UTC (permalink / raw)
To: David Marchand; +Cc: Neil Horman, Mcnamara, John, Thomas Monjalon, dev
Good catch :-).
On 23/10/2020 17:51, David Marchand wrote:
> On Fri, Oct 23, 2020 at 6:11 PM Ray Kinsella <mdr@ashroe.eu> wrote:
>>
>> Updated references to abi versions in the contributors guide.
>
> Thanks for looking at it.
>
> I would keep the dpdk release version aligned with updated ABI ver.
> Caught 3 references in the first file.
>
> %s/19.11/20.11/g can fix this.
>
> Then:
> Reviewed-by: David Marchand <david.marchand@redhat.com>
>
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to
@ 2020-10-26 6:47 3% yang_y_yi
2020-10-27 19:55 0% ` Ananyev, Konstantin
2020-10-28 0:51 0% ` Hu, Jiayu
0 siblings, 2 replies; 200+ results
From: yang_y_yi @ 2020-10-26 6:47 UTC (permalink / raw)
To: dev; +Cc: jiayu.hu, konstantin.ananyev, techboard, thomas, yangyi01, yang_y_yi
From: Yi Yang <yangyi01@inspur.com>
rte_gso_segment decreased refcnt of pkt by one, but
it is wrong if pkt is external mbuf, pkt won't be
freed because of incorrect refcnt, the result is
application can't allocate mbuf from mempool because
mbufs in mempool are run out of.
One correct way is application should call
rte_pktmbuf_free after calling rte_gso_segment to free
pkt explicitly. rte_gso_segment mustn't handle it, this
should be responsibility of application.
This commit changed rte_gso_segment in functional behavior
and return value, so the application must take appropriate
actions according to return values, "ret < 0" means it
should free and drop 'pkt', "ret == 0" means 'pkt' isn't
GSOed but 'pkt' can be transimmitted as a normal packet,
"ret > 0" means 'pkt' has been GSOed into two or multiple
segments, it should use "pkts_out" to transmit these
segments. The application must free 'pkt' after call
rte_gso_segment when return value isn't equal to 0.
Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO")
Signed-off-by: Yi Yang <yangyi01@inspur.com>
---
Changelog:
v2->v3:
- add release notes to emphasize behavior and return
value changes of rte_gso_segment().
- update return value description of rte_gso_segment().
- modify related code to adapt to the changes.
v1->v2:
- update description of rte_gso_segment().
- change code which calls rte_gso_segment() to
fix free issue.
---
app/test-pmd/csumonly.c | 12 ++++++++++--
.../prog_guide/generic_segmentation_offload_lib.rst | 7 +++++--
doc/guides/rel_notes/release_20_11.rst | 7 +++++++
drivers/net/tap/rte_eth_tap.c | 12 ++++++++++--
lib/librte_gso/gso_tcp4.c | 6 ++----
lib/librte_gso/gso_tunnel_tcp4.c | 14 +++++---------
lib/librte_gso/gso_udp4.c | 6 ++----
lib/librte_gso/rte_gso.c | 15 +++------------
lib/librte_gso/rte_gso.h | 8 ++++++--
9 files changed, 50 insertions(+), 37 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 3d7d244..d813d4f 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -1080,9 +1080,17 @@ struct simple_gre_hdr {
ret = rte_gso_segment(pkts_burst[i], gso_ctx,
&gso_segments[nb_segments],
GSO_MAX_PKT_BURST - nb_segments);
- if (ret >= 0)
+ if (ret >= 1) {
+ /* pkts_burst[i] can be freed safely here. */
+ rte_pktmbuf_free(pkts_burst[i]);
nb_segments += ret;
- else {
+ } else if (ret == 0) {
+ /* 0 means it can be transmitted directly
+ * without gso.
+ */
+ gso_segments[nb_segments] = pkts_burst[i];
+ nb_segments += 1;
+ } else {
TESTPMD_LOG(DEBUG, "Unable to segment packet");
rte_pktmbuf_free(pkts_burst[i]);
}
diff --git a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
index 205cb8a..8577572 100644
--- a/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
+++ b/doc/guides/prog_guide/generic_segmentation_offload_lib.rst
@@ -25,8 +25,9 @@ Bearing that in mind, the GSO library enables DPDK applications to segment
packets in software. Note however, that GSO is implemented as a standalone
library, and not via a 'fallback' mechanism (i.e. for when TSO is unsupported
in the underlying hardware); that is, applications must explicitly invoke the
-GSO library to segment packets. The size of GSO segments ``(segsz)`` is
-configurable by the application.
+GSO library to segment packets, they also must call ``rte_pktmbuf_free()`` to
+free mbuf GSO segments attach to after calling ``rte_gso_segment()``. The size
+of GSO segments ``(segsz)`` is configurable by the application.
Limitations
-----------
@@ -233,6 +234,8 @@ To segment an outgoing packet, an application must:
#. Invoke the GSO segmentation API, ``rte_gso_segment()``.
+#. Call ``rte_pktmbuf_free()`` to free mbuf ``rte_gso_segment()`` segments.
+
#. If required, update the L3 and L4 checksums of the newly-created segments.
For tunneled packets, the outer IPv4 headers' checksums should also be
updated. Alternatively, the application may offload checksum calculation
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index d8ac359..da77396 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -543,6 +543,13 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* **Changed ``rte_gso_segment`` in functional behavior and return value.**
+
+ * Don't save pkt to pkts_out[0] if it isn't GSOed in case of ret == 1.
+ * Return 0 instead of 1 for the above case.
+ * ``rte_gso_segment`` won't free pkt no matter whether it is GSOed, the
+ application has responsibility to free it after call ``rte_gso_segment``.
+
ABI Changes
-----------
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 81c6884..2f8abb1 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -751,8 +751,16 @@ struct ipc_queues {
if (num_tso_mbufs < 0)
break;
- mbuf = gso_mbufs;
- num_mbufs = num_tso_mbufs;
+ if (num_tso_mbufs >= 1) {
+ mbuf = gso_mbufs;
+ num_mbufs = num_tso_mbufs;
+ } else {
+ /* 0 means it can be transmitted directly
+ * without gso.
+ */
+ mbuf = &mbuf_in;
+ num_mbufs = 1;
+ }
} else {
/* stats.errs will be incremented */
if (rte_pktmbuf_pkt_len(mbuf_in) > max_size)
diff --git a/lib/librte_gso/gso_tcp4.c b/lib/librte_gso/gso_tcp4.c
index ade172a..d31feaf 100644
--- a/lib/librte_gso/gso_tcp4.c
+++ b/lib/librte_gso/gso_tcp4.c
@@ -50,15 +50,13 @@
pkt->l2_len);
frag_off = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
if (unlikely(IS_FRAGMENTED(frag_off))) {
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
/* Don't process the packet without data */
hdr_offset = pkt->l2_len + pkt->l3_len + pkt->l4_len;
if (unlikely(hdr_offset >= pkt->pkt_len)) {
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
pyld_unit_size = gso_size - hdr_offset;
diff --git a/lib/librte_gso/gso_tunnel_tcp4.c b/lib/librte_gso/gso_tunnel_tcp4.c
index e0384c2..166aace 100644
--- a/lib/librte_gso/gso_tunnel_tcp4.c
+++ b/lib/librte_gso/gso_tunnel_tcp4.c
@@ -62,7 +62,7 @@
{
struct rte_ipv4_hdr *inner_ipv4_hdr;
uint16_t pyld_unit_size, hdr_offset, frag_off;
- int ret = 1;
+ int ret;
hdr_offset = pkt->outer_l2_len + pkt->outer_l3_len + pkt->l2_len;
inner_ipv4_hdr = (struct rte_ipv4_hdr *)(rte_pktmbuf_mtod(pkt, char *) +
@@ -73,25 +73,21 @@
*/
frag_off = rte_be_to_cpu_16(inner_ipv4_hdr->fragment_offset);
if (unlikely(IS_FRAGMENTED(frag_off))) {
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
hdr_offset += pkt->l3_len + pkt->l4_len;
/* Don't process the packet without data */
if (hdr_offset >= pkt->pkt_len) {
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
pyld_unit_size = gso_size - hdr_offset;
/* Segment the payload */
ret = gso_do_segment(pkt, hdr_offset, pyld_unit_size, direct_pool,
indirect_pool, pkts_out, nb_pkts_out);
- if (ret <= 1)
- return ret;
-
- update_tunnel_ipv4_tcp_headers(pkt, ipid_delta, pkts_out, ret);
+ if (ret > 1)
+ update_tunnel_ipv4_tcp_headers(pkt, ipid_delta, pkts_out, ret);
return ret;
}
diff --git a/lib/librte_gso/gso_udp4.c b/lib/librte_gso/gso_udp4.c
index 6fa68f2..5d0186a 100644
--- a/lib/librte_gso/gso_udp4.c
+++ b/lib/librte_gso/gso_udp4.c
@@ -52,8 +52,7 @@
pkt->l2_len);
frag_off = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
if (unlikely(IS_FRAGMENTED(frag_off))) {
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
/*
@@ -65,8 +64,7 @@
/* Don't process the packet without data. */
if (unlikely(hdr_offset + pkt->l4_len >= pkt->pkt_len)) {
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
/* pyld_unit_size must be a multiple of 8 because frag_off
diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c
index 751b5b6..896350e 100644
--- a/lib/librte_gso/rte_gso.c
+++ b/lib/librte_gso/rte_gso.c
@@ -30,7 +30,6 @@
uint16_t nb_pkts_out)
{
struct rte_mempool *direct_pool, *indirect_pool;
- struct rte_mbuf *pkt_seg;
uint64_t ol_flags;
uint16_t gso_size;
uint8_t ipid_delta;
@@ -44,8 +43,7 @@
if (gso_ctx->gso_size >= pkt->pkt_len) {
pkt->ol_flags &= (~(PKT_TX_TCP_SEG | PKT_TX_UDP_SEG));
- pkts_out[0] = pkt;
- return 1;
+ return 0;
}
direct_pool = gso_ctx->direct_pool;
@@ -75,18 +73,11 @@
indirect_pool, pkts_out, nb_pkts_out);
} else {
/* unsupported packet, skip */
- pkts_out[0] = pkt;
RTE_LOG(DEBUG, GSO, "Unsupported packet type\n");
- return 1;
+ ret = 0;
}
- if (ret > 1) {
- pkt_seg = pkt;
- while (pkt_seg) {
- rte_mbuf_refcnt_update(pkt_seg, -1);
- pkt_seg = pkt_seg->next;
- }
- } else if (ret < 0) {
+ if (ret < 0) {
/* Revert the ol_flags in the event of failure. */
pkt->ol_flags = ol_flags;
}
diff --git a/lib/librte_gso/rte_gso.h b/lib/librte_gso/rte_gso.h
index 3aab297..af480ee 100644
--- a/lib/librte_gso/rte_gso.h
+++ b/lib/librte_gso/rte_gso.h
@@ -89,8 +89,11 @@ struct rte_gso_ctx {
* the GSO segments are sent to should support transmission of multi-segment
* packets.
*
- * If the input packet is GSO'd, its mbuf refcnt reduces by 1. Therefore,
- * when all GSO segments are freed, the input packet is freed automatically.
+ * If the input packet is GSO'd, all the indirect segments are attached to the
+ * input packet.
+ *
+ * rte_gso_segment() will not free the input packet no matter whether it is
+ * GSO'd or not, the application should free it after call rte_gso_segment().
*
* If the memory space in pkts_out or MBUF pools is insufficient, this
* function fails, and it returns (-1) * errno. Otherwise, GSO succeeds,
@@ -109,6 +112,7 @@ struct rte_gso_ctx {
*
* @return
* - The number of GSO segments filled in pkts_out on success.
+ * - Return 0 if it needn't GSOed.
* - Return -ENOMEM if run out of memory in MBUF pools.
* - Return -EINVAL for invalid parameters.
*/
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v8 4/5] doc: change references to blacklist and whitelist
@ 2020-10-25 21:15 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-25 21:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Luca Boccassi
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 18 ++++++------
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 18 ++++++------
doc/guides/nics/mlx5.rst | 14 +++++-----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 23 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 4 +--
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 7 +++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 3 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 175 insertions(+), 155 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 080768a2e766..83565d71752d 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index da14a68d9cff..bac82421bca2 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index f77ce91f76ee..f8d3d77474ff 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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
@@ -632,19 +632,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
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 4f06e069847a..496b7199c8c9 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -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
-----------------
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 53f09a52dbb5..1272c1e72b7b 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 2540ddd5c2f5..97033958b758 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -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
-----
@@ -725,7 +725,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
@@ -750,12 +750,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 442ab1511c64..8c2985cad04a 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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_pmd_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:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 1deb7faaa50c..9ae5109234eb 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index 01e37d462102..b79780abc1a5 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index c62448768376..163ae3f47b11 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index e1b5c80d6c91..9a9cf5bfbc3d 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -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,13 +120,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 234bf066b9f6..6458bfc42e1f 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 5cf85d94cc34..488a9ec22450 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -172,7 +172,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
@@ -185,7 +185,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
@@ -200,7 +200,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.
@@ -212,7 +212,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``)
@@ -222,7 +222,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -458,7 +458,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.
@@ -466,7 +466,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.
@@ -802,7 +802,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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index a2aea1233376..6e4d53968f75 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -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,
@@ -41,7 +41,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -53,7 +53,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -62,8 +74,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 +86,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 +245,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::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index ed920e91ad51..cea7e8c2c4e3 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -24,8 +24,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -381,7 +381,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -389,14 +389,14 @@ devices managed by librte_pmd_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_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index afa65a1379a5..5077e06a98a2 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1488,7 +1488,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1496,14 +1496,14 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
@@ -1511,7 +1511,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index ecea3ecff074..e987f331048c 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index 7c04b5e60040..3c42e8585835 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -63,7 +63,8 @@ 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 +117,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 +128,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 +140,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 +152,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 +164,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 +186,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 +195,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 +206,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 +214,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 +230,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index a928a790e389..9da4281c8bd3 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index d8ac359e51d4..57069ae4db4c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -543,6 +543,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 7c5a45b72afb..b2af9a0755d6 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index b4fc587a09e2..41ee8b7ee3f4 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 1f37dccf8bb7..cb637abdfaf4 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting 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
@@ -1023,4 +1023,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 7acbd7404e3b..5d53bf633db7 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,18 @@ 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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4a96800ec648..eee5d8185061 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index d7e1dc581328..831f2bf58f99 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index a8bedbab5321..9a7743146b82 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -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 \
+ -w 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 29340d94e801..73cabf0098d3 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v7 4/5] doc: change references to blacklist and whitelist
@ 2020-10-25 20:57 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-25 20:57 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Luca Boccassi
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 18 ++++++------
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 18 ++++++------
doc/guides/nics/mlx5.rst | 14 +++++-----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 23 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 4 +--
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 7 +++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 3 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 175 insertions(+), 155 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 080768a2e766..83565d71752d 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index da14a68d9cff..bac82421bca2 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index f77ce91f76ee..f8d3d77474ff 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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
@@ -632,19 +632,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
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 4f06e069847a..496b7199c8c9 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -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
-----------------
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 53f09a52dbb5..1272c1e72b7b 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 2540ddd5c2f5..97033958b758 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -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
-----
@@ -725,7 +725,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
@@ -750,12 +750,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 442ab1511c64..8c2985cad04a 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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_pmd_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:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 1deb7faaa50c..9ae5109234eb 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index 01e37d462102..b79780abc1a5 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index c62448768376..163ae3f47b11 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index e1b5c80d6c91..9a9cf5bfbc3d 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -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,13 +120,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 234bf066b9f6..6458bfc42e1f 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 5cf85d94cc34..488a9ec22450 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -172,7 +172,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
@@ -185,7 +185,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
@@ -200,7 +200,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.
@@ -212,7 +212,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``)
@@ -222,7 +222,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -458,7 +458,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.
@@ -466,7 +466,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.
@@ -802,7 +802,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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index a2aea1233376..6e4d53968f75 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -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,
@@ -41,7 +41,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -53,7 +53,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -62,8 +74,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 +86,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 +245,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::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index ed920e91ad51..cea7e8c2c4e3 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -24,8 +24,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -381,7 +381,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -389,14 +389,14 @@ devices managed by librte_pmd_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_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index afa65a1379a5..5077e06a98a2 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1488,7 +1488,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1496,14 +1496,14 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
@@ -1511,7 +1511,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index ecea3ecff074..e987f331048c 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index 7c04b5e60040..3c42e8585835 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -63,7 +63,8 @@ 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 +117,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 +128,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 +140,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 +152,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 +164,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 +186,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 +195,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 +206,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 +214,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 +230,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index a928a790e389..9da4281c8bd3 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index d8ac359e51d4..57069ae4db4c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -543,6 +543,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 7c5a45b72afb..b2af9a0755d6 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index b4fc587a09e2..41ee8b7ee3f4 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 1f37dccf8bb7..cb637abdfaf4 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting 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
@@ -1023,4 +1023,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 7acbd7404e3b..5d53bf633db7 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,18 @@ 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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4a96800ec648..eee5d8185061 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index d7e1dc581328..831f2bf58f99 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index a8bedbab5321..9a7743146b82 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -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 \
+ -w 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 29340d94e801..73cabf0098d3 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v6 5/5] doc: change references to blacklist and whitelist
@ 2020-10-25 16:57 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-25 16:57 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Luca Boccassi
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 18 ++++++------
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 18 ++++++------
doc/guides/nics/mlx5.rst | 14 +++++-----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 23 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 4 +--
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 7 +++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 3 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 175 insertions(+), 155 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 080768a2e766..83565d71752d 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index da14a68d9cff..bac82421bca2 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index f77ce91f76ee..f8d3d77474ff 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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
@@ -632,19 +632,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
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 4f06e069847a..496b7199c8c9 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -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
-----------------
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 53f09a52dbb5..1272c1e72b7b 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 2540ddd5c2f5..97033958b758 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -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
-----
@@ -725,7 +725,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
@@ -750,12 +750,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 442ab1511c64..8c2985cad04a 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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_pmd_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:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 1deb7faaa50c..9ae5109234eb 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index 01e37d462102..b79780abc1a5 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index c62448768376..163ae3f47b11 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index e1b5c80d6c91..9a9cf5bfbc3d 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -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,13 +120,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 234bf066b9f6..6458bfc42e1f 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 5cf85d94cc34..488a9ec22450 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -172,7 +172,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
@@ -185,7 +185,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
@@ -200,7 +200,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.
@@ -212,7 +212,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``)
@@ -222,7 +222,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -458,7 +458,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.
@@ -466,7 +466,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.
@@ -802,7 +802,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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index a2aea1233376..6e4d53968f75 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -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,
@@ -41,7 +41,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -53,7 +53,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -62,8 +74,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 +86,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 +245,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::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index ed920e91ad51..cea7e8c2c4e3 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -24,8 +24,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -381,7 +381,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -389,14 +389,14 @@ devices managed by librte_pmd_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_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index afa65a1379a5..5077e06a98a2 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1488,7 +1488,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1496,14 +1496,14 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
@@ -1511,7 +1511,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index ecea3ecff074..e987f331048c 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index 7c04b5e60040..3c42e8585835 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -63,7 +63,8 @@ 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 +117,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 +128,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 +140,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 +152,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 +164,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 +186,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 +195,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 +206,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 +214,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 +230,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index a928a790e389..9da4281c8bd3 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index d8ac359e51d4..57069ae4db4c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -543,6 +543,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 7c5a45b72afb..b2af9a0755d6 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index b4fc587a09e2..41ee8b7ee3f4 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 1f37dccf8bb7..cb637abdfaf4 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting 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
@@ -1023,4 +1023,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 7acbd7404e3b..5d53bf633db7 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,18 @@ 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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4a96800ec648..eee5d8185061 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index d7e1dc581328..831f2bf58f99 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index a8bedbab5321..9a7743146b82 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -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 \
+ -w 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 29340d94e801..73cabf0098d3 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v5 5/5] doc: change references to blacklist and whitelist
@ 2020-10-24 1:01 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-24 1:01 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Luca Boccassi
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 18 ++++++------
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 18 ++++++------
doc/guides/nics/mlx5.rst | 14 +++++-----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 23 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 4 +--
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 7 +++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 3 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 175 insertions(+), 155 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 080768a2e766..83565d71752d 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index da14a68d9cff..bac82421bca2 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index f77ce91f76ee..f8d3d77474ff 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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
@@ -632,19 +632,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
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 4f06e069847a..496b7199c8c9 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -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
-----------------
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 53f09a52dbb5..1272c1e72b7b 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 2540ddd5c2f5..97033958b758 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -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
-----
@@ -725,7 +725,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
@@ -750,12 +750,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 442ab1511c64..8c2985cad04a 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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_pmd_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:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 1deb7faaa50c..9ae5109234eb 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index 01e37d462102..b79780abc1a5 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index c62448768376..163ae3f47b11 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index e1b5c80d6c91..9a9cf5bfbc3d 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -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,13 +120,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 234bf066b9f6..6458bfc42e1f 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 5cf85d94cc34..488a9ec22450 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -172,7 +172,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
@@ -185,7 +185,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
@@ -200,7 +200,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.
@@ -212,7 +212,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``)
@@ -222,7 +222,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -458,7 +458,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.
@@ -466,7 +466,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.
@@ -802,7 +802,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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index a2aea1233376..6e4d53968f75 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -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,
@@ -41,7 +41,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -53,7 +53,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -62,8 +74,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 +86,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 +245,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::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index ed920e91ad51..cea7e8c2c4e3 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -24,8 +24,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -381,7 +381,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -389,14 +389,14 @@ devices managed by librte_pmd_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_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index afa65a1379a5..5077e06a98a2 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1488,7 +1488,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1496,14 +1496,14 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
@@ -1511,7 +1511,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index ecea3ecff074..e987f331048c 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index 7c04b5e60040..3c42e8585835 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -63,7 +63,8 @@ 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 +117,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 +128,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 +140,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 +152,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 +164,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 +186,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 +195,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 +206,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 +214,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 +230,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index a928a790e389..9da4281c8bd3 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index d8ac359e51d4..57069ae4db4c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -543,6 +543,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 7c5a45b72afb..b2af9a0755d6 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index b4fc587a09e2..41ee8b7ee3f4 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 1f37dccf8bb7..cb637abdfaf4 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting 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
@@ -1023,4 +1023,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 7acbd7404e3b..5d53bf633db7 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,18 @@ 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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index 4a96800ec648..eee5d8185061 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index d7e1dc581328..831f2bf58f99 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index a8bedbab5321..9a7743146b82 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -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 \
+ -w 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 29340d94e801..73cabf0098d3 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v6 00/23] Add DLB PMD
2020-10-17 19:03 3% ` [dpdk-dev] [PATCH v5 00/22] Add DLB PMD Timothy McDaniel
@ 2020-10-23 18:32 3% ` Timothy McDaniel
1 sibling, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-23 18:32 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in v6 after dpdk reviews:
=====================
- fixed meson conditional build. Moved test into driver’s meson.build
file instead of event/meson.build
- documentation is populated as associated code is introduced
- add log_register in add dynamic logging patch
- rename RTE_xxx symbol(s) as DLB2_xxx
- replaced function ptr enqueue_four with direct call to movdir64b
- remove unused port_pages
- broke up probe patch into 3 smaller patches for easier review
- changed param order of movdir64b/movntdq to match intrinsics
- added self to MAINTAINERS files
- squashed announcement of availability into last patch in series
- correct spelling errors and delete repeated words
- DPDK_21.0 -> DPDK 21 in map file
- add experimental banner to public structs and APIs
- implemented other suggestions from code reviews of DLB2 PMD. The
software is very similar in form so some DLB2 reviews comments
were applicable to DLB as well
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-79539 ("eal: add new x86 cpuid support for WAITPKG")
Timothy McDaniel (23):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add eventdev probe
event/dlb: add flexible interface
event/dlb: add probe-time hardware init
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
MAINTAINERS | 5 +
app/test/test_eventdev.c | 7 +
config/rte_config.h | 8 +-
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4129 ++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 59 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1551 +++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 ++++
drivers/event/dlb/meson.build | 21 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 310 +
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 ++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6904 +++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 +++
drivers/event/dlb/pf/dlb_main.c | 586 ++
drivers/event/dlb/pf/dlb_main.h | 47 +
drivers/event/dlb/pf/dlb_pf.c | 750 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 77 +
drivers/event/dlb/rte_pmd_dlb_event_version.map | 9 +
drivers/event/meson.build | 2 +-
32 files changed, 21765 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/rte_pmd_dlb_event_version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1] doc: update abi version references
2020-10-23 16:07 33% [dpdk-dev] [PATCH v1] doc: update abi version references Ray Kinsella
@ 2020-10-23 16:51 7% ` David Marchand
2020-10-26 18:27 4% ` Kinsella, Ray
2020-10-26 19:23 33% ` [dpdk-dev] [PATCH] " Ray Kinsella
2020-10-26 19:31 33% ` [dpdk-dev] [PATCH v3] " Ray Kinsella
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2020-10-23 16:51 UTC (permalink / raw)
To: Ray Kinsella; +Cc: Neil Horman, Mcnamara, John, Thomas Monjalon, dev
On Fri, Oct 23, 2020 at 6:11 PM Ray Kinsella <mdr@ashroe.eu> wrote:
>
> Updated references to abi versions in the contributors guide.
Thanks for looking at it.
I would keep the dpdk release version aligned with updated ABI ver.
Caught 3 references in the first file.
%s/19.11/20.11/g can fix this.
Then:
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v1] doc: update abi version references
@ 2020-10-23 16:07 33% Ray Kinsella
2020-10-23 16:51 7% ` David Marchand
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ray Kinsella @ 2020-10-23 16:07 UTC (permalink / raw)
To: Ray Kinsella, Neil Horman; +Cc: john.mcnamara, thomas, david.marchand, dev
Updated references to abi versions in the contributors guide.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_policy.rst | 52 ++++-----
doc/guides/contributing/abi_versioning.rst | 120 ++++++++++-----------
2 files changed, 86 insertions(+), 86 deletions(-)
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index e17758a107..bc564f0cf6 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -78,15 +78,15 @@ The DPDK ABI policy
-------------------
A new major ABI version is declared no more frequently than yearly, with
-declarations usually aligning with a LTS release, e.g. ABI 20 for DPDK 19.11.
+declarations usually aligning with a LTS release, e.g. ABI 21 for DPDK 19.11.
Compatibility with the major ABI version is then mandatory in subsequent
-releases until the next major ABI version is declared, e.g. ABI 21 for DPDK
-20.11.
+releases until the next major ABI version is declared, e.g. ABI 22 for DPDK
+21.11.
At the declaration of a major ABI version, major version numbers encoded in
libraries' sonames are bumped to indicate the new version, with the minor
-version reset to ``0``. An example would be ``librte_eal.so.20.3`` would become
-``librte_eal.so.21.0``.
+version reset to ``0``. An example would be ``librte_eal.so.21.3`` would become
+``librte_eal.so.22.0``.
The ABI may then change multiple times, without warning, between the last major
ABI version increment and the HEAD label of the git tree, with the condition
@@ -95,8 +95,8 @@ sonames do not change.
Minor versions are incremented to indicate the release of a new ABI compatible
DPDK release, typically the DPDK quarterly releases. An example of this, might
-be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
-release, following the declaration of the new major ABI version ``20``.
+be that ``librte_eal.so.21.1`` would indicate the first ABI compatible DPDK
+release, following the declaration of the new major ABI version ``21``.
An ABI version is supported in all new releases until the next major ABI version
is declared. When changing the major ABI version, the release notes will detail
@@ -223,10 +223,10 @@ The following are examples of allowable ABI changes occurring between
declarations of major ABI versions.
* DPDK 19.11 release defines the function ``rte_foo()`` ; ``rte_foo()``
- is part of the major ABI version ``20``.
+ is part of the major ABI version ``21``.
-* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``.
- This is not a problem as long as the symbol ``rte_foo@DPDK20`` is
+* DPDK 21.02 release defines a new function ``rte_foo(uint8_t bar)``.
+ This is not a problem as long as the symbol ``rte_foo@DPDK21`` is
preserved through :ref:`abi_versioning`.
- The new function may be marked with the ``__rte_experimental`` tag for a
@@ -236,20 +236,20 @@ declarations of major ABI versions.
declared as ``__rte_deprecated`` and an deprecation notice is provided.
* DPDK 19.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
- version of ``rte_foo`` only exists from DPDK 20.02 onwards as described in the
+ version of ``rte_foo`` only exists from DPDK 21.02 onwards as described in the
:ref:`note on forward-only compatibility<forward-only>`.
-* DPDK 20.02 release defines the experimental function ``__rte_experimental
- rte_baz()``. This function may or may not exist in the DPDK 20.05 release.
+* DPDK 21.02 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in the DPDK 21.05 release.
* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
- declaration of the DPDK ``21`` major ABI version. The application can only
- ensure its runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ declaration of the DPDK ``22`` major ABI version. The application can only
+ ensure its runtime dependencies are met by specifying ``DPDK (>= 21.2)`` as
an explicit package dependency, as the soname can only indicate the
supported major ABI version.
-* At the release of DPDK 20.11, the function ``rte_foo(uint8_t bar)`` becomes
- formally part of then new major ABI version DPDK ``21`` and ``rte_foo()`` may be
+* At the release of DPDK 21.11, the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of then new major ABI version DPDK ``22`` and ``rte_foo()`` may be
removed.
.. _deprecation_notices:
@@ -261,25 +261,25 @@ The following are some examples of ABI deprecation notices which would be
added to the Release Notes:
* The Macro ``#RTE_FOO`` is deprecated and will be removed with ABI version
- 21, to be replaced with the inline function ``rte_foo()``.
+ 22, to be replaced with the inline function ``rte_foo()``.
* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 20.2. Backwards compatibility will be maintained for this function
- until the release of the new DPDK major ABI version 21, in DPDK version
- 20.11.
+ in version 21.2. Backwards compatibility will be maintained for this function
+ until the release of the new DPDK major ABI version 22, in DPDK version
+ 21.11.
-* The members of ``struct rte_foo`` have been reorganized in DPDK 20.02 for
+* The members of ``struct rte_foo`` have been reorganized in DPDK 21.02 for
performance reasons. Existing binary applications will have backwards
- compatibility in release 20.02, while newly built binaries will need to
+ compatibility in release 21.02, while newly built binaries will need to
reference the new structure variant ``struct rte_foo2``. Compatibility will be
- removed in release 20.11, and all applications will require updating and
+ removed in release 21.11, and all applications will require updating and
rebuilding to the new structure at that time, which will be renamed to the
original ``struct rte_foo``.
* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 20.02 will not contain these changes, but release 20.11 will,
+ upcoming release 21.02 will not contain these changes, but release 21.11 will,
and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to ABI version 21 will
+ these changes. Binaries using this library built prior to ABI version 22 will
require updating and recompilation.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index b8b35761e2..91ada18dd7 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -14,22 +14,22 @@ What is a library's soname?
---------------------------
System libraries usually adopt the familiar major and minor version naming
-convention, where major versions (e.g. ``librte_eal 20.x, 21.x``) are presumed
+convention, where major versions (e.g. ``librte_eal 21.x, 22.x``) are presumed
to be ABI incompatible with each other and minor versions (e.g. ``librte_eal
-20.1, 20.2``) are presumed to be ABI compatible. A library's `soname
+21.1, 21.2``) are presumed to be ABI compatible. A library's `soname
<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
compatibility information about a given library, describing the lowest common
denominator ABI supported by the library. The soname or logical name for the
library, is typically comprised of the library's name and major version e.g.
-``librte_eal.so.20``.
+``librte_eal.so.21``.
During an application's build process, a library's soname is noted as a runtime
dependency of the application. This information is then used by the `dynamic
linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
applications dependencies at runtime, to load a library supporting the correct
ABI version. The library loaded at runtime therefore, may be a minor revision
-supporting the same major ABI version (e.g. ``librte_eal.20.2``), as the library
-used to link the application (e.g ``librte_eal.20.0``).
+supporting the same major ABI version (e.g. ``librte_eal.21.2``), as the library
+used to link the application (e.g ``librte_eal.21.0``).
.. _major_abi_versions:
@@ -59,41 +59,41 @@ persists over multiple releases.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
$ head ./lib/librte_eal/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
When an ABI change is made between major ABI versions to a given library, a new
section is added to that library's version map describing the impending new ABI
version, as described in the section :ref:`example_abi_macro_usage`. The
-library's soname and filename however do not change, e.g. ``libacl.so.20``, as
+library's soname and filename however do not change, e.g. ``libacl.so.21``, as
ABI compatibility with the last major ABI version continues to be preserved for
that library.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
- DPDK_21 {
+ DPDK_22 {
global:
- } DPDK_20;
+ } DPDK_21;
...
$ head ./lib/librte_eal/version.map
- DPDK_20 {
+ DPDK_21 {
global:
...
-However when a new ABI version is declared, for example DPDK ``21``, old
+However when a new ABI version is declared, for example DPDK ``22``, old
depreciated functions may be safely removed at this point and the entire old
major ABI version removed, see the section :ref:`deprecating_entire_abi` on
how this may be done.
@@ -101,12 +101,12 @@ how this may be done.
.. code-block:: none
$ head ./lib/librte_acl/version.map
- DPDK_21 {
+ DPDK_22 {
global:
...
$ head ./lib/librte_eal/version.map
- DPDK_21 {
+ DPDK_22 {
global:
...
@@ -216,7 +216,7 @@ library looks like this
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -242,7 +242,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -264,15 +264,15 @@ This file needs to be modified as follows
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
The addition of the new block tells the linker that a new version node
-``DPDK_21`` is available, which contains the symbol rte_acl_create, and inherits
-the symbols from the DPDK_20 node. This list is directly translated into a
+``DPDK_22`` is available, which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_21 node. This list is directly translated into a
list of exported symbols when DPDK is compiled as a shared library.
Next, we need to specify in the code which function maps to the rte_acl_create
@@ -285,7 +285,7 @@ with the public symbol name
-struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param)
+struct rte_acl_ctx * __vsym
- +rte_acl_create_v20(const struct rte_acl_param *param)
+ +rte_acl_create_v21(const struct rte_acl_param *param)
{
size_t sz;
struct rte_acl_ctx *ctx;
@@ -294,7 +294,7 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols and we have annotated the function as
``__vsym``, an implementation of a versioned symbol . That is our next step,
-mapping this new symbol name to the initial symbol name at version node 20.
+mapping this new symbol name to the initial symbol name at version node 21.
Immediately after the function, we add the VERSION_SYMBOL macro.
.. code-block:: c
@@ -302,26 +302,26 @@ Immediately after the function, we add the VERSION_SYMBOL macro.
#include <rte_function_versioning.h>
...
- VERSION_SYMBOL(rte_acl_create, _v20, 20);
+ VERSION_SYMBOL(rte_acl_create, _v21, 21);
Remembering to also add the rte_function_versioning.h header to the requisite c
file where these changes are being made. The macro instructs the linker to
-create a new symbol ``rte_acl_create@DPDK_20``, which matches the symbol created
+create a new symbol ``rte_acl_create@DPDK_21``, which matches the symbol created
in older builds, but now points to the above newly named function. We have now
mapped the original rte_acl_create symbol to the original function (but with a
new name).
Please see the section :ref:`Enabling versioning macros
<enabling_versioning_macros>` to enable this macro in the meson/ninja build.
-Next, we need to create the new ``v21`` version of the symbol. We create a new
-function name, with the ``v21`` suffix, and implement it appropriately.
+Next, we need to create the new ``v22`` version of the symbol. We create a new
+function name, with the ``v22`` suffix, and implement it appropriately.
.. code-block:: c
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug);
{
- struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
+ struct rte_acl_ctx *ctx = rte_acl_create_v21(param);
ctx->debug = debug;
@@ -330,7 +330,7 @@ function name, with the ``v21`` suffix, and implement it appropriately.
This code serves as our new API call. Its the same as our old call, but adds the
new parameter in place. Next we need to map this function to the new default
-symbol ``rte_acl_create@DPDK_21``. To do this, immediately after the function,
+symbol ``rte_acl_create@DPDK_22``. To do this, immediately after the function,
we add the BIND_DEFAULT_SYMBOL macro.
.. code-block:: c
@@ -338,10 +338,10 @@ we add the BIND_DEFAULT_SYMBOL macro.
#include <rte_function_versioning.h>
...
- BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
The macro instructs the linker to create the new default symbol
-``rte_acl_create@DPDK_21``, which points to the above newly named function.
+``rte_acl_create@DPDK_22``, which points to the above newly named function.
We finally modify the prototype of the call in the public header file,
such that it contains both versions of the symbol and the public API.
@@ -352,15 +352,15 @@ such that it contains both versions of the symbol and the public API.
rte_acl_create(const struct rte_acl_param *param);
struct rte_acl_ctx * __vsym
- rte_acl_create_v20(const struct rte_acl_param *param);
+ rte_acl_create_v21(const struct rte_acl_param *param);
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug);
And that's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_20 version, used by previously built applications,
-and a new DPDK_21 version, used by future built applications.
+rte_acl_create, an old DPDK_21 version, used by previously built applications,
+and a new DPDK_22 version, used by future built applications.
.. note::
@@ -385,21 +385,21 @@ this code in a position of no longer having a symbol simply named
To correct this, we can simply map a function of our choosing back to the public
symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
assumption is that the most recent version of the symbol is the one you want to
-map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
+map. So, back in the C file where, immediately after ``rte_acl_create_v22`` is
defined, we add this
.. code-block:: c
struct rte_acl_ctx * __vsym
- rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ rte_acl_create_v22(const struct rte_acl_param *param, int debug)
{
...
}
- MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v22);
That tells the compiler that, when building a static library, any calls to the
-symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
+symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v22``
.. _enabling_versioning_macros:
@@ -456,7 +456,7 @@ version node.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
@@ -486,22 +486,22 @@ When we promote the symbol to the stable ABI, we simply strip the
}
We then update the map file, adding the symbol ``rte_acl_create``
-to the ``DPDK_21`` version node.
+to the ``DPDK_22`` version node.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
Although there are strictly no guarantees or commitments associated with
@@ -509,7 +509,7 @@ Although there are strictly no guarantees or commitments associated with
an alias to experimental. The process to add an alias to experimental,
is similar to the symbol versioning process. Assuming we have an experimental
symbol as before, we now add the symbol to both the ``EXPERIMENTAL``
-and ``DPDK_21`` version nodes.
+and ``DPDK_22`` version nodes.
.. code-block:: c
@@ -535,29 +535,29 @@ and ``DPDK_21`` version nodes.
VERSION_SYMBOL_EXPERIMENTAL(rte_acl_create, _e);
struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param)
+ rte_acl_create_v22(const struct rte_acl_param *param)
{
return rte_acl_create(param);
}
- BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
In the map file, we map the symbol to both the ``EXPERIMENTAL``
-and ``DPDK_21`` version nodes.
+and ``DPDK_22`` version nodes.
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
...
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
EXPERIMENTAL {
global:
@@ -585,7 +585,7 @@ file:
.. code-block:: none
- DPDK_20 {
+ DPDK_21 {
global:
rte_acl_add_rules;
@@ -607,21 +607,21 @@ file:
local: *;
};
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_create;
- } DPDK_20;
+ } DPDK_21;
Next remove the corresponding versioned export.
.. code-block:: c
- -VERSION_SYMBOL(rte_acl_create, _v20, 20);
+ -VERSION_SYMBOL(rte_acl_create, _v21, 21);
Note that the internal function definition could also be removed, but its used
-in our example by the newer version ``v21``, so we leave it in place and declare
+in our example by the newer version ``v22``, so we leave it in place and declare
it as static. This is a coding style choice.
.. _deprecating_entire_abi:
@@ -642,7 +642,7 @@ In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_21 {
+ DPDK_22 {
global:
rte_acl_add_rules;
@@ -670,8 +670,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v22, 22);
Lastly, any VERSION_SYMBOL macros that point to the old version nodes
should be removed, taking care to preserve any code that is shared
--
2.23.0
^ permalink raw reply [relevance 33%]
* Re: [dpdk-dev] [v3 1/2] cryptodev: support enqueue callback functions
2020-10-21 19:33 3% ` Ananyev, Konstantin
@ 2020-10-23 12:36 0% ` Gujjar, Abhinandan S
0 siblings, 0 replies; 200+ results
From: Gujjar, Abhinandan S @ 2020-10-23 12:36 UTC (permalink / raw)
To: Ananyev, Konstantin, dev, Doherty, Declan, akhil.goyal,
Honnappa.Nagarahalli
Cc: Vangati, Narender, jerinj
Hi Konstantin,
Thanks. I will generate a new patch with suggested changes.
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Thursday, October 22, 2020 1:04 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>; akhil.goyal@nxp.com;
> Honnappa.Nagarahalli@arm.com
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v3 1/2] cryptodev: support enqueue callback functions
>
>
> Hi Abhinandan,
>
> Thanks for the effort, good progress.
> Though few more comments, see below.
>
> > This patch adds APIs to add/remove callback functions. The callback
> > function will be called for each burst of crypto ops received on a
> > given crypto device queue pair.
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > config/rte_config.h | 1 +
> > lib/librte_cryptodev/meson.build | 2 +-
> > lib/librte_cryptodev/rte_cryptodev.c | 201
> +++++++++++++++++++++++++
> > lib/librte_cryptodev/rte_cryptodev.h | 153 ++++++++++++++++++-
> > lib/librte_cryptodev/rte_cryptodev_version.map | 2 +
> > 5 files changed, 357 insertions(+), 2 deletions(-)
>
> Don't forget to update Release Notes and probably Prog Guide too.
>
> >
> > diff --git a/config/rte_config.h b/config/rte_config.h index
> > 03d90d7..e999d93 100644
> > --- a/config/rte_config.h
> > +++ b/config/rte_config.h
> > @@ -61,6 +61,7 @@
> > /* cryptodev defines */
> > #define RTE_CRYPTO_MAX_DEVS 64
> > #define RTE_CRYPTODEV_NAME_LEN 64
> > +#define RTE_CRYPTO_CALLBACKS 1
> >
> > /* compressdev defines */
> > #define RTE_COMPRESS_MAX_DEVS 64
> > diff --git a/lib/librte_cryptodev/meson.build
> > b/lib/librte_cryptodev/meson.build
> > index c4c6b3b..8c5493f 100644
> > --- a/lib/librte_cryptodev/meson.build
> > +++ b/lib/librte_cryptodev/meson.build
> > @@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
> > 'rte_crypto.h',
> > 'rte_crypto_sym.h',
> > 'rte_crypto_asym.h')
> > -deps += ['kvargs', 'mbuf']
> > +deps += ['kvargs', 'mbuf', 'rcu']
> > diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> > b/lib/librte_cryptodev/rte_cryptodev.c
> > index 3d95ac6..5ba774a 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.c
> > +++ b/lib/librte_cryptodev/rte_cryptodev.c
> > @@ -448,6 +448,10 @@ struct
> rte_cryptodev_sym_session_pool_private_data {
> > return 0;
> > }
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/* spinlock for crypto device enq callbacks */ static rte_spinlock_t
> > +rte_cryptodev_enq_cb_lock = RTE_SPINLOCK_INITIALIZER; #endif
> >
> > const char *
> > rte_cryptodev_get_feature_name(uint64_t flag) @@ -1136,6 +1140,203 @@
> > struct rte_cryptodev *
> > socket_id);
> > }
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +
> > +struct rte_cryptodev_cb *
> > +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + rte_cryptodev_callback_fn cb_fn,
> > + void *cb_arg)
> > +{
> > + struct rte_cryptodev *dev;
> > + struct rte_cryptodev_cb *cb, *tail;
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + struct rte_rcu_qsbr *qsbr;
> > + size_t size;
> > +
> > + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> > + const uint32_t max_threads = 1;
> > +
> > + if (!cb_fn)
> > + return NULL;
> > +
> > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> > + return NULL;
> > + }
> > +
> > + dev = &rte_crypto_devices[dev_id];
> > + if (qp_id >= dev->data->nb_queue_pairs) {
> > + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> > + return NULL;
> > + }
> > +
> > + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock);
> > + if (dev->enq_cbs == NULL) {
> > + dev->enq_cbs = rte_zmalloc(NULL, sizeof(cb) *
> > + dev->data->nb_queue_pairs, 0);
> > + if (dev->enq_cbs == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for
> callbacks");
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
>
> It is a bit clumsy to do unlock() for every return with error.
> Probably an easier way - create an internal function that would do the actual
> job, and then lock(); ret=actual_job_internal_functio(...); unlock();...
>
> > + rte_errno = ENOMEM;
> > + return NULL;
> > + }
> > +
> > + list = rte_zmalloc(NULL, sizeof(*list), 0);
>
> As I understand, list is per queue, while enq_cbs[] is per port.
> So if enq_cbs is not null, it doesn't mean that list for that particular queue is
> already properly initialized.
>
> Another thing - is there any point for dev->enq_cbs[] to be a an array of
> pointers to rte_cryptodev_enq_cb_rcu? Considering that
> rte_cryptodev_enq_cb_rcu itself contains just two pointers inside, I think it
> enq_cbs can point just to an array of rte_cryptodev_enq_cb_rcu:
>
> struct rte_cryptodev {
> ...
> struct rte_cryptodev_enq_cb_rcu *enq_cbs;
>
> And you can remove one level of indirection here and in other places.
>
> > + if (list == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for list on
> "
> > + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > + rte_errno = ENOMEM;
> > + rte_free(dev->enq_cbs);
>
> Here and in other places: you free dev->enq_cbs, but not set it to NULL.
> In fact - probably a good idea to have one cleanup() function that would free all
> necessary stuff and set it to null, and then use it in all such places.
>
> > + return NULL;
> > + }
> > +
> > + /* Create RCU QSBR variable */
> > + size = rte_rcu_qsbr_get_memsize(max_threads);
> > + qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> > + if (qsbr == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for RCU
> on "
> > + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > + rte_errno = ENOMEM;
> > + rte_free(list);
> > + rte_free(dev->enq_cbs);
> > + dev->enq_cbs[qp_id] = NULL;
> > + return NULL;
> > + }
> > +
> > + if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> > + CDEV_LOG_ERR("Failed to initialize for RCU on "
> > + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > + rte_free(qsbr);
> > + rte_free(list);
> > + rte_free(dev->enq_cbs);
> > + dev->enq_cbs[qp_id] = NULL;
> > + return NULL;
> > + }
> > +
> > + dev->enq_cbs[qp_id] = list;
> > + list->qsbr = qsbr;
> > + }
> > +
> > + cb = rte_zmalloc(NULL, sizeof(*cb), 0);
> > + if (cb == NULL) {
> > + CDEV_LOG_ERR("Failed to allocate memory for callback on "
> > + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > + rte_errno = ENOMEM;
> > + return NULL;
> > + }
> > +
> > + cb->fn = cb_fn;
> > + cb->arg = cb_arg;
> > +
> > + /* Add the callbacks in fifo order. */
> > + list = dev->enq_cbs[qp_id];
> > + tail = list->next;
> > + if (tail) {
> > + while (tail->next)
> > + tail = tail->next;
> > + tail->next = cb;
> > + } else
> > + list->next = cb;
> > +
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +
> > + return cb;
> > +}
> > +
> > +int
> > +rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + struct rte_cryptodev_cb *cb)
> > +{
> > + struct rte_cryptodev *dev;
> > + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + uint16_t qp;
> > + int free_mem;
> > + int ret;
> > +
> > + free_mem = 1;
> > + ret = -EINVAL;
> > +
> > + if (!cb) {
> > + CDEV_LOG_ERR("cb is NULL");
> > + return ret;
> > + }
> > +
> > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> > + return ret;
> > + }
> > +
> > + dev = &rte_crypto_devices[dev_id];
> > + if (qp_id >= dev->data->nb_queue_pairs) {
> > + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> > + return ret;
> > + }
> > +
> > + list = dev->enq_cbs[qp_id];
> > + if (list == NULL) {
> > + CDEV_LOG_ERR("Callback list is NULL");
> > + return ret;
> > + }
> > +
> > + if (list->qsbr == NULL) {
> > + CDEV_LOG_ERR("Rcu qsbr is NULL");
> > + return ret;
> > + }
> > +
> > + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock);
> > + if (dev->enq_cbs == NULL) {
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > + return ret;
> > + }
> > +
> > + prev_cb = &list->next;
> > + for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
> > + curr_cb = *prev_cb;
> > + if (curr_cb == cb) {
> > + /* Remove the user cb from the callback list. */
> > + *prev_cb = curr_cb->next;
> > + ret = 0;
> > + break;
> > + }
> > + }
> > +
> > + if (!ret) {
> > + /* Call sync with invalid thread id as this is part of
> > + * control plane API
> > + */
> > + rte_rcu_qsbr_synchronize(list->qsbr,
> RTE_QSBR_THRID_INVALID);
> > + rte_free(cb);
> > + }
> > +
> > + if (list->next == NULL) {
> > + rte_free(list->qsbr);
>
> We can't destroy our sync variable while device is not stopped or destroyed.
> It can be still used by DP.
> Probably the easiest way to deal with it - allocate and initialize enq_cbs[] and
> all related qsbrs at first add_callback and free all that memory only on
> dev_destroy().
>
> > + rte_free(list);
> > + dev->enq_cbs[qp_id] = NULL;
> > + }
> > +
> > + for (qp = 0; qp < dev->data->nb_queue_pairs; qp++)
> > + if (dev->enq_cbs[qp] != NULL) {
> > + free_mem = 0;
> > + break;
> > + }
> > +
> > + if (free_mem) {
> > + rte_free(dev->enq_cbs);
>
> Again, not safe to do here, see above.
>
> > + dev->enq_cbs = NULL;
> > + }
> > +
> > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +
> > + return ret;
> > +}
> > +#endif
> >
> > int
> > rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats
> > *stats) diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> > b/lib/librte_cryptodev/rte_cryptodev.h
> > index 0935fd5..669746d 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -23,6 +23,7 @@
> > #include "rte_dev.h"
> > #include <rte_common.h>
> > #include <rte_config.h>
> > +#include <rte_rcu_qsbr.h>
> >
> > #include "rte_cryptodev_trace_fp.h"
> >
> > @@ -522,6 +523,34 @@ struct rte_cryptodev_qp_conf {
> > /**< The mempool for creating sess private data in sessionless mode
> > */ };
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * Function type used for pre processing crypto ops when enqueue
> > +burst is
> > + * called.
> > + *
> > + * The callback function is called on enqueue burst immediately
> > + * before the crypto ops are put onto the hardware queue for processing.
> > + *
> > + * @param dev_id The identifier of the device.
> > + * @param qp_id The index of the queue pair in which ops are
> > + * to be enqueued for processing. The value
> > + * must be in the range [0, nb_queue_pairs - 1]
> > + * previously supplied to
> > + * *rte_cryptodev_configure*.
> > + * @param ops The address of an array of *nb_ops* pointers
> > + * to *rte_crypto_op* structures which contain
> > + * the crypto operations to be processed.
> > + * @param nb_ops The number of operations to process.
> > + * @param user_param The arbitrary user parameter passed in by the
> > + * application when the callback was originally
> > + * registered.
> > + * @return The number of ops to be enqueued to the
> > + * crypto device.
> > + */
> > +typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t
> qp_id,
> > + struct rte_crypto_op **ops, uint16_t nb_ops, void
> *user_param);
> > +#endif
> > +
> > /**
> > * Typedef for application callback function to be registered by application
> > * software for notification of device events @@ -822,7 +851,6 @@
> > struct rte_cryptodev_config {
> > enum rte_cryptodev_event_type event,
> > rte_cryptodev_cb_fn cb_fn, void *cb_arg);
> >
> > -
> > typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
> > struct rte_crypto_op **ops, uint16_t nb_ops);
> > /**< Dequeue processed packets from queue pair of a device. */ @@
> > -839,6 +867,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
> > /** Structure to keep track of registered callbacks */
> > TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * @internal
> > + * Structure used to hold information about the callbacks to be
> > +called for a
> > + * queue pair on enqueue.
> > + */
> > +struct rte_cryptodev_cb {
> > + struct rte_cryptodev_cb *next;
> > + /** < Pointer to next callback */
> > + rte_cryptodev_callback_fn fn;
> > + /** < Pointer to callback function */
> > + void *arg;
> > + /** < Pointer to argument */
> > +};
> > +
> > +/**
> > + * @internal
> > + * Structure used to hold information about the RCU for a queue pair.
> > + */
> > +struct rte_cryptodev_enq_cb_rcu {
> > + struct rte_cryptodev_cb *next;
> > + /** < Pointer to next callback */
> > + struct rte_rcu_qsbr *qsbr;
> > + /** < RCU QSBR variable per queue pair */ }; #endif
> > +
> > /** The data structure associated with each crypto device. */ struct
> > rte_cryptodev {
> > dequeue_pkt_burst_t dequeue_burst;
> > @@ -867,6 +922,11 @@ struct rte_cryptodev {
> > __extension__
> > uint8_t attached : 1;
> > /**< Flag indicating the device is attached */
> > +
> > +#ifdef RTE_CRYPTO_CALLBACKS
>
> I'd *always* reserve space for it.
> No matter is RTE_CRYPTO_CALLBACKS defined or not.
> To avoid difference in public structure layout.
>
> > + struct rte_cryptodev_enq_cb_rcu **enq_cbs;
>
> As I said above, no need for extra level of indirection.
>
> > + /**< User application callback for pre enqueue processing */ #endif
>
> As I understand, it is not an ABI breakage - as there are some free space right
> now at the end of struct rte_cryptodev (due to it alignment), but definitely need
> to update RN.
>
>
> > } __rte_cache_aligned;
> >
> > void *
> > @@ -989,6 +1049,25 @@ struct rte_cryptodev_data { {
> > struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > + if (unlikely(dev->enq_cbs != NULL && dev->enq_cbs[qp_id] != NULL)) {
>
> Agree with Honnappa's comment for that piece of code.
> Probably need to be something like:
>
> if (unlikely(dev->enq_cbs != NULL && dev->enq_cbs[qp_id].next != NULL) {
> list = &dev->enq_cbs[qp_id];
> rte_rcu_qsbr_thread_online(list->qsbr, 0);
> for (cb = list->next; cb != NULL; cb = cb->next)
> ....
> rte_rcu_qsbr_thread_offline(list->qsbr, 0); }
>
>
> > + struct rte_cryptodev_enq_cb_rcu *list;
> > + struct rte_cryptodev_cb *cb;
> > +
> > + list = dev->enq_cbs[qp_id];
> > + cb = list->next;
> > + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> > +
> > + do {
> > + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> > + cb->arg);
> > + cb = cb->next;
> > + } while (cb != NULL);
> > +
> > + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> > + }
> > +#endif
> > +
> > rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops,
> nb_ops);
> > return (*dev->enqueue_burst)(
> > dev->data->queue_pairs[qp_id], ops, nb_ops); @@ -
> 1730,6 +1809,78
> > @@ struct rte_crypto_raw_dp_ctx {
> > rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
> > uint32_t n);
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Add a user callback for a given crypto device and queue pair which
> > +will be
> > + * called on crypto ops enqueue.
> > + *
> > + * This API configures a function to be called for each burst of
> > +crypto ops
> > + * received on a given crypto device queue pair. The return value is
> > +a pointer
> > + * that can be used later to remove the callback using
> > + * rte_cryptodev_remove_enq_callback().
> > + *
> > + * Multiple functions are called in the order that they are added.
> > + *
> > + * @param dev_id The identifier of the device.
> > + * @param qp_id The index of the queue pair in which ops are
> > + * to be enqueued for processing. The value
> > + * must be in the range [0, nb_queue_pairs - 1]
> > + * previously supplied to
> > + * *rte_cryptodev_configure*.
> > + * @param cb_fn The callback function
> > + * @param cb_arg A generic pointer parameter which will be
> passed
> > + * to each invocation of the callback function on
> > + * this crypto device and queue pair.
> > + *
> > + * @return
> > + * NULL on error.
> > + * On success, a pointer value which can later be used to remove the
> callback.
> > + */
> > +
> > +__rte_experimental
> > +struct rte_cryptodev_cb *
> > +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + rte_cryptodev_callback_fn cb_fn,
> > + void *cb_arg);
> > +
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Remove a user callback function for given crypto device and queue pair.
> > + *
> > + * This function is used to removed callbacks that were added to a
> > +crypto
> > + * device queue pair using rte_cryptodev_add_enq_callback().
> > + *
> > + *
> > + *
> > + * @param dev_id The identifier of the device.
> > + * @param qp_id The index of the queue pair in which ops are
> > + * to be enqueued for processing. The value
> > + * must be in the range [0, nb_queue_pairs - 1]
> > + * previously supplied to
> > + * *rte_cryptodev_configure*.
> > + * @param cb Pointer to user supplied callback created via
> > + * rte_cryptodev_add_enq_callback().
> > + *
> > + * @return
> > + * - 0: Success. Callback was removed.
> > + * - -EINVAL: The dev_id or the qp_id is out of range, or the callback
> > + * is NULL or not found for the crypto device queue pair.
> > + */
> > +
> > +__rte_experimental
> > +int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> > + uint16_t qp_id,
> > + struct rte_cryptodev_cb *cb);
> > +
> > +#endif
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map
> > b/lib/librte_cryptodev/rte_cryptodev_version.map
> > index 7e4360f..5d8d6b0 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev_version.map
> > +++ b/lib/librte_cryptodev/rte_cryptodev_version.map
> > @@ -101,6 +101,7 @@ EXPERIMENTAL {
> > rte_cryptodev_get_qp_status;
> >
> > # added in 20.11
> > + rte_cryptodev_add_enq_callback;
> > rte_cryptodev_configure_raw_dp_ctx;
> > rte_cryptodev_get_raw_dp_ctx_size;
> > rte_cryptodev_raw_dequeue;
> > @@ -109,4 +110,5 @@ EXPERIMENTAL {
> > rte_cryptodev_raw_enqueue;
> > rte_cryptodev_raw_enqueue_burst;
> > rte_cryptodev_raw_enqueue_done;
> > + rte_cryptodev_remove_enq_callback;
> > };
> > --
> > 1.9.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 2/2] lpm: hide internal data
@ 2020-10-23 9:38 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2020-10-23 9:38 UTC (permalink / raw)
To: dev
Cc: honnappa.nagarahalli, ruifeng.wang, nd, Kevin Traynor,
Thomas Monjalon, Vladimir Medvedkin, Bruce Richardson
From: Ruifeng Wang <ruifeng.wang@arm.com>
Fields except tbl24 and tbl8 in rte_lpm structure have no
need to be exposed to the user.
Hide the unneeded exposure of structure fields for better
ABI maintainability.
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v2:
- hid rte_lpm_rule and rte_lpm_rule_info,
- used i_lpm as the preferred variable name,
- moved lpm <-> i_lpm at public API boundaries, all internal functions
deal with __rte_lpm object,
---
doc/guides/rel_notes/release_20_11.rst | 3 +
lib/librte_lpm/rte_lpm.c | 388 +++++++++++++------------
lib/librte_lpm/rte_lpm.h | 19 --
3 files changed, 208 insertions(+), 202 deletions(-)
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index d8ac359e51..dca8d41eb6 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -606,6 +606,9 @@ ABI Changes
* sched: Added new fields to ``struct rte_sched_subport_port_params``.
+* lpm: Removed fields other than ``tbl24`` and ``tbl8`` from the struct
+ ``rte_lpm``. The removed fields were made internal.
+
Known Issues
------------
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 51a0ae5780..002811f4de 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -40,11 +40,31 @@ enum valid_flag {
VALID
};
+/** @internal Rule structure. */
+struct rte_lpm_rule {
+ uint32_t ip; /**< Rule IP address. */
+ uint32_t next_hop; /**< Rule next hop. */
+};
+
+/** @internal Contains metadata about the rules table. */
+struct rte_lpm_rule_info {
+ uint32_t used_rules; /**< Used rules so far. */
+ uint32_t first_rule; /**< Indexes the first rule of a given depth. */
+};
+
/** @internal LPM structure. */
struct __rte_lpm {
- /* LPM metadata. */
+ /* Exposed LPM data. */
struct rte_lpm lpm;
+ /* LPM metadata. */
+ char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
+ uint32_t max_rules; /**< Max. balanced rules per lpm. */
+ uint32_t number_tbl8s; /**< Number of tbl8s. */
+ /**< Rule info table. */
+ struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH];
+ struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
+
/* RCU config. */
struct rte_rcu_qsbr *v; /* RCU QSBR variable. */
enum rte_lpm_qsbr_mode rcu_mode;/* Blocking, defer queue. */
@@ -104,7 +124,7 @@ depth_to_range(uint8_t depth)
struct rte_lpm *
rte_lpm_find_existing(const char *name)
{
- struct rte_lpm *l = NULL;
+ struct __rte_lpm *i_lpm = NULL;
struct rte_tailq_entry *te;
struct rte_lpm_list *lpm_list;
@@ -112,8 +132,8 @@ rte_lpm_find_existing(const char *name)
rte_mcfg_tailq_read_lock();
TAILQ_FOREACH(te, lpm_list, next) {
- l = te->data;
- if (strncmp(name, l->name, RTE_LPM_NAMESIZE) == 0)
+ i_lpm = te->data;
+ if (strncmp(name, i_lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
rte_mcfg_tailq_read_unlock();
@@ -123,7 +143,7 @@ rte_lpm_find_existing(const char *name)
return NULL;
}
- return l;
+ return &i_lpm->lpm;
}
/*
@@ -134,7 +154,7 @@ rte_lpm_create(const char *name, int socket_id,
const struct rte_lpm_config *config)
{
char mem_name[RTE_LPM_NAMESIZE];
- struct __rte_lpm *internal_lpm;
+ struct __rte_lpm *i_lpm;
struct rte_lpm *lpm = NULL;
struct rte_tailq_entry *te;
uint32_t mem_size, rules_size, tbl8s_size;
@@ -157,19 +177,18 @@ rte_lpm_create(const char *name, int socket_id,
/* guarantee there's no existing */
TAILQ_FOREACH(te, lpm_list, next) {
- lpm = te->data;
- if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
+ i_lpm = te->data;
+ if (strncmp(name, i_lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
if (te != NULL) {
- lpm = NULL;
rte_errno = EEXIST;
goto exit;
}
/* Determine the amount of memory to allocate. */
- mem_size = sizeof(*internal_lpm);
+ mem_size = sizeof(*i_lpm);
rules_size = sizeof(struct rte_lpm_rule) * config->max_rules;
tbl8s_size = sizeof(struct rte_lpm_tbl_entry) *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES * config->number_tbl8s;
@@ -183,49 +202,47 @@ rte_lpm_create(const char *name, int socket_id,
}
/* Allocate memory to store the LPM data structures. */
- internal_lpm = rte_zmalloc_socket(mem_name, mem_size,
+ i_lpm = rte_zmalloc_socket(mem_name, mem_size,
RTE_CACHE_LINE_SIZE, socket_id);
- if (internal_lpm == NULL) {
+ if (i_lpm == NULL) {
RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
rte_free(te);
rte_errno = ENOMEM;
goto exit;
}
- lpm = &internal_lpm->lpm;
- lpm->rules_tbl = rte_zmalloc_socket(NULL,
+ i_lpm->rules_tbl = rte_zmalloc_socket(NULL,
(size_t)rules_size, RTE_CACHE_LINE_SIZE, socket_id);
- if (lpm->rules_tbl == NULL) {
+ if (i_lpm->rules_tbl == NULL) {
RTE_LOG(ERR, LPM, "LPM rules_tbl memory allocation failed\n");
- rte_free(internal_lpm);
- internal_lpm = NULL;
- lpm = NULL;
+ rte_free(i_lpm);
+ i_lpm = NULL;
rte_free(te);
rte_errno = ENOMEM;
goto exit;
}
- lpm->tbl8 = rte_zmalloc_socket(NULL,
+ i_lpm->lpm.tbl8 = rte_zmalloc_socket(NULL,
(size_t)tbl8s_size, RTE_CACHE_LINE_SIZE, socket_id);
- if (lpm->tbl8 == NULL) {
+ if (i_lpm->lpm.tbl8 == NULL) {
RTE_LOG(ERR, LPM, "LPM tbl8 memory allocation failed\n");
- rte_free(lpm->rules_tbl);
- rte_free(internal_lpm);
- internal_lpm = NULL;
- lpm = NULL;
+ rte_free(i_lpm->rules_tbl);
+ rte_free(i_lpm);
+ i_lpm = NULL;
rte_free(te);
rte_errno = ENOMEM;
goto exit;
}
/* Save user arguments. */
- lpm->max_rules = config->max_rules;
- lpm->number_tbl8s = config->number_tbl8s;
- strlcpy(lpm->name, name, sizeof(lpm->name));
+ i_lpm->max_rules = config->max_rules;
+ i_lpm->number_tbl8s = config->number_tbl8s;
+ strlcpy(i_lpm->name, name, sizeof(i_lpm->name));
- te->data = lpm;
+ te->data = i_lpm;
+ lpm = &i_lpm->lpm;
TAILQ_INSERT_TAIL(lpm_list, te, next);
@@ -241,13 +258,14 @@ rte_lpm_create(const char *name, int socket_id,
void
rte_lpm_free(struct rte_lpm *lpm)
{
- struct __rte_lpm *internal_lpm;
struct rte_lpm_list *lpm_list;
struct rte_tailq_entry *te;
+ struct __rte_lpm *i_lpm;
/* Check user arguments. */
if (lpm == NULL)
return;
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
@@ -255,7 +273,7 @@ rte_lpm_free(struct rte_lpm *lpm)
/* find our tailq entry */
TAILQ_FOREACH(te, lpm_list, next) {
- if (te->data == (void *) lpm)
+ if (te->data == (void *)i_lpm)
break;
}
if (te != NULL)
@@ -263,19 +281,18 @@ rte_lpm_free(struct rte_lpm *lpm)
rte_mcfg_tailq_write_unlock();
- internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
- if (internal_lpm->dq != NULL)
- rte_rcu_qsbr_dq_delete(internal_lpm->dq);
- rte_free(lpm->tbl8);
- rte_free(lpm->rules_tbl);
- rte_free(internal_lpm);
+ if (i_lpm->dq != NULL)
+ rte_rcu_qsbr_dq_delete(i_lpm->dq);
+ rte_free(i_lpm->lpm.tbl8);
+ rte_free(i_lpm->rules_tbl);
+ rte_free(i_lpm);
rte_free(te);
}
static void
__lpm_rcu_qsbr_free_resource(void *p, void *data, unsigned int n)
{
- struct rte_lpm_tbl_entry *tbl8 = ((struct rte_lpm *)p)->tbl8;
+ struct rte_lpm_tbl_entry *tbl8 = ((struct __rte_lpm *)p)->lpm.tbl8;
struct rte_lpm_tbl_entry zero_tbl8_entry = {0};
uint32_t tbl8_group_index = *(uint32_t *)data;
@@ -292,15 +309,15 @@ rte_lpm_rcu_qsbr_add(struct rte_lpm *lpm, struct rte_lpm_rcu_config *cfg)
{
struct rte_rcu_qsbr_dq_parameters params = {0};
char rcu_dq_name[RTE_RCU_QSBR_DQ_NAMESIZE];
- struct __rte_lpm *internal_lpm;
+ struct __rte_lpm *i_lpm;
if (lpm == NULL || cfg == NULL) {
rte_errno = EINVAL;
return 1;
}
- internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
- if (internal_lpm->v != NULL) {
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
+ if (i_lpm->v != NULL) {
rte_errno = EEXIST;
return 1;
}
@@ -310,21 +327,21 @@ rte_lpm_rcu_qsbr_add(struct rte_lpm *lpm, struct rte_lpm_rcu_config *cfg)
} else if (cfg->mode == RTE_LPM_QSBR_MODE_DQ) {
/* Init QSBR defer queue. */
snprintf(rcu_dq_name, sizeof(rcu_dq_name),
- "LPM_RCU_%s", lpm->name);
+ "LPM_RCU_%s", i_lpm->name);
params.name = rcu_dq_name;
params.size = cfg->dq_size;
if (params.size == 0)
- params.size = lpm->number_tbl8s;
+ params.size = i_lpm->number_tbl8s;
params.trigger_reclaim_limit = cfg->reclaim_thd;
params.max_reclaim_size = cfg->reclaim_max;
if (params.max_reclaim_size == 0)
params.max_reclaim_size = RTE_LPM_RCU_DQ_RECLAIM_MAX;
params.esize = sizeof(uint32_t); /* tbl8 group index */
params.free_fn = __lpm_rcu_qsbr_free_resource;
- params.p = lpm;
+ params.p = i_lpm;
params.v = cfg->v;
- internal_lpm->dq = rte_rcu_qsbr_dq_create(¶ms);
- if (internal_lpm->dq == NULL) {
+ i_lpm->dq = rte_rcu_qsbr_dq_create(¶ms);
+ if (i_lpm->dq == NULL) {
RTE_LOG(ERR, LPM, "LPM defer queue creation failed\n");
return 1;
}
@@ -332,8 +349,8 @@ rte_lpm_rcu_qsbr_add(struct rte_lpm *lpm, struct rte_lpm_rcu_config *cfg)
rte_errno = EINVAL;
return 1;
}
- internal_lpm->rcu_mode = cfg->mode;
- internal_lpm->v = cfg->v;
+ i_lpm->rcu_mode = cfg->mode;
+ i_lpm->v = cfg->v;
return 0;
}
@@ -349,7 +366,7 @@ rte_lpm_rcu_qsbr_add(struct rte_lpm *lpm, struct rte_lpm_rcu_config *cfg)
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static int32_t
-rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
+rule_add(struct __rte_lpm *i_lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
uint32_t rule_gindex, rule_index, last_rule;
@@ -358,68 +375,68 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
VERIFY_DEPTH(depth);
/* Scan through rule group to see if rule already exists. */
- if (lpm->rule_info[depth - 1].used_rules > 0) {
+ if (i_lpm->rule_info[depth - 1].used_rules > 0) {
/* rule_gindex stands for rule group index. */
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
+ rule_gindex = i_lpm->rule_info[depth - 1].first_rule;
/* Initialise rule_index to point to start of rule group. */
rule_index = rule_gindex;
/* Last rule = Last used rule in this rule group. */
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
+ last_rule = rule_gindex + i_lpm->rule_info[depth - 1].used_rules;
for (; rule_index < last_rule; rule_index++) {
/* If rule already exists update next hop and return. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked) {
+ if (i_lpm->rules_tbl[rule_index].ip == ip_masked) {
- if (lpm->rules_tbl[rule_index].next_hop
+ if (i_lpm->rules_tbl[rule_index].next_hop
== next_hop)
return -EEXIST;
- lpm->rules_tbl[rule_index].next_hop = next_hop;
+ i_lpm->rules_tbl[rule_index].next_hop = next_hop;
return rule_index;
}
}
- if (rule_index == lpm->max_rules)
+ if (rule_index == i_lpm->max_rules)
return -ENOSPC;
} else {
/* Calculate the position in which the rule will be stored. */
rule_index = 0;
for (i = depth - 1; i > 0; i--) {
- if (lpm->rule_info[i - 1].used_rules > 0) {
- rule_index = lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules;
+ if (i_lpm->rule_info[i - 1].used_rules > 0) {
+ rule_index = i_lpm->rule_info[i - 1].first_rule
+ + i_lpm->rule_info[i - 1].used_rules;
break;
}
}
- if (rule_index == lpm->max_rules)
+ if (rule_index == i_lpm->max_rules)
return -ENOSPC;
- lpm->rule_info[depth - 1].first_rule = rule_index;
+ i_lpm->rule_info[depth - 1].first_rule = rule_index;
}
/* Make room for the new rule in the array. */
for (i = RTE_LPM_MAX_DEPTH; i > depth; i--) {
- if (lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules == lpm->max_rules)
+ if (i_lpm->rule_info[i - 1].first_rule
+ + i_lpm->rule_info[i - 1].used_rules == i_lpm->max_rules)
return -ENOSPC;
- if (lpm->rule_info[i - 1].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules]
- = lpm->rules_tbl[lpm->rule_info[i - 1].first_rule];
- lpm->rule_info[i - 1].first_rule++;
+ if (i_lpm->rule_info[i - 1].used_rules > 0) {
+ i_lpm->rules_tbl[i_lpm->rule_info[i - 1].first_rule
+ + i_lpm->rule_info[i - 1].used_rules]
+ = i_lpm->rules_tbl[i_lpm->rule_info[i - 1].first_rule];
+ i_lpm->rule_info[i - 1].first_rule++;
}
}
/* Add the new rule. */
- lpm->rules_tbl[rule_index].ip = ip_masked;
- lpm->rules_tbl[rule_index].next_hop = next_hop;
+ i_lpm->rules_tbl[rule_index].ip = ip_masked;
+ i_lpm->rules_tbl[rule_index].next_hop = next_hop;
/* Increment the used rules counter for this rule group. */
- lpm->rule_info[depth - 1].used_rules++;
+ i_lpm->rule_info[depth - 1].used_rules++;
return rule_index;
}
@@ -429,26 +446,26 @@ rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static void
-rule_delete(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
+rule_delete(struct __rte_lpm *i_lpm, int32_t rule_index, uint8_t depth)
{
int i;
VERIFY_DEPTH(depth);
- lpm->rules_tbl[rule_index] =
- lpm->rules_tbl[lpm->rule_info[depth - 1].first_rule
- + lpm->rule_info[depth - 1].used_rules - 1];
+ i_lpm->rules_tbl[rule_index] =
+ i_lpm->rules_tbl[i_lpm->rule_info[depth - 1].first_rule
+ + i_lpm->rule_info[depth - 1].used_rules - 1];
for (i = depth; i < RTE_LPM_MAX_DEPTH; i++) {
- if (lpm->rule_info[i].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i].first_rule - 1] =
- lpm->rules_tbl[lpm->rule_info[i].first_rule
- + lpm->rule_info[i].used_rules - 1];
- lpm->rule_info[i].first_rule--;
+ if (i_lpm->rule_info[i].used_rules > 0) {
+ i_lpm->rules_tbl[i_lpm->rule_info[i].first_rule - 1] =
+ i_lpm->rules_tbl[i_lpm->rule_info[i].first_rule
+ + i_lpm->rule_info[i].used_rules - 1];
+ i_lpm->rule_info[i].first_rule--;
}
}
- lpm->rule_info[depth - 1].used_rules--;
+ i_lpm->rule_info[depth - 1].used_rules--;
}
/*
@@ -456,19 +473,19 @@ rule_delete(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
* NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
*/
static int32_t
-rule_find(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
+rule_find(struct __rte_lpm *i_lpm, uint32_t ip_masked, uint8_t depth)
{
uint32_t rule_gindex, last_rule, rule_index;
VERIFY_DEPTH(depth);
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
+ rule_gindex = i_lpm->rule_info[depth - 1].first_rule;
+ last_rule = rule_gindex + i_lpm->rule_info[depth - 1].used_rules;
/* Scan used rules at given depth to find rule. */
for (rule_index = rule_gindex; rule_index < last_rule; rule_index++) {
/* If rule is found return the rule index. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked)
+ if (i_lpm->rules_tbl[rule_index].ip == ip_masked)
return rule_index;
}
@@ -480,14 +497,14 @@ rule_find(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
* Find, clean and allocate a tbl8.
*/
static int32_t
-_tbl8_alloc(struct rte_lpm *lpm)
+_tbl8_alloc(struct __rte_lpm *i_lpm)
{
uint32_t group_idx; /* tbl8 group index. */
struct rte_lpm_tbl_entry *tbl8_entry;
/* Scan through tbl8 to find a free (i.e. INVALID) tbl8 group. */
- for (group_idx = 0; group_idx < lpm->number_tbl8s; group_idx++) {
- tbl8_entry = &lpm->tbl8[group_idx *
+ for (group_idx = 0; group_idx < i_lpm->number_tbl8s; group_idx++) {
+ tbl8_entry = &i_lpm->lpm.tbl8[group_idx *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES];
/* If a free tbl8 group is found clean it and set as VALID. */
if (!tbl8_entry->valid_group) {
@@ -515,45 +532,41 @@ _tbl8_alloc(struct rte_lpm *lpm)
}
static int32_t
-tbl8_alloc(struct rte_lpm *lpm)
+tbl8_alloc(struct __rte_lpm *i_lpm)
{
int32_t group_idx; /* tbl8 group index. */
- struct __rte_lpm *internal_lpm;
- internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
- group_idx = _tbl8_alloc(lpm);
- if (group_idx == -ENOSPC && internal_lpm->dq != NULL) {
+ group_idx = _tbl8_alloc(i_lpm);
+ if (group_idx == -ENOSPC && i_lpm->dq != NULL) {
/* If there are no tbl8 groups try to reclaim one. */
- if (rte_rcu_qsbr_dq_reclaim(internal_lpm->dq, 1,
+ if (rte_rcu_qsbr_dq_reclaim(i_lpm->dq, 1,
NULL, NULL, NULL) == 0)
- group_idx = _tbl8_alloc(lpm);
+ group_idx = _tbl8_alloc(i_lpm);
}
return group_idx;
}
static int32_t
-tbl8_free(struct rte_lpm *lpm, uint32_t tbl8_group_start)
+tbl8_free(struct __rte_lpm *i_lpm, uint32_t tbl8_group_start)
{
struct rte_lpm_tbl_entry zero_tbl8_entry = {0};
- struct __rte_lpm *internal_lpm;
int status;
- internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
- if (internal_lpm->v == NULL) {
+ if (i_lpm->v == NULL) {
/* Set tbl8 group invalid*/
- __atomic_store(&lpm->tbl8[tbl8_group_start], &zero_tbl8_entry,
+ __atomic_store(&i_lpm->lpm.tbl8[tbl8_group_start], &zero_tbl8_entry,
__ATOMIC_RELAXED);
- } else if (internal_lpm->rcu_mode == RTE_LPM_QSBR_MODE_SYNC) {
+ } else if (i_lpm->rcu_mode == RTE_LPM_QSBR_MODE_SYNC) {
/* Wait for quiescent state change. */
- rte_rcu_qsbr_synchronize(internal_lpm->v,
+ rte_rcu_qsbr_synchronize(i_lpm->v,
RTE_QSBR_THRID_INVALID);
/* Set tbl8 group invalid*/
- __atomic_store(&lpm->tbl8[tbl8_group_start], &zero_tbl8_entry,
+ __atomic_store(&i_lpm->lpm.tbl8[tbl8_group_start], &zero_tbl8_entry,
__ATOMIC_RELAXED);
- } else if (internal_lpm->rcu_mode == RTE_LPM_QSBR_MODE_DQ) {
+ } else if (i_lpm->rcu_mode == RTE_LPM_QSBR_MODE_DQ) {
/* Push into QSBR defer queue. */
- status = rte_rcu_qsbr_dq_enqueue(internal_lpm->dq,
+ status = rte_rcu_qsbr_dq_enqueue(i_lpm->dq,
(void *)&tbl8_group_start);
if (status == 1) {
RTE_LOG(ERR, LPM, "Failed to push QSBR FIFO\n");
@@ -565,7 +578,7 @@ tbl8_free(struct rte_lpm *lpm, uint32_t tbl8_group_start)
}
static __rte_noinline int32_t
-add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+add_depth_small(struct __rte_lpm *i_lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
#define group_idx next_hop
@@ -580,8 +593,8 @@ add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
* For invalid OR valid and non-extended tbl 24 entries set
* entry.
*/
- if (!lpm->tbl24[i].valid || (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth)) {
+ if (!i_lpm->lpm.tbl24[i].valid || (i_lpm->lpm.tbl24[i].valid_group == 0 &&
+ i_lpm->lpm.tbl24[i].depth <= depth)) {
struct rte_lpm_tbl_entry new_tbl24_entry = {
.next_hop = next_hop,
@@ -593,24 +606,24 @@ add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
/* Setting tbl24 entry in one go to avoid race
* conditions
*/
- __atomic_store(&lpm->tbl24[i], &new_tbl24_entry,
+ __atomic_store(&i_lpm->lpm.tbl24[i], &new_tbl24_entry,
__ATOMIC_RELEASE);
continue;
}
- if (lpm->tbl24[i].valid_group == 1) {
+ if (i_lpm->lpm.tbl24[i].valid_group == 1) {
/* If tbl24 entry is valid and extended calculate the
* index into tbl8.
*/
- tbl8_index = lpm->tbl24[i].group_idx *
+ tbl8_index = i_lpm->lpm.tbl24[i].group_idx *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
tbl8_group_end = tbl8_index +
RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
for (j = tbl8_index; j < tbl8_group_end; j++) {
- if (!lpm->tbl8[j].valid ||
- lpm->tbl8[j].depth <= depth) {
+ if (!i_lpm->lpm.tbl8[j].valid ||
+ i_lpm->lpm.tbl8[j].depth <= depth) {
struct rte_lpm_tbl_entry
new_tbl8_entry = {
.valid = VALID,
@@ -623,7 +636,7 @@ add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
* Setting tbl8 entry in one go to avoid
* race conditions
*/
- __atomic_store(&lpm->tbl8[j],
+ __atomic_store(&i_lpm->lpm.tbl8[j],
&new_tbl8_entry,
__ATOMIC_RELAXED);
@@ -637,7 +650,7 @@ add_depth_small(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
static __rte_noinline int32_t
-add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
+add_depth_big(struct __rte_lpm *i_lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
#define group_idx next_hop
@@ -648,9 +661,9 @@ add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
tbl24_index = (ip_masked >> 8);
tbl8_range = depth_to_range(depth);
- if (!lpm->tbl24[tbl24_index].valid) {
+ if (!i_lpm->lpm.tbl24[tbl24_index].valid) {
/* Search for a free tbl8 group. */
- tbl8_group_index = tbl8_alloc(lpm);
+ tbl8_group_index = tbl8_alloc(i_lpm);
/* Check tbl8 allocation was successful. */
if (tbl8_group_index < 0) {
@@ -667,10 +680,10 @@ add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
struct rte_lpm_tbl_entry new_tbl8_entry = {
.valid = VALID,
.depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
+ .valid_group = i_lpm->lpm.tbl8[i].valid_group,
.next_hop = next_hop,
};
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
+ __atomic_store(&i_lpm->lpm.tbl8[i], &new_tbl8_entry,
__ATOMIC_RELAXED);
}
@@ -690,13 +703,13 @@ add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
/* The tbl24 entry must be written only after the
* tbl8 entries are written.
*/
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
+ __atomic_store(&i_lpm->lpm.tbl24[tbl24_index], &new_tbl24_entry,
__ATOMIC_RELEASE);
} /* If valid entry but not extended calculate the index into Table8. */
- else if (lpm->tbl24[tbl24_index].valid_group == 0) {
+ else if (i_lpm->lpm.tbl24[tbl24_index].valid_group == 0) {
/* Search for free tbl8 group. */
- tbl8_group_index = tbl8_alloc(lpm);
+ tbl8_group_index = tbl8_alloc(i_lpm);
if (tbl8_group_index < 0) {
return tbl8_group_index;
@@ -711,11 +724,11 @@ add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
for (i = tbl8_group_start; i < tbl8_group_end; i++) {
struct rte_lpm_tbl_entry new_tbl8_entry = {
.valid = VALID,
- .depth = lpm->tbl24[tbl24_index].depth,
- .valid_group = lpm->tbl8[i].valid_group,
- .next_hop = lpm->tbl24[tbl24_index].next_hop,
+ .depth = i_lpm->lpm.tbl24[tbl24_index].depth,
+ .valid_group = i_lpm->lpm.tbl8[i].valid_group,
+ .next_hop = i_lpm->lpm.tbl24[tbl24_index].next_hop,
};
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
+ __atomic_store(&i_lpm->lpm.tbl8[i], &new_tbl8_entry,
__ATOMIC_RELAXED);
}
@@ -726,10 +739,10 @@ add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
struct rte_lpm_tbl_entry new_tbl8_entry = {
.valid = VALID,
.depth = depth,
- .valid_group = lpm->tbl8[i].valid_group,
+ .valid_group = i_lpm->lpm.tbl8[i].valid_group,
.next_hop = next_hop,
};
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
+ __atomic_store(&i_lpm->lpm.tbl8[i], &new_tbl8_entry,
__ATOMIC_RELAXED);
}
@@ -749,33 +762,33 @@ add_depth_big(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
/* The tbl24 entry must be written only after the
* tbl8 entries are written.
*/
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
+ __atomic_store(&i_lpm->lpm.tbl24[tbl24_index], &new_tbl24_entry,
__ATOMIC_RELEASE);
} else { /*
* If it is valid, extended entry calculate the index into tbl8.
*/
- tbl8_group_index = lpm->tbl24[tbl24_index].group_idx;
+ tbl8_group_index = i_lpm->lpm.tbl24[tbl24_index].group_idx;
tbl8_group_start = tbl8_group_index *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (!lpm->tbl8[i].valid ||
- lpm->tbl8[i].depth <= depth) {
+ if (!i_lpm->lpm.tbl8[i].valid ||
+ i_lpm->lpm.tbl8[i].depth <= depth) {
struct rte_lpm_tbl_entry new_tbl8_entry = {
.valid = VALID,
.depth = depth,
.next_hop = next_hop,
- .valid_group = lpm->tbl8[i].valid_group,
+ .valid_group = i_lpm->lpm.tbl8[i].valid_group,
};
/*
* Setting tbl8 entry in one go to avoid race
* condition
*/
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
+ __atomic_store(&i_lpm->lpm.tbl8[i], &new_tbl8_entry,
__ATOMIC_RELAXED);
continue;
@@ -794,16 +807,18 @@ rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t next_hop)
{
int32_t rule_index, status = 0;
+ struct __rte_lpm *i_lpm;
uint32_t ip_masked;
/* Check user arguments. */
if ((lpm == NULL) || (depth < 1) || (depth > RTE_LPM_MAX_DEPTH))
return -EINVAL;
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
ip_masked = ip & depth_to_mask(depth);
/* Add the rule to the rule table. */
- rule_index = rule_add(lpm, ip_masked, depth, next_hop);
+ rule_index = rule_add(i_lpm, ip_masked, depth, next_hop);
/* Skip table entries update if The rule is the same as
* the rule in the rules table.
@@ -817,16 +832,16 @@ rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
if (depth <= MAX_DEPTH_TBL24) {
- status = add_depth_small(lpm, ip_masked, depth, next_hop);
+ status = add_depth_small(i_lpm, ip_masked, depth, next_hop);
} else { /* If depth > RTE_LPM_MAX_DEPTH_TBL24 */
- status = add_depth_big(lpm, ip_masked, depth, next_hop);
+ status = add_depth_big(i_lpm, ip_masked, depth, next_hop);
/*
* If add fails due to exhaustion of tbl8 extensions delete
* rule that was added to rule table.
*/
if (status < 0) {
- rule_delete(lpm, rule_index, depth);
+ rule_delete(i_lpm, rule_index, depth);
return status;
}
@@ -842,6 +857,7 @@ int
rte_lpm_is_rule_present(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
uint32_t *next_hop)
{
+ struct __rte_lpm *i_lpm;
uint32_t ip_masked;
int32_t rule_index;
@@ -852,11 +868,12 @@ uint32_t *next_hop)
return -EINVAL;
/* Look for the rule using rule_find. */
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
ip_masked = ip & depth_to_mask(depth);
- rule_index = rule_find(lpm, ip_masked, depth);
+ rule_index = rule_find(i_lpm, ip_masked, depth);
if (rule_index >= 0) {
- *next_hop = lpm->rules_tbl[rule_index].next_hop;
+ *next_hop = i_lpm->rules_tbl[rule_index].next_hop;
return 1;
}
@@ -865,7 +882,7 @@ uint32_t *next_hop)
}
static int32_t
-find_previous_rule(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
+find_previous_rule(struct __rte_lpm *i_lpm, uint32_t ip, uint8_t depth,
uint8_t *sub_rule_depth)
{
int32_t rule_index;
@@ -875,7 +892,7 @@ find_previous_rule(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
for (prev_depth = (uint8_t)(depth - 1); prev_depth > 0; prev_depth--) {
ip_masked = ip & depth_to_mask(prev_depth);
- rule_index = rule_find(lpm, ip_masked, prev_depth);
+ rule_index = rule_find(i_lpm, ip_masked, prev_depth);
if (rule_index >= 0) {
*sub_rule_depth = prev_depth;
@@ -887,7 +904,7 @@ find_previous_rule(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
}
static int32_t
-delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
+delete_depth_small(struct __rte_lpm *i_lpm, uint32_t ip_masked,
uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
{
#define group_idx next_hop
@@ -909,26 +926,26 @@ delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
*/
for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
- if (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth) {
- __atomic_store(&lpm->tbl24[i],
+ if (i_lpm->lpm.tbl24[i].valid_group == 0 &&
+ i_lpm->lpm.tbl24[i].depth <= depth) {
+ __atomic_store(&i_lpm->lpm.tbl24[i],
&zero_tbl24_entry, __ATOMIC_RELEASE);
- } else if (lpm->tbl24[i].valid_group == 1) {
+ } else if (i_lpm->lpm.tbl24[i].valid_group == 1) {
/*
* If TBL24 entry is extended, then there has
* to be a rule with depth >= 25 in the
* associated TBL8 group.
*/
- tbl8_group_index = lpm->tbl24[i].group_idx;
+ tbl8_group_index = i_lpm->lpm.tbl24[i].group_idx;
tbl8_index = tbl8_group_index *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
for (j = tbl8_index; j < (tbl8_index +
RTE_LPM_TBL8_GROUP_NUM_ENTRIES); j++) {
- if (lpm->tbl8[j].depth <= depth)
- lpm->tbl8[j].valid = INVALID;
+ if (i_lpm->lpm.tbl8[j].depth <= depth)
+ i_lpm->lpm.tbl8[j].valid = INVALID;
}
}
}
@@ -939,7 +956,7 @@ delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
*/
struct rte_lpm_tbl_entry new_tbl24_entry = {
- .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
+ .next_hop = i_lpm->rules_tbl[sub_rule_index].next_hop,
.valid = VALID,
.valid_group = 0,
.depth = sub_rule_depth,
@@ -949,32 +966,32 @@ delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
.valid = VALID,
.valid_group = VALID,
.depth = sub_rule_depth,
- .next_hop = lpm->rules_tbl
+ .next_hop = i_lpm->rules_tbl
[sub_rule_index].next_hop,
};
for (i = tbl24_index; i < (tbl24_index + tbl24_range); i++) {
- if (lpm->tbl24[i].valid_group == 0 &&
- lpm->tbl24[i].depth <= depth) {
- __atomic_store(&lpm->tbl24[i], &new_tbl24_entry,
+ if (i_lpm->lpm.tbl24[i].valid_group == 0 &&
+ i_lpm->lpm.tbl24[i].depth <= depth) {
+ __atomic_store(&i_lpm->lpm.tbl24[i], &new_tbl24_entry,
__ATOMIC_RELEASE);
- } else if (lpm->tbl24[i].valid_group == 1) {
+ } else if (i_lpm->lpm.tbl24[i].valid_group == 1) {
/*
* If TBL24 entry is extended, then there has
* to be a rule with depth >= 25 in the
* associated TBL8 group.
*/
- tbl8_group_index = lpm->tbl24[i].group_idx;
+ tbl8_group_index = i_lpm->lpm.tbl24[i].group_idx;
tbl8_index = tbl8_group_index *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
for (j = tbl8_index; j < (tbl8_index +
RTE_LPM_TBL8_GROUP_NUM_ENTRIES); j++) {
- if (lpm->tbl8[j].depth <= depth)
- __atomic_store(&lpm->tbl8[j],
+ if (i_lpm->lpm.tbl8[j].depth <= depth)
+ __atomic_store(&i_lpm->lpm.tbl8[j],
&new_tbl8_entry,
__ATOMIC_RELAXED);
}
@@ -1041,7 +1058,7 @@ tbl8_recycle_check(struct rte_lpm_tbl_entry *tbl8,
}
static int32_t
-delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
+delete_depth_big(struct __rte_lpm *i_lpm, uint32_t ip_masked,
uint8_t depth, int32_t sub_rule_index, uint8_t sub_rule_depth)
{
#define group_idx next_hop
@@ -1056,7 +1073,7 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
tbl24_index = ip_masked >> 8;
/* Calculate the index into tbl8 and range. */
- tbl8_group_index = lpm->tbl24[tbl24_index].group_idx;
+ tbl8_group_index = i_lpm->lpm.tbl24[tbl24_index].group_idx;
tbl8_group_start = tbl8_group_index * RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
tbl8_range = depth_to_range(depth);
@@ -1067,16 +1084,16 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
* rule_to_delete must be removed or modified.
*/
for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (lpm->tbl8[i].depth <= depth)
- lpm->tbl8[i].valid = INVALID;
+ if (i_lpm->lpm.tbl8[i].depth <= depth)
+ i_lpm->lpm.tbl8[i].valid = INVALID;
}
} else {
/* Set new tbl8 entry. */
struct rte_lpm_tbl_entry new_tbl8_entry = {
.valid = VALID,
.depth = sub_rule_depth,
- .valid_group = lpm->tbl8[tbl8_group_start].valid_group,
- .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
+ .valid_group = i_lpm->lpm.tbl8[tbl8_group_start].valid_group,
+ .next_hop = i_lpm->rules_tbl[sub_rule_index].next_hop,
};
/*
@@ -1084,8 +1101,8 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
* rule_to_delete must be modified.
*/
for (i = tbl8_index; i < (tbl8_index + tbl8_range); i++) {
- if (lpm->tbl8[i].depth <= depth)
- __atomic_store(&lpm->tbl8[i], &new_tbl8_entry,
+ if (i_lpm->lpm.tbl8[i].depth <= depth)
+ __atomic_store(&i_lpm->lpm.tbl8[i], &new_tbl8_entry,
__ATOMIC_RELAXED);
}
}
@@ -1096,31 +1113,31 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
* associated tbl24 entry.
*/
- tbl8_recycle_index = tbl8_recycle_check(lpm->tbl8, tbl8_group_start);
+ tbl8_recycle_index = tbl8_recycle_check(i_lpm->lpm.tbl8, tbl8_group_start);
if (tbl8_recycle_index == -EINVAL) {
/* Set tbl24 before freeing tbl8 to avoid race condition.
* Prevent the free of the tbl8 group from hoisting.
*/
- lpm->tbl24[tbl24_index].valid = 0;
+ i_lpm->lpm.tbl24[tbl24_index].valid = 0;
__atomic_thread_fence(__ATOMIC_RELEASE);
- status = tbl8_free(lpm, tbl8_group_start);
+ status = tbl8_free(i_lpm, tbl8_group_start);
} else if (tbl8_recycle_index > -1) {
/* Update tbl24 entry. */
struct rte_lpm_tbl_entry new_tbl24_entry = {
- .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop,
+ .next_hop = i_lpm->lpm.tbl8[tbl8_recycle_index].next_hop,
.valid = VALID,
.valid_group = 0,
- .depth = lpm->tbl8[tbl8_recycle_index].depth,
+ .depth = i_lpm->lpm.tbl8[tbl8_recycle_index].depth,
};
/* Set tbl24 before freeing tbl8 to avoid race condition.
* Prevent the free of the tbl8 group from hoisting.
*/
- __atomic_store(&lpm->tbl24[tbl24_index], &new_tbl24_entry,
+ __atomic_store(&i_lpm->lpm.tbl24[tbl24_index], &new_tbl24_entry,
__ATOMIC_RELAXED);
__atomic_thread_fence(__ATOMIC_RELEASE);
- status = tbl8_free(lpm, tbl8_group_start);
+ status = tbl8_free(i_lpm, tbl8_group_start);
}
#undef group_idx
return status;
@@ -1133,6 +1150,7 @@ int
rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
{
int32_t rule_to_delete_index, sub_rule_index;
+ struct __rte_lpm *i_lpm;
uint32_t ip_masked;
uint8_t sub_rule_depth;
/*
@@ -1143,13 +1161,14 @@ rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
return -EINVAL;
}
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
ip_masked = ip & depth_to_mask(depth);
/*
* Find the index of the input rule, that needs to be deleted, in the
* rule table.
*/
- rule_to_delete_index = rule_find(lpm, ip_masked, depth);
+ rule_to_delete_index = rule_find(i_lpm, ip_masked, depth);
/*
* Check if rule_to_delete_index was found. If no rule was found the
@@ -1159,7 +1178,7 @@ rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
return -EINVAL;
/* Delete the rule from the rule table. */
- rule_delete(lpm, rule_to_delete_index, depth);
+ rule_delete(i_lpm, rule_to_delete_index, depth);
/*
* Find rule to replace the rule_to_delete. If there is no rule to
@@ -1167,17 +1186,17 @@ rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
* entries associated with this rule.
*/
sub_rule_depth = 0;
- sub_rule_index = find_previous_rule(lpm, ip, depth, &sub_rule_depth);
+ sub_rule_index = find_previous_rule(i_lpm, ip, depth, &sub_rule_depth);
/*
* If the input depth value is less than 25 use function
* delete_depth_small otherwise use delete_depth_big.
*/
if (depth <= MAX_DEPTH_TBL24) {
- return delete_depth_small(lpm, ip_masked, depth,
+ return delete_depth_small(i_lpm, ip_masked, depth,
sub_rule_index, sub_rule_depth);
} else { /* If depth > MAX_DEPTH_TBL24 */
- return delete_depth_big(lpm, ip_masked, depth, sub_rule_index,
+ return delete_depth_big(i_lpm, ip_masked, depth, sub_rule_index,
sub_rule_depth);
}
}
@@ -1188,16 +1207,19 @@ rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
void
rte_lpm_delete_all(struct rte_lpm *lpm)
{
+ struct __rte_lpm *i_lpm;
+
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
/* Zero rule information. */
- memset(lpm->rule_info, 0, sizeof(lpm->rule_info));
+ memset(i_lpm->rule_info, 0, sizeof(i_lpm->rule_info));
/* Zero tbl24. */
- memset(lpm->tbl24, 0, sizeof(lpm->tbl24));
+ memset(i_lpm->lpm.tbl24, 0, sizeof(i_lpm->lpm.tbl24));
/* Zero tbl8. */
- memset(lpm->tbl8, 0, sizeof(lpm->tbl8[0])
- * RTE_LPM_TBL8_GROUP_NUM_ENTRIES * lpm->number_tbl8s);
+ memset(i_lpm->lpm.tbl8, 0, sizeof(i_lpm->lpm.tbl8[0])
+ * RTE_LPM_TBL8_GROUP_NUM_ENTRIES * i_lpm->number_tbl8s);
/* Delete all rules form the rules table. */
- memset(lpm->rules_tbl, 0, sizeof(lpm->rules_tbl[0]) * lpm->max_rules);
+ memset(i_lpm->rules_tbl, 0, sizeof(i_lpm->rules_tbl[0]) * i_lpm->max_rules);
}
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 5b3b7b5b58..1afe55cdcb 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -118,31 +118,12 @@ struct rte_lpm_config {
int flags; /**< This field is currently unused. */
};
-/** @internal Rule structure. */
-struct rte_lpm_rule {
- uint32_t ip; /**< Rule IP address. */
- uint32_t next_hop; /**< Rule next hop. */
-};
-
-/** @internal Contains metadata about the rules table. */
-struct rte_lpm_rule_info {
- uint32_t used_rules; /**< Used rules so far. */
- uint32_t first_rule; /**< Indexes the first rule of a given depth. */
-};
-
/** @internal LPM structure. */
struct rte_lpm {
- /* LPM metadata. */
- char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
- uint32_t max_rules; /**< Max. balanced rules per lpm. */
- uint32_t number_tbl8s; /**< Number of tbl8s. */
- struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**< Rule info table. */
-
/* LPM Tables. */
struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
__rte_cache_aligned; /**< LPM tbl24 table. */
struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
- struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
};
/** LPM RCU QSBR configuration structure. */
--
2.23.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 5/5] doc: change references to blacklist and whitelist
@ 2020-10-22 20:40 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-22 20:40 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Luca Boccassi, Akhil Goyal, Hemant Agrawal,
John Griffin, Fiona Trahe, Deepak Kumar Jain, Pavan Nikhilesh,
Jerin Jacob, Bruce Richardson, Nithin Dabilpuram, Ajit Khaparde,
Somnath Kotur, Rahul Lakkireddy, Sachin Saxena, John Daley,
Hyong Youb Kim, Gaetan Rivet, Beilei Xing, Jeff Guo, Qiming Yang,
Qi Zhang, Haiyue Wang, Matan Azrad, Shahaf Shuler,
Viacheslav Ovsiienko, Martin Spinler, Kiran Kumar K,
Andrew Rybchenko, Keith Wiles, Maciej Czekaj, Anatoly Burakov,
Thomas Monjalon, Ferruh Yigit, Nicolas Chautru, Harry van Haaren,
Radu Nicolau, Konstantin Ananyev, David Hunt, Maxime Coquelin,
Chenbo Xia, Declan Doherty, Wisam Jaddo
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 18 ++++++------
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 18 ++++++------
doc/guides/nics/mlx5.rst | 14 +++++-----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 22 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 6 ++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 2 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 171 insertions(+), 154 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 3053636b8295..b50fee76954a 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index db3c8e918945..38ad45e66d76 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index a0becf689109..d41ee82aff52 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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.
@@ -264,7 +264,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 CONFIG_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
@@ -302,7 +302,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
@@ -662,7 +662,7 @@ QAT SYM crypto PMD can be tested by running the test application::
make defconfig
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_autotest
QAT ASYM crypto PMD can be tested by running the test application::
@@ -670,7 +670,7 @@ QAT ASYM crypto PMD can be tested by running the test application::
make defconfig
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_asym_autotest
QAT compression PMD can be tested by running the test application::
@@ -679,7 +679,7 @@ QAT compression PMD can be tested by running the test application::
sed -i 's,\(CONFIG_RTE_COMPRESSDEV_TEST\)=n,\1=y,' build/.config
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>compressdev_autotest
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 6502f6415fb4..1c671518a4db 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -66,7 +66,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``
@@ -74,7 +74,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``
@@ -89,7 +89,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``
@@ -98,7 +98,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``
@@ -107,7 +107,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``
@@ -118,7 +118,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``
@@ -126,7 +126,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``
@@ -136,7 +136,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``
@@ -146,7 +146,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``
@@ -156,7 +156,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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 49b45a04e8ec..efaef85f90fc 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -50,7 +50,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.
@@ -69,7 +69,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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 28973fc3e2e9..37c632c3f046 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -686,7 +686,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
-----
@@ -728,7 +728,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
@@ -753,12 +753,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 54a4c138998c..ee91c85ebfee 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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:
@@ -112,7 +112,7 @@ be passed as part of EAL arguments. For example,
.. code-block:: console
- testpmd -w 02:00.4,keep_ovlan=1 -- -i
+ testpmd -a 02:00.4,keep_ovlan=1 -- -i
Common Runtime Options
^^^^^^^^^^^^^^^^^^^^^^
@@ -317,7 +317,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
- testpmd -w 02:00.4,filtermode=0x88 -- -i
+ testpmd -a 02:00.4,filtermode=0x88 -- -i
- ``filtermask`` (default **0**)
@@ -344,7 +344,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
- testpmd -w 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
+ testpmd -a 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
.. _driver-compilation:
@@ -776,7 +776,7 @@ devices managed by librte_pmd_cxgbe in FreeBSD operating system.
.. code-block:: console
- ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
+ ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -a 0000:02:00.4 -- -i
Example output:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 74d4a6058ef0..eb9defca0f09 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index ca6ba5b5e291..693be5ce8707 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -527,10 +527,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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index a28a7f4e477a..fa8459435730 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -312,7 +312,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
@@ -378,7 +378,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``).
@@ -427,7 +427,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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index f80346a35898..25525ef19aad 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -60,7 +60,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
@@ -68,11 +68,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.
@@ -123,8 +123,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
@@ -132,13 +132,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 16e00b8f64b5..14b8d0f33fae 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a0b81e66950f..0eb1d7c1af2f 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -194,7 +194,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
@@ -207,7 +207,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
@@ -222,7 +222,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.
@@ -234,7 +234,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``)
@@ -244,7 +244,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -479,7 +479,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.
@@ -487,7 +487,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.
@@ -822,7 +822,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::
- ./l3fwd -l 18-21 -n 4 -w 82:00.0 -w 85:00.0 \
+ ./l3fwd -l 18-21 -n 4 -a 82:00.0 -w 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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 25a821177a4c..bb76d62a0139 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -47,7 +47,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,
@@ -58,7 +58,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -70,7 +70,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -79,8 +91,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.
@@ -91,14 +103,14 @@ Runtime Config Options
.. code-block:: console
- testpmd -w 18:00.0,proto_xtr='[(1,2-3,8-9):tcp,10-13:vlan]'
+ 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
- testpmd -w 18:00.0,proto_xtr=vlan,proto_xtr='[(1,2-3,8-9):tcp,10-23:ipv6]'
+ 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.
@@ -250,7 +262,7 @@ responses for the same from PF.
#. Bind the VF0, and run testpmd with 'cap=dcf' devarg::
- testpmd -l 22-25 -n 4 -w 18:01.0,cap=dcf -- -i
+ testpmd -l 22-25 -n 4 -a 18:01.0,cap=dcf -- -i
#. Monitor the VF2 interface network traffic::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 6818b6af515e..428e71d88687 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -29,8 +29,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -422,7 +422,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -430,14 +430,14 @@ devices managed by librte_pmd_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::
@@ -450,7 +450,7 @@ devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a071db276fe4..9f0dc8388951 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1537,7 +1537,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1545,14 +1545,14 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
@@ -1560,7 +1560,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index 10f33a025ede..7766a76d7a6d 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -78,7 +78,7 @@ products) and the device argument `timestamp=1` must be used.
.. code-block:: console
- $RTE_TARGET/app/testpmd -w b3:00.0,timestamp=1 <other EAL params> -- <testpmd params>
+ $RTE_TARGET/app/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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index f3be79bbb8a3..9862a1d4508c 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -74,7 +74,7 @@ use arm64-octeontx2-linux-gcc as target.
.. code-block:: console
- ./build/app/testpmd -c 0x300 -w 0002:02:00.0 -- --portmask=0x1 --nb-cores=1 --port-topology=loop --rxq=1 --txq=1
+ ./build/app/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
@@ -127,7 +127,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.
@@ -138,7 +138,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.
@@ -150,7 +150,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.
@@ -162,7 +162,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.
@@ -174,7 +174,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
@@ -196,7 +196,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``)
@@ -205,7 +205,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).
@@ -216,7 +216,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``
@@ -224,7 +224,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::
@@ -240,7 +240,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index b1ef9eba59b8..db64503a9ab8 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -178,7 +178,7 @@ This section provides instructions to configure SR-IOV with Linux OS.
.. code-block:: console
- ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
+ ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -a 0002:01:00.2 \
-- -i --no-flush-rx \
--port-topology=loop
@@ -398,7 +398,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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 0d45b500325f..28ab5a03be8c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -539,6 +539,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 54ff6574aed8..f0947a7544e4 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -79,19 +79,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/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
+ $ ./build/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,
@@ -111,20 +111,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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index dc7972aa9a5c..e4c23da9ebcb 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -46,7 +46,7 @@ these settings is shown below:
.. code-block:: console
- ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
+ ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -i 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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 434f484138d0..db2685660ff7 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -329,15 +329,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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting all hardware crypto devices.
For example, something like the following command line:
.. code-block:: console
./build/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)" \
@@ -935,13 +935,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
@@ -1029,4 +1029,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 07c8d44936d6..5173da8b108a 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,17 @@ Following is the sample command:
.. code-block:: console
- ./build/l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x3 --eventq-sched=ordered
+ ./build/l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered
or
.. code-block:: console
- ./build/l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x03 --mode=eventdev --eventq-sched=ordered
+ ./build/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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index c2d4ca73abde..1e580ff86cf4 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index f05816d9b24e..bc162a0118ac 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -378,7 +378,7 @@ See :doc:`Power Management<../prog_guide/power_man>` chapter in the DPDK Program
.. code-block:: console
- ./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
+ ./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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index d66a724827af..60a7eb227db2 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -52,7 +52,7 @@ Take IFCVF driver for example:
.. code-block:: console
./vdpa -c 0x2 -n 4 --socket-mem 1024,1024 \
- -w 0000:06:00.3,vdpa=1 -w 0000:06:00.4,vdpa=1 \
+ -i 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 28b729dbda8b..72707e9a4a9d 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -417,7 +417,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
@@ -427,7 +427,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
@@ -437,7 +437,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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v3 5/5] doc: change references to blacklist and whitelist
@ 2020-10-22 14:39 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-22 14:39 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Luca Boccassi, Akhil Goyal, Hemant Agrawal,
John Griffin, Fiona Trahe, Deepak Kumar Jain, Pavan Nikhilesh,
Jerin Jacob, Bruce Richardson, Nithin Dabilpuram, Ajit Khaparde,
Somnath Kotur, Rahul Lakkireddy, Sachin Saxena, John Daley,
Hyong Youb Kim, Gaetan Rivet, Beilei Xing, Jeff Guo, Qiming Yang,
Qi Zhang, Haiyue Wang, Matan Azrad, Shahaf Shuler,
Viacheslav Ovsiienko, Martin Spinler, Kiran Kumar K,
Andrew Rybchenko, Keith Wiles, Maciej Czekaj, Anatoly Burakov,
Thomas Monjalon, Ferruh Yigit, Nicolas Chautru, Harry van Haaren,
Radu Nicolau, Konstantin Ananyev, David Hunt, Maxime Coquelin,
Chenbo Xia, Declan Doherty, Wisam Jaddo
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 12 ++++----
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 16 +++++------
doc/guides/nics/mlx5.rst | 12 ++++----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 22 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 6 ++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 2 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 166 insertions(+), 149 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 3053636b8295..b50fee76954a 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index db3c8e918945..38ad45e66d76 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index a0becf689109..d41ee82aff52 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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.
@@ -264,7 +264,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 CONFIG_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
@@ -302,7 +302,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
@@ -662,7 +662,7 @@ QAT SYM crypto PMD can be tested by running the test application::
make defconfig
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_autotest
QAT ASYM crypto PMD can be tested by running the test application::
@@ -670,7 +670,7 @@ QAT ASYM crypto PMD can be tested by running the test application::
make defconfig
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_asym_autotest
QAT compression PMD can be tested by running the test application::
@@ -679,7 +679,7 @@ QAT compression PMD can be tested by running the test application::
sed -i 's,\(CONFIG_RTE_COMPRESSDEV_TEST\)=n,\1=y,' build/.config
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>compressdev_autotest
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 6502f6415fb4..1c671518a4db 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -66,7 +66,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``
@@ -74,7 +74,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``
@@ -89,7 +89,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``
@@ -98,7 +98,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``
@@ -107,7 +107,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``
@@ -118,7 +118,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``
@@ -126,7 +126,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``
@@ -136,7 +136,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``
@@ -146,7 +146,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``
@@ -156,7 +156,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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 49b45a04e8ec..efaef85f90fc 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -50,7 +50,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.
@@ -69,7 +69,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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 28973fc3e2e9..82cabab6885d 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -728,7 +728,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 54a4c138998c..ee91c85ebfee 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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:
@@ -112,7 +112,7 @@ be passed as part of EAL arguments. For example,
.. code-block:: console
- testpmd -w 02:00.4,keep_ovlan=1 -- -i
+ testpmd -a 02:00.4,keep_ovlan=1 -- -i
Common Runtime Options
^^^^^^^^^^^^^^^^^^^^^^
@@ -317,7 +317,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
- testpmd -w 02:00.4,filtermode=0x88 -- -i
+ testpmd -a 02:00.4,filtermode=0x88 -- -i
- ``filtermask`` (default **0**)
@@ -344,7 +344,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
- testpmd -w 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
+ testpmd -a 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
.. _driver-compilation:
@@ -776,7 +776,7 @@ devices managed by librte_pmd_cxgbe in FreeBSD operating system.
.. code-block:: console
- ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
+ ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -a 0000:02:00.4 -- -i
Example output:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 74d4a6058ef0..eb9defca0f09 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index ca6ba5b5e291..693be5ce8707 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -527,10 +527,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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index a28a7f4e477a..fa8459435730 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -312,7 +312,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
@@ -378,7 +378,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``).
@@ -427,7 +427,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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index f80346a35898..25525ef19aad 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -60,7 +60,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
@@ -68,11 +68,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.
@@ -123,8 +123,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
@@ -132,13 +132,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 16e00b8f64b5..14b8d0f33fae 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a0b81e66950f..0eb1d7c1af2f 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -194,7 +194,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
@@ -207,7 +207,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
@@ -222,7 +222,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.
@@ -234,7 +234,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``)
@@ -244,7 +244,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -479,7 +479,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.
@@ -487,7 +487,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.
@@ -822,7 +822,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::
- ./l3fwd -l 18-21 -n 4 -w 82:00.0 -w 85:00.0 \
+ ./l3fwd -l 18-21 -n 4 -a 82:00.0 -w 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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 25a821177a4c..bb76d62a0139 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -47,7 +47,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,
@@ -58,7 +58,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -70,7 +70,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -79,8 +91,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.
@@ -91,14 +103,14 @@ Runtime Config Options
.. code-block:: console
- testpmd -w 18:00.0,proto_xtr='[(1,2-3,8-9):tcp,10-13:vlan]'
+ 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
- testpmd -w 18:00.0,proto_xtr=vlan,proto_xtr='[(1,2-3,8-9):tcp,10-23:ipv6]'
+ 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.
@@ -250,7 +262,7 @@ responses for the same from PF.
#. Bind the VF0, and run testpmd with 'cap=dcf' devarg::
- testpmd -l 22-25 -n 4 -w 18:01.0,cap=dcf -- -i
+ testpmd -l 22-25 -n 4 -a 18:01.0,cap=dcf -- -i
#. Monitor the VF2 interface network traffic::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 6818b6af515e..67e3964b2b3b 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -29,8 +29,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -422,7 +422,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -434,10 +434,10 @@ devices managed by librte_pmd_mlx4.
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::
@@ -450,7 +450,7 @@ devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a071db276fe4..b44490cfe5e4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1537,7 +1537,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1549,10 +1549,10 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
Example output::
- -w 0000:05:00.1
- -w 0000:06:00.0
- -w 0000:06:00.1
- -w 0000:05:00.0
+ -i 0000:05:00.1
+ -i 0000:06:00.0
+ -i 0000:06:00.1
+ -i 0000:05:00.0
#. Request huge pages::
@@ -1560,7 +1560,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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 -i 05:00.0 -w 05:00.1 -w 06:00.0 -w 06:00.1 -- --rxq=2 --txq=2 -i
Example output::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index 10f33a025ede..7766a76d7a6d 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -78,7 +78,7 @@ products) and the device argument `timestamp=1` must be used.
.. code-block:: console
- $RTE_TARGET/app/testpmd -w b3:00.0,timestamp=1 <other EAL params> -- <testpmd params>
+ $RTE_TARGET/app/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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index f3be79bbb8a3..9862a1d4508c 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -74,7 +74,7 @@ use arm64-octeontx2-linux-gcc as target.
.. code-block:: console
- ./build/app/testpmd -c 0x300 -w 0002:02:00.0 -- --portmask=0x1 --nb-cores=1 --port-topology=loop --rxq=1 --txq=1
+ ./build/app/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
@@ -127,7 +127,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.
@@ -138,7 +138,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.
@@ -150,7 +150,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.
@@ -162,7 +162,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.
@@ -174,7 +174,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
@@ -196,7 +196,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``)
@@ -205,7 +205,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).
@@ -216,7 +216,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``
@@ -224,7 +224,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::
@@ -240,7 +240,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index b1ef9eba59b8..db64503a9ab8 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -178,7 +178,7 @@ This section provides instructions to configure SR-IOV with Linux OS.
.. code-block:: console
- ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
+ ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -a 0002:01:00.2 \
-- -i --no-flush-rx \
--port-topology=loop
@@ -398,7 +398,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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 0d45b500325f..28ab5a03be8c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -539,6 +539,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 54ff6574aed8..f0947a7544e4 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -79,19 +79,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/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
+ $ ./build/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,
@@ -111,20 +111,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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index dc7972aa9a5c..e4c23da9ebcb 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -46,7 +46,7 @@ these settings is shown below:
.. code-block:: console
- ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
+ ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -i 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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 434f484138d0..db2685660ff7 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -329,15 +329,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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting all hardware crypto devices.
For example, something like the following command line:
.. code-block:: console
./build/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)" \
@@ -935,13 +935,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
@@ -1029,4 +1029,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 07c8d44936d6..5173da8b108a 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,17 @@ Following is the sample command:
.. code-block:: console
- ./build/l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x3 --eventq-sched=ordered
+ ./build/l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered
or
.. code-block:: console
- ./build/l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x03 --mode=eventdev --eventq-sched=ordered
+ ./build/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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index c2d4ca73abde..1e580ff86cf4 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index f05816d9b24e..bc162a0118ac 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -378,7 +378,7 @@ See :doc:`Power Management<../prog_guide/power_man>` chapter in the DPDK Program
.. code-block:: console
- ./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
+ ./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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index d66a724827af..60a7eb227db2 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -52,7 +52,7 @@ Take IFCVF driver for example:
.. code-block:: console
./vdpa -c 0x2 -n 4 --socket-mem 1024,1024 \
- -w 0000:06:00.3,vdpa=1 -w 0000:06:00.4,vdpa=1 \
+ -i 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 28b729dbda8b..72707e9a4a9d 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -417,7 +417,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
@@ -427,7 +427,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
@@ -437,7 +437,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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH] build: fix version map file references in documentation
2020-10-22 12:11 3% ` David Marchand
@ 2020-10-22 14:24 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-22 14:24 UTC (permalink / raw)
To: David Marchand, dev
Cc: Thomas Monjalon, Bruce Richardson, Neil Horman, Rosen Xu,
Andrew Rybchenko, Luca Boccassi
No worries, happy to.
On 22/10/2020 13:11, David Marchand wrote:
> On Thu, Oct 22, 2020 at 9:47 AM David Marchand
> <david.marchand@redhat.com> wrote:
>>
>> Fixes: 63b3907833d8 ("build: remove library name from version map file name")
>>
>> Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
> Applied, thanks.
>
> Ray, I'll let you update the documentation with better examples on the
> ABI version.
> Thanks.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] build: fix version map file references in documentation
2020-10-22 7:47 3% [dpdk-dev] [PATCH] build: fix version map file references in documentation David Marchand
2020-10-22 7:52 0% ` Kinsella, Ray
@ 2020-10-22 12:11 3% ` David Marchand
2020-10-22 14:24 0% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2020-10-22 12:11 UTC (permalink / raw)
To: dev, Ray Kinsella
Cc: Thomas Monjalon, Bruce Richardson, Neil Horman, Rosen Xu,
Andrew Rybchenko, Luca Boccassi
On Thu, Oct 22, 2020 at 9:47 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> Fixes: 63b3907833d8 ("build: remove library name from version map file name")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
Ray, I'll let you update the documentation with better examples on the
ABI version.
Thanks.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] build: fix version map file references in documentation
2020-10-22 7:47 3% [dpdk-dev] [PATCH] build: fix version map file references in documentation David Marchand
@ 2020-10-22 7:52 0% ` Kinsella, Ray
2020-10-22 12:11 3% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-22 7:52 UTC (permalink / raw)
To: David Marchand, dev
Cc: thomas, bruce.richardson, Neil Horman, Rosen Xu,
Andrew Rybchenko, Luca Boccassi
On 22/10/2020 08:47, David Marchand wrote:
> Fixes: 63b3907833d8 ("build: remove library name from version map file name")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Note: we might want to update the ABI version in the examples shown in
> the documentation. I can send a followup patch.
I was thinking similar, I can do it also.
> ---
> doc/guides/contributing/abi_versioning.rst | 14 +++++++-------
> lib/librte_eal/include/rte_function_versioning.h | 2 +-
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
> index 7a771dba10..b8b35761e2 100644
> --- a/doc/guides/contributing/abi_versioning.rst
> +++ b/doc/guides/contributing/abi_versioning.rst
> @@ -58,12 +58,12 @@ persists over multiple releases.
>
> .. code-block:: none
>
> - $ head ./lib/librte_acl/rte_acl_version.map
> + $ head ./lib/librte_acl/version.map
> DPDK_20 {
> global:
> ...
>
> - $ head ./lib/librte_eal/rte_eal_version.map
> + $ head ./lib/librte_eal/version.map
> DPDK_20 {
> global:
> ...
> @@ -77,7 +77,7 @@ that library.
>
> .. code-block:: none
>
> - $ head ./lib/librte_acl/rte_acl_version.map
> + $ head ./lib/librte_acl/version.map
> DPDK_20 {
> global:
> ...
> @@ -88,7 +88,7 @@ that library.
> } DPDK_20;
> ...
>
> - $ head ./lib/librte_eal/rte_eal_version.map
> + $ head ./lib/librte_eal/version.map
> DPDK_20 {
> global:
> ...
> @@ -100,12 +100,12 @@ how this may be done.
>
> .. code-block:: none
>
> - $ head ./lib/librte_acl/rte_acl_version.map
> + $ head ./lib/librte_acl/version.map
> DPDK_21 {
> global:
> ...
>
> - $ head ./lib/librte_eal/rte_eal_version.map
> + $ head ./lib/librte_eal/version.map
> DPDK_21 {
> global:
> ...
> @@ -134,7 +134,7 @@ linked to the DPDK.
>
> To support backward compatibility the ``rte_function_versioning.h``
> header file provides macros to use when updating exported functions. These
> -macros are used in conjunction with the ``rte_<library>_version.map`` file for
> +macros are used in conjunction with the ``version.map`` file for
> a given library to allow multiple versions of a symbol to exist in a shared
> library so that older binaries need not be immediately recompiled.
>
> diff --git a/lib/librte_eal/include/rte_function_versioning.h b/lib/librte_eal/include/rte_function_versioning.h
> index f588f2643b..746a1e1992 100644
> --- a/lib/librte_eal/include/rte_function_versioning.h
> +++ b/lib/librte_eal/include/rte_function_versioning.h
> @@ -22,7 +22,7 @@
> * allow for backwards compatibility for a time with older binaries that are
> * dynamically linked to the dpdk. To support that, the __vsym and
> * VERSION_SYMBOL macros are created. They, in conjunction with the
> - * <library>_version.map file for a given library allow for multiple versions of
> + * version.map file for a given library allow for multiple versions of
> * a symbol to exist in a shared library so that older binaries need not be
> * immediately recompiled.
> *
>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] build: fix version map file references in documentation
@ 2020-10-22 7:47 3% David Marchand
2020-10-22 7:52 0% ` Kinsella, Ray
2020-10-22 12:11 3% ` David Marchand
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2020-10-22 7:47 UTC (permalink / raw)
To: dev
Cc: thomas, bruce.richardson, Ray Kinsella, Neil Horman, Rosen Xu,
Andrew Rybchenko, Luca Boccassi
Fixes: 63b3907833d8 ("build: remove library name from version map file name")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Note: we might want to update the ABI version in the examples shown in
the documentation. I can send a followup patch.
---
doc/guides/contributing/abi_versioning.rst | 14 +++++++-------
lib/librte_eal/include/rte_function_versioning.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index 7a771dba10..b8b35761e2 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -58,12 +58,12 @@ persists over multiple releases.
.. code-block:: none
- $ head ./lib/librte_acl/rte_acl_version.map
+ $ head ./lib/librte_acl/version.map
DPDK_20 {
global:
...
- $ head ./lib/librte_eal/rte_eal_version.map
+ $ head ./lib/librte_eal/version.map
DPDK_20 {
global:
...
@@ -77,7 +77,7 @@ that library.
.. code-block:: none
- $ head ./lib/librte_acl/rte_acl_version.map
+ $ head ./lib/librte_acl/version.map
DPDK_20 {
global:
...
@@ -88,7 +88,7 @@ that library.
} DPDK_20;
...
- $ head ./lib/librte_eal/rte_eal_version.map
+ $ head ./lib/librte_eal/version.map
DPDK_20 {
global:
...
@@ -100,12 +100,12 @@ how this may be done.
.. code-block:: none
- $ head ./lib/librte_acl/rte_acl_version.map
+ $ head ./lib/librte_acl/version.map
DPDK_21 {
global:
...
- $ head ./lib/librte_eal/rte_eal_version.map
+ $ head ./lib/librte_eal/version.map
DPDK_21 {
global:
...
@@ -134,7 +134,7 @@ linked to the DPDK.
To support backward compatibility the ``rte_function_versioning.h``
header file provides macros to use when updating exported functions. These
-macros are used in conjunction with the ``rte_<library>_version.map`` file for
+macros are used in conjunction with the ``version.map`` file for
a given library to allow multiple versions of a symbol to exist in a shared
library so that older binaries need not be immediately recompiled.
diff --git a/lib/librte_eal/include/rte_function_versioning.h b/lib/librte_eal/include/rte_function_versioning.h
index f588f2643b..746a1e1992 100644
--- a/lib/librte_eal/include/rte_function_versioning.h
+++ b/lib/librte_eal/include/rte_function_versioning.h
@@ -22,7 +22,7 @@
* allow for backwards compatibility for a time with older binaries that are
* dynamically linked to the dpdk. To support that, the __vsym and
* VERSION_SYMBOL macros are created. They, in conjunction with the
- * <library>_version.map file for a given library allow for multiple versions of
+ * version.map file for a given library allow for multiple versions of
* a symbol to exist in a shared library so that older binaries need not be
* immediately recompiled.
*
--
2.23.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [v3 1/2] cryptodev: support enqueue callback functions
@ 2020-10-21 19:33 3% ` Ananyev, Konstantin
2020-10-23 12:36 0% ` Gujjar, Abhinandan S
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2020-10-21 19:33 UTC (permalink / raw)
To: Gujjar, Abhinandan S, dev, Doherty, Declan, akhil.goyal,
Honnappa.Nagarahalli
Cc: Vangati, Narender, jerinj
Hi Abhinandan,
Thanks for the effort, good progress.
Though few more comments, see below.
> This patch adds APIs to add/remove callback functions. The callback
> function will be called for each burst of crypto ops received on a
> given crypto device queue pair.
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> config/rte_config.h | 1 +
> lib/librte_cryptodev/meson.build | 2 +-
> lib/librte_cryptodev/rte_cryptodev.c | 201 +++++++++++++++++++++++++
> lib/librte_cryptodev/rte_cryptodev.h | 153 ++++++++++++++++++-
> lib/librte_cryptodev/rte_cryptodev_version.map | 2 +
> 5 files changed, 357 insertions(+), 2 deletions(-)
Don't forget to update Release Notes and probably Prog Guide too.
>
> diff --git a/config/rte_config.h b/config/rte_config.h
> index 03d90d7..e999d93 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -61,6 +61,7 @@
> /* cryptodev defines */
> #define RTE_CRYPTO_MAX_DEVS 64
> #define RTE_CRYPTODEV_NAME_LEN 64
> +#define RTE_CRYPTO_CALLBACKS 1
>
> /* compressdev defines */
> #define RTE_COMPRESS_MAX_DEVS 64
> diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
> index c4c6b3b..8c5493f 100644
> --- a/lib/librte_cryptodev/meson.build
> +++ b/lib/librte_cryptodev/meson.build
> @@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
> 'rte_crypto.h',
> 'rte_crypto_sym.h',
> 'rte_crypto_asym.h')
> -deps += ['kvargs', 'mbuf']
> +deps += ['kvargs', 'mbuf', 'rcu']
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
> index 3d95ac6..5ba774a 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -448,6 +448,10 @@ struct rte_cryptodev_sym_session_pool_private_data {
> return 0;
> }
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/* spinlock for crypto device enq callbacks */
> +static rte_spinlock_t rte_cryptodev_enq_cb_lock = RTE_SPINLOCK_INITIALIZER;
> +#endif
>
> const char *
> rte_cryptodev_get_feature_name(uint64_t flag)
> @@ -1136,6 +1140,203 @@ struct rte_cryptodev *
> socket_id);
> }
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb *cb, *tail;
> + struct rte_cryptodev_enq_cb_rcu *list;
> + struct rte_rcu_qsbr *qsbr;
> + size_t size;
> +
> + /* Max thread set to 1, as one DP thread accessing a queue-pair */
> + const uint32_t max_threads = 1;
> +
> + if (!cb_fn)
> + return NULL;
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + return NULL;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + return NULL;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock);
> + if (dev->enq_cbs == NULL) {
> + dev->enq_cbs = rte_zmalloc(NULL, sizeof(cb) *
> + dev->data->nb_queue_pairs, 0);
> + if (dev->enq_cbs == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for callbacks");
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
It is a bit clumsy to do unlock() for every return with error.
Probably an easier way - create an internal function that would do the actual job, and then
lock(); ret=actual_job_internal_functio(...); unlock();...
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> +
> + list = rte_zmalloc(NULL, sizeof(*list), 0);
As I understand, list is per queue, while enq_cbs[] is per port.
So if enq_cbs is not null, it doesn't mean that list for that particular queue is
already properly initialized.
Another thing - is there any point for dev->enq_cbs[] to be a an array of pointers to
rte_cryptodev_enq_cb_rcu? Considering that rte_cryptodev_enq_cb_rcu itself contains
just two pointers inside, I think it enq_cbs can point just to an array of rte_cryptodev_enq_cb_rcu:
struct rte_cryptodev {
...
struct rte_cryptodev_enq_cb_rcu *enq_cbs;
And you can remove one level of indirection here and in other places.
> + if (list == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for list on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> + rte_errno = ENOMEM;
> + rte_free(dev->enq_cbs);
Here and in other places: you free dev->enq_cbs, but not set it to NULL.
In fact - probably a good idea to have one cleanup() function that would free
all necessary stuff and set it to null, and then use it in all such places.
> + return NULL;
> + }
> +
> + /* Create RCU QSBR variable */
> + size = rte_rcu_qsbr_get_memsize(max_threads);
> + qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> + if (qsbr == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for RCU on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> + rte_errno = ENOMEM;
> + rte_free(list);
> + rte_free(dev->enq_cbs);
> + dev->enq_cbs[qp_id] = NULL;
> + return NULL;
> + }
> +
> + if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> + CDEV_LOG_ERR("Failed to initialize for RCU on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> + rte_free(qsbr);
> + rte_free(list);
> + rte_free(dev->enq_cbs);
> + dev->enq_cbs[qp_id] = NULL;
> + return NULL;
> + }
> +
> + dev->enq_cbs[qp_id] = list;
> + list->qsbr = qsbr;
> + }
> +
> + cb = rte_zmalloc(NULL, sizeof(*cb), 0);
> + if (cb == NULL) {
> + CDEV_LOG_ERR("Failed to allocate memory for callback on "
> + "dev=%d, queue_pair_id=%d", dev_id, qp_id);
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> +
> + cb->fn = cb_fn;
> + cb->arg = cb_arg;
> +
> + /* Add the callbacks in fifo order. */
> + list = dev->enq_cbs[qp_id];
> + tail = list->next;
> + if (tail) {
> + while (tail->next)
> + tail = tail->next;
> + tail->next = cb;
> + } else
> + list->next = cb;
> +
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> +
> + return cb;
> +}
> +
> +int
> +rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb)
> +{
> + struct rte_cryptodev *dev;
> + struct rte_cryptodev_cb **prev_cb, *curr_cb;
> + struct rte_cryptodev_enq_cb_rcu *list;
> + uint16_t qp;
> + int free_mem;
> + int ret;
> +
> + free_mem = 1;
> + ret = -EINVAL;
> +
> + if (!cb) {
> + CDEV_LOG_ERR("cb is NULL");
> + return ret;
> + }
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> + CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> + return ret;
> + }
> +
> + dev = &rte_crypto_devices[dev_id];
> + if (qp_id >= dev->data->nb_queue_pairs) {
> + CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
> + return ret;
> + }
> +
> + list = dev->enq_cbs[qp_id];
> + if (list == NULL) {
> + CDEV_LOG_ERR("Callback list is NULL");
> + return ret;
> + }
> +
> + if (list->qsbr == NULL) {
> + CDEV_LOG_ERR("Rcu qsbr is NULL");
> + return ret;
> + }
> +
> + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock);
> + if (dev->enq_cbs == NULL) {
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> + return ret;
> + }
> +
> + prev_cb = &list->next;
> + for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
> + curr_cb = *prev_cb;
> + if (curr_cb == cb) {
> + /* Remove the user cb from the callback list. */
> + *prev_cb = curr_cb->next;
> + ret = 0;
> + break;
> + }
> + }
> +
> + if (!ret) {
> + /* Call sync with invalid thread id as this is part of
> + * control plane API
> + */
> + rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
> + rte_free(cb);
> + }
> +
> + if (list->next == NULL) {
> + rte_free(list->qsbr);
We can't destroy our sync variable while device is not stopped or destroyed.
It can be still used by DP.
Probably the easiest way to deal with it - allocate and initialize enq_cbs[] and all
related qsbrs at first add_callback and free all that memory only on dev_destroy().
> + rte_free(list);
> + dev->enq_cbs[qp_id] = NULL;
> + }
> +
> + for (qp = 0; qp < dev->data->nb_queue_pairs; qp++)
> + if (dev->enq_cbs[qp] != NULL) {
> + free_mem = 0;
> + break;
> + }
> +
> + if (free_mem) {
> + rte_free(dev->enq_cbs);
Again, not safe to do here, see above.
> + dev->enq_cbs = NULL;
> + }
> +
> + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> +
> + return ret;
> +}
> +#endif
>
> int
> rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats)
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
> index 0935fd5..669746d 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -23,6 +23,7 @@
> #include "rte_dev.h"
> #include <rte_common.h>
> #include <rte_config.h>
> +#include <rte_rcu_qsbr.h>
>
> #include "rte_cryptodev_trace_fp.h"
>
> @@ -522,6 +523,34 @@ struct rte_cryptodev_qp_conf {
> /**< The mempool for creating sess private data in sessionless mode */
> };
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/**
> + * Function type used for pre processing crypto ops when enqueue burst is
> + * called.
> + *
> + * The callback function is called on enqueue burst immediately
> + * before the crypto ops are put onto the hardware queue for processing.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair in which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param ops The address of an array of *nb_ops* pointers
> + * to *rte_crypto_op* structures which contain
> + * the crypto operations to be processed.
> + * @param nb_ops The number of operations to process.
> + * @param user_param The arbitrary user parameter passed in by the
> + * application when the callback was originally
> + * registered.
> + * @return The number of ops to be enqueued to the
> + * crypto device.
> + */
> +typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
> + struct rte_crypto_op **ops, uint16_t nb_ops, void *user_param);
> +#endif
> +
> /**
> * Typedef for application callback function to be registered by application
> * software for notification of device events
> @@ -822,7 +851,6 @@ struct rte_cryptodev_config {
> enum rte_cryptodev_event_type event,
> rte_cryptodev_cb_fn cb_fn, void *cb_arg);
>
> -
> typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
> struct rte_crypto_op **ops, uint16_t nb_ops);
> /**< Dequeue processed packets from queue pair of a device. */
> @@ -839,6 +867,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
> /** Structure to keep track of registered callbacks */
> TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/**
> + * @internal
> + * Structure used to hold information about the callbacks to be called for a
> + * queue pair on enqueue.
> + */
> +struct rte_cryptodev_cb {
> + struct rte_cryptodev_cb *next;
> + /** < Pointer to next callback */
> + rte_cryptodev_callback_fn fn;
> + /** < Pointer to callback function */
> + void *arg;
> + /** < Pointer to argument */
> +};
> +
> +/**
> + * @internal
> + * Structure used to hold information about the RCU for a queue pair.
> + */
> +struct rte_cryptodev_enq_cb_rcu {
> + struct rte_cryptodev_cb *next;
> + /** < Pointer to next callback */
> + struct rte_rcu_qsbr *qsbr;
> + /** < RCU QSBR variable per queue pair */
> +};
> +#endif
> +
> /** The data structure associated with each crypto device. */
> struct rte_cryptodev {
> dequeue_pkt_burst_t dequeue_burst;
> @@ -867,6 +922,11 @@ struct rte_cryptodev {
> __extension__
> uint8_t attached : 1;
> /**< Flag indicating the device is attached */
> +
> +#ifdef RTE_CRYPTO_CALLBACKS
I'd *always* reserve space for it.
No matter is RTE_CRYPTO_CALLBACKS defined or not.
To avoid difference in public structure layout.
> + struct rte_cryptodev_enq_cb_rcu **enq_cbs;
As I said above, no need for extra level of indirection.
> + /**< User application callback for pre enqueue processing */
> +#endif
As I understand, it is not an ABI breakage - as there are some free space right now
at the end of struct rte_cryptodev (due to it alignment), but definitely need to update RN.
> } __rte_cache_aligned;
>
> void *
> @@ -989,6 +1049,25 @@ struct rte_cryptodev_data {
> {
> struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> + if (unlikely(dev->enq_cbs != NULL && dev->enq_cbs[qp_id] != NULL)) {
Agree with Honnappa's comment for that piece of code.
Probably need to be something like:
if (unlikely(dev->enq_cbs != NULL && dev->enq_cbs[qp_id].next != NULL) {
list = &dev->enq_cbs[qp_id];
rte_rcu_qsbr_thread_online(list->qsbr, 0);
for (cb = list->next; cb != NULL; cb = cb->next)
....
rte_rcu_qsbr_thread_offline(list->qsbr, 0);
}
> + struct rte_cryptodev_enq_cb_rcu *list;
> + struct rte_cryptodev_cb *cb;
> +
> + list = dev->enq_cbs[qp_id];
> + cb = list->next;
> + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> +
> + do {
> + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> + cb->arg);
> + cb = cb->next;
> + } while (cb != NULL);
> +
> + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> + }
> +#endif
> +
> rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, nb_ops);
> return (*dev->enqueue_burst)(
> dev->data->queue_pairs[qp_id], ops, nb_ops);
> @@ -1730,6 +1809,78 @@ struct rte_crypto_raw_dp_ctx {
> rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
> uint32_t n);
>
> +#ifdef RTE_CRYPTO_CALLBACKS
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Add a user callback for a given crypto device and queue pair which will be
> + * called on crypto ops enqueue.
> + *
> + * This API configures a function to be called for each burst of crypto ops
> + * received on a given crypto device queue pair. The return value is a pointer
> + * that can be used later to remove the callback using
> + * rte_cryptodev_remove_enq_callback().
> + *
> + * Multiple functions are called in the order that they are added.
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair in which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param cb_fn The callback function
> + * @param cb_arg A generic pointer parameter which will be passed
> + * to each invocation of the callback function on
> + * this crypto device and queue pair.
> + *
> + * @return
> + * NULL on error.
> + * On success, a pointer value which can later be used to remove the callback.
> + */
> +
> +__rte_experimental
> +struct rte_cryptodev_cb *
> +rte_cryptodev_add_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + rte_cryptodev_callback_fn cb_fn,
> + void *cb_arg);
> +
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Remove a user callback function for given crypto device and queue pair.
> + *
> + * This function is used to removed callbacks that were added to a crypto
> + * device queue pair using rte_cryptodev_add_enq_callback().
> + *
> + *
> + *
> + * @param dev_id The identifier of the device.
> + * @param qp_id The index of the queue pair in which ops are
> + * to be enqueued for processing. The value
> + * must be in the range [0, nb_queue_pairs - 1]
> + * previously supplied to
> + * *rte_cryptodev_configure*.
> + * @param cb Pointer to user supplied callback created via
> + * rte_cryptodev_add_enq_callback().
> + *
> + * @return
> + * - 0: Success. Callback was removed.
> + * - -EINVAL: The dev_id or the qp_id is out of range, or the callback
> + * is NULL or not found for the crypto device queue pair.
> + */
> +
> +__rte_experimental
> +int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
> + uint16_t qp_id,
> + struct rte_cryptodev_cb *cb);
> +
> +#endif
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
> index 7e4360f..5d8d6b0 100644
> --- a/lib/librte_cryptodev/rte_cryptodev_version.map
> +++ b/lib/librte_cryptodev/rte_cryptodev_version.map
> @@ -101,6 +101,7 @@ EXPERIMENTAL {
> rte_cryptodev_get_qp_status;
>
> # added in 20.11
> + rte_cryptodev_add_enq_callback;
> rte_cryptodev_configure_raw_dp_ctx;
> rte_cryptodev_get_raw_dp_ctx_size;
> rte_cryptodev_raw_dequeue;
> @@ -109,4 +110,5 @@ EXPERIMENTAL {
> rte_cryptodev_raw_enqueue;
> rte_cryptodev_raw_enqueue_burst;
> rte_cryptodev_raw_enqueue_done;
> + rte_cryptodev_remove_enq_callback;
> };
> --
> 1.9.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 14/14] doc: update patch cheatsheet to use meson
2020-10-21 8:17 9% ` [dpdk-dev] [PATCH v7 12/14] doc: remove references to make from contributing guide Ciara Power
@ 2020-10-21 8:17 2% ` Ciara Power
1 sibling, 0 replies; 200+ results
From: Ciara Power @ 2020-10-21 8:17 UTC (permalink / raw)
To: dev; +Cc: Kevin Laatz
From: Kevin Laatz <kevin.laatz@intel.com>
With 'make' being removed, the patch cheatsheet needs to be updated to
remove any references to 'make'. These references have been replaced with
meson alternatives in this patch.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
---
.../contributing/img/patch_cheatsheet.svg | 582 ++++++++----------
1 file changed, 270 insertions(+), 312 deletions(-)
diff --git a/doc/guides/contributing/img/patch_cheatsheet.svg b/doc/guides/contributing/img/patch_cheatsheet.svg
index 85225923e1..986e4db815 100644
--- a/doc/guides/contributing/img/patch_cheatsheet.svg
+++ b/doc/guides/contributing/img/patch_cheatsheet.svg
@@ -1,6 +1,4 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
@@ -13,7 +11,7 @@
width="210mm"
height="297mm"
id="svg2985"
- inkscape:version="0.48.4 r9939"
+ inkscape:version="1.0.1 (3bc2e813f5, 2020-09-07)"
sodipodi:docname="patch_cheatsheet.svg">
<sodipodi:namedview
pagecolor="#ffffff"
@@ -24,17 +22,19 @@
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
- inkscape:window-width="1184"
- inkscape:window-height="1822"
+ inkscape:window-width="1920"
+ inkscape:window-height="1017"
id="namedview274"
showgrid="false"
- inkscape:zoom="1.2685914"
- inkscape:cx="289.93958"
- inkscape:cy="509.84194"
- inkscape:window-x="0"
- inkscape:window-y="19"
- inkscape:window-maximized="0"
- inkscape:current-layer="g3272" />
+ inkscape:zoom="0.89702958"
+ inkscape:cx="246.07409"
+ inkscape:cy="416.76022"
+ inkscape:window-x="1072"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="layer1"
+ inkscape:document-rotation="0"
+ inkscape:snap-grids="false" />
<defs
id="defs3">
<linearGradient
@@ -549,347 +549,336 @@
</g>
</switch>
<g
- transform="matrix(0.89980358,0,0,0.89980358,45.57817,-2.8793563)"
+ transform="matrix(0.89980358,0,0,0.89980358,57.57817,-2.8793563)"
id="g4009">
<text
x="325.02054"
y="107.5126"
id="text3212"
xml:space="preserve"
- style="font-size:43.11383057px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:43.1138px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"
transform="scale(1.193782,0.83767389)"><tspan
x="325.02054"
y="107.5126"
- id="tspan3214">CHEATSHEET</tspan></text>
+ id="tspan3214"
+ style="font-family:monospace">CHEATSHEET</tspan></text>
<text
x="386.51117"
y="58.178116"
transform="scale(1.0054999,0.99453018)"
id="text3212-1"
xml:space="preserve"
- style="font-size:42.11373901px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:42.1137px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="386.51117"
y="58.178116"
- id="tspan3214-7">PATCH SUBMIT</tspan></text>
+ id="tspan3214-7"
+ style="font-family:monospace">PATCH SUBMIT</tspan></text>
</g>
<rect
- width="714.94495"
- height="88.618027"
- rx="20.780111"
- ry="15.96909"
- x="14.574773"
- y="7.0045133"
+ width="759.50977"
+ height="88.591248"
+ rx="22.075403"
+ ry="15.964265"
+ x="14.588161"
+ y="7.0179014"
id="rect3239"
- style="fill:none;stroke:#00233b;stroke-width:0.87678075;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:0.903557;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
- width="713.28113"
- height="887.29156"
- rx="17.656931"
- ry="17.280584"
- x="15.406689"
- y="104.73515"
+ width="757.84167"
+ height="887.2605"
+ rx="18.760006"
+ ry="17.27998"
+ x="15.422211"
+ y="104.75068"
id="rect3239-0"
- style="fill:none;stroke:#00233b;stroke-width:1.00973284;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:1.04078;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
- width="694.94904"
- height="381.31"
- rx="9.4761629"
- ry="9.0904856"
- x="24.336016"
- y="601.75836"
+ width="732.82446"
+ height="381.28253"
+ rx="9.9926233"
+ ry="9.0898304"
+ x="24.349754"
+ y="601.77209"
id="rect3239-0-9-4"
- style="fill:none;stroke:#00233b;stroke-width:1.02322531;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:1.0507;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
- d="m 386.3921,327.23442 323.14298,0"
+ d="M 422.0654,327.23442 H 709.53508"
id="path4088"
- style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ style="fill:none;stroke:#00233b;stroke-width:0.943189px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
- x="396.18015"
+ x="428.18015"
y="314.45731"
id="text4090"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="396.18015"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="428.18015"
y="314.45731"
id="tspan4092"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Patch Pre-Checks</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Patch Pre-Checks</tspan></text>
<text
x="43.44949"
y="147.32129"
id="text4090-4"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="43.44949"
y="147.32129"
id="tspan4092-3"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Commit Pre-Checks</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Commit Pre-Checks</tspan></text>
<text
- x="397.1235"
+ x="429.1235"
y="144.8549"
id="text4090-4-3"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="397.1235"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="429.1235"
y="144.8549"
id="tspan4092-3-3"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Bugfix?</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Bugfix?</tspan></text>
<text
x="41.215897"
y="634.38617"
id="text4090-1"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="41.215897"
y="634.38617"
id="tspan4092-38"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Git send-email </tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Git send-email </tspan></text>
<path
d="m 31.232443,642.80575 376.113467,0"
id="path4088-7"
style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
inkscape:connector-curvature="0" />
<rect
- width="342.13785"
- height="230.74609"
- rx="10.411126"
- ry="10.411126"
- x="25.418407"
- y="114.92036"
+ width="376.65033"
+ height="230.70007"
+ rx="11.461329"
+ ry="10.40905"
+ x="25.441414"
+ y="114.94337"
id="rect3239-0-9-4-2"
- style="fill:none;stroke:#00233b;stroke-width:0.93674862;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:0.982762;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
x="43.44949"
y="385.8045"
id="text4090-86"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="43.44949"
y="385.8045"
id="tspan4092-5"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Compile Pre-Checks</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Compile Pre-Checks</tspan></text>
<g
- transform="translate(352.00486,-348.25973)"
+ transform="matrix(1.0077634,0,0,1,384.57109,-348.25973)"
id="g3295">
<text
x="43.87738"
y="568.03088"
id="text4090-8-14"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="43.87738"
y="568.03088"
id="tspan4289"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Include warning/error</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Include warning/error</tspan></text>
<text
x="43.87738"
y="537.71906"
id="text4090-8-14-4"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="43.87738"
y="537.71906"
id="tspan4289-1"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Fixes: line</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Fixes: line</tspan></text>
<text
x="43.87738"
y="598.9939"
id="text4090-8-14-0"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="43.87738"
y="598.9939"
id="tspan4289-2"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ How to reproduce</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ How to reproduce</tspan></text>
</g>
<g
- transform="translate(-2.6258125,-26.708615)"
+ transform="matrix(0.88614399,0,0,1.0199334,-5.7864591,-38.84504)"
id="g4115">
<g
id="g3272">
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1"
y="454.36987"
x="49.093246"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7"
y="454.36987"
x="49.093246">+ build gcc icc clang </tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
+ xml:space="preserve"
+ id="text581"
+ y="454.36987"
+ x="49.093246" />
+ <text
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-2"
y="516.59979"
x="49.093246"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-79"
y="516.59979"
- x="49.093246">+ make test doc </tspan></text>
+ x="49.093246">+ meson -Denable_docs=true</tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-2-0-0"
y="544.71033"
x="49.093246"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-79-9-0"
y="544.71033"
- x="49.093246">+ make examples</tspan></text>
+ x="49.093246">+ meson -Dexamples=all</tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-2-0-07"
y="576.83533"
x="49.093246"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-79-9-3"
y="576.83533"
- x="49.093246">+ make shared-lib</tspan></text>
+ x="49.093246"
+ transform="matrix(1.0305467,0,0,1,-1.5447426,0)">+ meson -Ddefault_library=shared</tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-2-0-07-4"
y="604.88947"
x="49.093246"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-79-9-3-9"
y="604.88947"
x="49.093246">+ library ABI version</tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-2-9"
y="486.56659"
x="49.093246"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-79-3"
y="486.56659"
x="49.093246">+ build 32 and 64 bits</tspan></text>
</g>
</g>
<text
- x="74.388756"
- y="914.65686"
+ x="72.598656"
+ y="937.21002"
id="text4090-8-1-8-65-9"
xml:space="preserve"
- style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.2959px;line-height:0%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.02466"
+ transform="scale(1.0246575,0.97593587)"><tspan
sodipodi:role="line"
id="tspan3268"
- x="74.388756"
- y="914.65686">git send-email *.patch --annotate --to <maintainer></tspan><tspan
+ x="72.598656"
+ y="937.21002"
+ style="font-size:19.4685px;line-height:1.25;font-family:monospace;stroke-width:1.02466">git send-email *.patch --annotate --to <maintainer></tspan><tspan
sodipodi:role="line"
id="tspan3272"
- x="74.388756"
- y="938.40686"> --cc dev@dpdk.org [ --cc other@participants.com</tspan><tspan
+ x="72.598656"
+ y="961.54565"
+ style="font-size:19.4685px;line-height:1.25;font-family:monospace;stroke-width:1.02466"> --cc dev@dpdk.org [ --cc other@participants.com</tspan><tspan
sodipodi:role="line"
- x="74.388756"
- y="962.15686"
- id="tspan3266"> --cover-letter -v[N] --in-reply-to <message ID> ]</tspan></text>
+ x="72.598656"
+ y="985.88129"
+ id="tspan3266"
+ style="font-size:19.4685px;line-height:1.25;font-family:monospace;stroke-width:1.02466"> --cover-letter -v[N] --in-reply-to <message ID> ]</tspan></text>
<text
x="543.47675"
y="1032.3459"
id="text4090-8-7-8-7-6-3-8-2-5"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="543.47675"
y="1032.3459"
id="tspan4092-8-6-3-1-8-4-4-5-3"
- style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">harry.van.haaren@intel.com</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:125%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;writing-mode:lr-tb;text-anchor:start">harry.van.haaren@intel.com</tspan></text>
<rect
- width="678.14105"
- height="87.351799"
- rx="6.7972355"
- ry="6.7972355"
- x="31.865864"
- y="888.44696"
+ width="711.56055"
+ height="87.327599"
+ rx="7.1322103"
+ ry="6.795352"
+ x="31.877964"
+ y="888.45905"
id="rect3239-0-9-4-3"
- style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:1.0242;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
x="543.29498"
y="1018.1843"
id="text4090-8-7-8-7-6-3-8-2-5-3"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="543.29498"
y="1018.1843"
id="tspan4092-8-6-3-1-8-4-4-5-3-7"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Suggestions / Updates?</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Suggestions / Updates?</tspan></text>
<g
id="g3268"
transform="translate(0,-6)">
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8"
y="704.07019"
x="41.658669"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6"
y="704.07019"
x="41.658669">+ Patch version ( eg: -v2 ) </tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8-0"
y="736.29175"
x="41.658669"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6-2"
y="736.29175"
x="41.658669">+ Patch version annotations</tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8-6"
y="766.70355"
x="41.911205"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6-1"
y="766.70355"
x="41.911205">+ Send --to maintainer </tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8-6-3"
y="795.30548"
x="41.658669"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6-1-8"
y="795.30548"
x="41.658669">+ Send --cc dev@dpdk.org </tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8-9"
y="675.25287"
x="41.658669"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6-9"
y="675.25287"
x="41.658669">+ Cover letter</tspan></text>
@@ -897,73 +886,70 @@
id="g3303"
transform="translate(1.0962334,-40.034939)">
<text
- sodipodi:linespacing="125%"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8-65"
y="868.70337"
x="41.572586"><tspan
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6-10"
y="868.70337"
x="41.572586">+ Send --in-reply-to <message ID><tspan
- style="font-size:20px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:20px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan3184" /></tspan></text>
<text
- sodipodi:linespacing="125%"
- style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ style="font-style:normal;font-weight:normal;font-size:25.6917px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"
xml:space="preserve"
id="text4090-8-1-8-9-1"
y="855.79816"
x="460.18405"><tspan
- style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:11.5613px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start"
id="tspan4092-8-7-6-9-7"
y="855.79816"
x="460.18405">****</tspan></text>
</g>
</g>
<text
- x="685.67828"
+ x="697.67828"
y="76.55056"
id="text4090-8-1-8-9-1-9"
xml:space="preserve"
- style="font-size:20.20989037px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="685.67828"
+ style="font-style:normal;font-weight:normal;font-size:20.2099px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="697.67828"
y="76.55056"
id="tspan4092-8-7-6-9-7-4"
- style="font-size:9.09445095px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">v1.0</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:9.09445px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">v2.0</tspan></text>
<rect
- width="342.3053"
- height="155.54948"
- rx="9.2344503"
- ry="9.2344503"
- x="377.58942"
- y="114.55766"
+ width="347.40179"
+ height="155.50351"
+ rx="9.3719397"
+ ry="9.2317209"
+ x="412.60239"
+ y="114.58065"
id="rect3239-0-9-4-2-1"
- style="fill:none;stroke:#00233b;stroke-width:0.76930124;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:0.774892;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
- width="342.12564"
- height="236.79482"
- rx="10.647112"
- ry="9.584527"
- x="25.642178"
- y="356.86249"
+ width="377.75555"
+ height="234.52185"
+ rx="11.755931"
+ ry="9.4925261"
+ x="25.663876"
+ y="356.88416"
id="rect3239-0-9-4-2-0"
- style="fill:none;stroke:#00233b;stroke-width:0.9489302;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:0.99232;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
- width="341.98428"
- height="312.73181"
- rx="8.5358429"
- ry="8.5358429"
- x="377.96762"
- y="280.45331"
+ width="343.53604"
+ height="312.67508"
+ rx="8.5745735"
+ ry="8.5342941"
+ x="414.29037"
+ y="280.48166"
id="rect3239-0-9-4-2-1-9"
- style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:1.00217;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
- d="m 387.02742,157.3408 323.14298,0"
+ d="M 419.35634,157.3408 H 710.1704"
id="path4088-8"
- style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ style="fill:none;stroke:#00233b;stroke-width:0.94866px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
inkscape:connector-curvature="0" />
<path
d="m 36.504486,397.33869 323.142974,0"
@@ -971,9 +957,9 @@
style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
inkscape:connector-curvature="0" />
<path
- d="m 35.494337,156.92238 323.142983,0"
+ d="M 35.494337,156.92238 H 372.01481"
id="path4088-4"
- style="fill:none;stroke:#00233b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ style="fill:none;stroke:#00233b;stroke-width:1.02049px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
inkscape:connector-curvature="0" />
<g
transform="translate(1.0962334,-30.749225)"
@@ -983,45 +969,41 @@
y="214.1572"
id="text4090-8-11"
xml:space="preserve"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="45.371201"
y="214.1572"
id="tspan4092-8-52"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Signed-off-by: </tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Signed-off-by: </tspan></text>
<text
x="45.371201"
y="243.81795"
id="text4090-8-7-8"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="45.371201"
y="243.81795"
id="tspan4092-8-6-3"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Suggested-by:</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Suggested-by:</tspan></text>
<text
x="45.371201"
y="273.90939"
id="text4090-8-7-8-7"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="45.371201"
y="273.90939"
id="tspan4092-8-6-3-1"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reported-by:</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Reported-by:</tspan></text>
<text
x="45.371201"
y="304.00082"
id="text4090-8-7-8-7-6"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="45.371201"
y="304.00082"
id="tspan4092-8-6-3-1-8"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Tested-by:</tspan></text>
<g
id="g3297"
transform="translate(1.1147904,-7.2461378)">
@@ -1030,110 +1012,102 @@
y="368.8187"
id="text4090-8-7-8-7-6-3"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="45.371201"
y="368.8187"
id="tspan4092-8-6-3-1-8-4"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Previous Acks</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Previous Acks</tspan></text>
<text
x="235.24362"
y="360.3028"
id="text4090-8-1-8-9-1-4"
xml:space="preserve"
- style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:25.6917px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="235.24362"
y="360.3028"
id="tspan4092-8-7-6-9-7-0"
- style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:11.5613px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
</g>
<text
x="45.371201"
y="334.52298"
id="text4090-8-7-8-7-6-3-4"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="45.371201"
y="334.52298"
id="tspan4092-8-6-3-1-8-4-0"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Commit message</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Commit message</tspan></text>
</g>
<rect
width="295.87207"
height="164.50136"
rx="7.3848925"
ry="4.489974"
- x="414.80502"
+ x="444.80502"
y="611.47064"
id="rect3239-0-9-4-2-1-9-9"
- style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
- x="439.4429"
+ x="469.4429"
y="638.35608"
id="text4090-1-4"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="439.4429"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="469.4429"
y="638.35608"
id="tspan4092-38-8"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Mailing List</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Mailing List</tspan></text>
<text
- x="431.55353"
+ x="461.55353"
y="675.59857"
id="text4090-8-5-6-9-4-6-6-8"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="431.55353"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="461.55353"
y="675.59857"
id="tspan4092-8-5-5-3-4-0-6-2"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Acked-by:</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Acked-by:</tspan></text>
<text
- x="431.39734"
+ x="461.39734"
y="734.18231"
id="text4090-8-5-6-9-4-6-6-8-5"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="431.39734"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="461.39734"
y="734.18231"
id="tspan4092-8-5-5-3-4-0-6-2-1"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Reviewed-by:</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Reviewed-by:</tspan></text>
<text
- x="450.8428"
+ x="480.8428"
y="766.5578"
id="text4090-8-5-6-9-4-6-6-8-7"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="450.8428"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="480.8428"
y="766.5578"
id="tspan4092-8-5-5-3-4-0-6-2-11"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">Nack (refuse patch)</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">Nack (refuse patch)</tspan></text>
<path
- d="m 426.99385,647.80575 272.72607,0"
+ d="M 456.99385,647.80575 H 729.71992"
id="path4088-7-5"
- style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<path
- d="m 424.7332,742.35699 272.72607,0"
+ d="M 454.7332,742.35699 H 727.45927"
id="path4088-7-5-2"
- style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ style="fill:none;stroke:#00233b;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:connector-curvature="0" />
<text
- x="431.39734"
+ x="461.39734"
y="704.78278"
id="text4090-8-5-6-9-4-6-6-8-5-1"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="431.39734"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="461.39734"
y="704.78278"
id="tspan4092-8-5-5-3-4-0-6-2-1-7"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Tested-by:</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Tested-by:</tspan></text>
<g
transform="translate(1.0962334,-2.7492248)"
id="g3613">
@@ -1142,22 +1116,21 @@
y="1007.5879"
id="text4090-8-7-8-7-6-3-8"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="43.146141"
y="1007.5879"
id="tspan4092-8-6-3-1-8-4-4"
- style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Previous Acks only when fixing typos, rebased, or checkpatch issues.</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:125%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;writing-mode:lr-tb;text-anchor:start">Previous Acks only when fixing typos, rebased, or checkpatch issues.</tspan></text>
<text
x="30.942892"
y="1011.3757"
id="text4090-8-7-8-7-6-3-8-4-1"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="30.942892"
y="1011.3757"
id="tspan4092-8-6-3-1-8-4-4-55-7"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
</g>
<g
transform="translate(1.0962334,-2.7492248)"
@@ -1167,35 +1140,34 @@
y="1020.4383"
id="text4090-8-7-8-7-6-3-8-4"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="42.176418"
y="1020.4383"
id="tspan4092-8-6-3-1-8-4-4-55"
- style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">The version.map function names must be in alphabetical order.</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:125%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;writing-mode:lr-tb;text-anchor:start">The version.map function names must be in alphabetical order.</tspan></text>
<text
x="30.942892"
y="1024.2014"
id="text4090-8-7-8-7-6-3-8-4-1-5"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="30.942892"
y="1024.2014"
id="tspan4092-8-6-3-1-8-4-4-55-7-2"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="25.247679"
y="1024.2014"
id="text4090-8-7-8-7-6-3-8-4-1-5-6"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="25.247679"
y="1024.2014"
id="tspan4092-8-6-3-1-8-4-4-55-7-2-8"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
</g>
<g
- transform="translate(1.0962334,-30.749225)"
+ transform="matrix(1.0211743,0,0,1,25.427515,-30.749225)"
id="g3275">
<g
id="g3341">
@@ -1204,67 +1176,61 @@
y="390.17807"
id="text4090-8"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="390.17807"
id="tspan4092-8"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Rebase to git </tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Rebase to git </tspan></text>
<text
x="394.78601"
y="420.24835"
id="text4090-8-5"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="420.24835"
id="tspan4092-8-5"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Checkpatch </tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Checkpatch </tspan></text>
<text
x="394.78601"
y="450.53394"
id="text4090-8-5-6"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="450.53394"
id="tspan4092-8-5-5"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ ABI breakage </tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ ABI breakage </tspan></text>
<text
x="394.78601"
y="513.13031"
id="text4090-8-5-6-9-4"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="513.13031"
id="tspan4092-8-5-5-3-4"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Maintainers file</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Maintainers file</tspan></text>
<text
x="394.78601"
y="573.48621"
id="text4090-8-5-6-9-4-6"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="573.48621"
id="tspan4092-8-5-5-3-4-0"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Release notes</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Release notes</tspan></text>
<text
x="395.79617"
y="603.98718"
id="text4090-8-5-6-9-4-6-6"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="395.79617"
y="603.98718"
id="tspan4092-8-5-5-3-4-0-6"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Documentation</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Documentation</tspan></text>
<g
transform="translate(0,-0.83470152)"
id="g3334">
@@ -1276,24 +1242,22 @@
y="468.01297"
id="text4090-8-1-8-9-1-4-1"
xml:space="preserve"
- style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:25.6917px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="660.46729"
y="468.01297"
id="tspan4092-8-7-6-9-7-0-7"
- style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">**</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:11.5613px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">**</tspan></text>
</g>
<text
x="394.78601"
y="483.59955"
id="text4090-8-5-6-9"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="483.59955"
id="tspan4092-8-5-5-3"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Update version.map</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Update version.map</tspan></text>
</g>
<g
id="g3428"
@@ -1303,12 +1267,11 @@
y="541.38928"
id="text4090-8-5-6-9-4-6-1"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="394.78601"
y="541.38928"
id="tspan4092-8-5-5-3-4-0-7"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+ Doxygen</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+ Doxygen</tspan></text>
<g
transform="translate(-119.92979,57.949844)"
id="g3267-9">
@@ -1317,28 +1280,26 @@
y="473.13675"
id="text4090-8-1-8-9-1-4-1-4"
xml:space="preserve"
- style="font-size:25.6917057px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-weight:normal;font-size:25.6917px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="628.93628"
y="473.13675"
id="tspan4092-8-7-6-9-7-0-7-8"
- style="font-size:11.56126785px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">***</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:11.5613px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">***</tspan></text>
</g>
</g>
</g>
</g>
<text
- x="840.1828"
- y="234.34692"
- transform="matrix(0.70710678,0.70710678,-0.70710678,0.70710678,0,0)"
+ x="861.39557"
+ y="213.1337"
+ transform="rotate(45)"
id="text4090-8-5-6-9-4-6-6-8-7-4"
xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- sodipodi:linespacing="125%"><tspan
- x="840.1828"
- y="234.34692"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:0%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none"><tspan
+ x="861.39557"
+ y="213.1337"
id="tspan4092-8-5-5-3-4-0-6-2-11-0"
- style="font-size:21px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">+</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:21px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">+</tspan></text>
<g
transform="translate(1.0962334,-2.7492248)"
id="g3595">
@@ -1347,42 +1308,41 @@
y="1037.0271"
id="text4090-8-7-8-7-6-3-8-4-1-2"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="30.942892"
y="1037.0271"
id="tspan4092-8-6-3-1-8-4-4-55-7-3"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="25.247679"
y="1037.0271"
id="text4090-8-7-8-7-6-3-8-4-1-2-5"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="25.247679"
y="1037.0271"
id="tspan4092-8-6-3-1-8-4-4-55-7-3-7"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="19.552465"
y="1037.0271"
id="text4090-8-7-8-7-6-3-8-4-1-2-7"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="19.552465"
y="1037.0271"
id="tspan4092-8-6-3-1-8-4-4-55-7-3-9"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="42.830166"
y="1033.2393"
id="text4090-8-7-8-7-6-3-8-4-8"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="42.830166"
y="1033.2393"
id="tspan4092-8-6-3-1-8-4-4-55-2"
- style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">New header files must get a new page in the API docs.</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:125%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;writing-mode:lr-tb;text-anchor:start">New header files must get a new page in the API docs.</tspan></text>
</g>
<g
transform="translate(1.0962334,-2.7492248)"
@@ -1392,52 +1352,51 @@
y="1046.0962"
id="text4090-8-7-8-7-6-3-8-2"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="42.212418"
y="1046.0962"
id="tspan4092-8-6-3-1-8-4-4-5"
- style="font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">Available from patchwork, or email header. Reply to Cover letters.</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:125%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;writing-mode:lr-tb;text-anchor:start">Available from patchwork, or email header. Reply to Cover letters.</tspan></text>
<text
x="31.140535"
y="1049.8527"
id="text4090-8-7-8-7-6-3-8-4-1-2-2"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="31.140535"
y="1049.8527"
id="tspan4092-8-6-3-1-8-4-4-55-7-3-3"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="25.445322"
y="1049.8527"
id="text4090-8-7-8-7-6-3-8-4-1-2-5-2"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="25.445322"
y="1049.8527"
id="tspan4092-8-6-3-1-8-4-4-55-7-3-7-2"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="19.750109"
y="1049.8527"
id="text4090-8-7-8-7-6-3-8-4-1-2-7-1"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="19.750109"
y="1049.8527"
id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
<text
x="14.016749"
y="1049.8527"
id="text4090-8-7-8-7-6-3-8-4-1-2-7-1-8"
xml:space="preserve"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace Bold"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:0%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
x="14.016749"
y="1049.8527"
id="tspan4092-8-6-3-1-8-4-4-55-7-3-9-6-5"
- style="font-size:13px;font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace Bold">*</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:300;font-stretch:normal;font-size:13px;line-height:125%;font-family:monospace;-inkscape-font-specification:'Monospace Bold';text-align:start;writing-mode:lr-tb;text-anchor:start">*</tspan></text>
</g>
<rect
width="196.44218"
@@ -1449,36 +1408,35 @@
id="rect3239-0-9-4-2-1-9-9-7"
style="fill:none;stroke:#00233b;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
<rect
- width="678.43036"
- height="43.497677"
- rx="7.8557949"
- ry="6.7630997"
- x="31.274473"
- y="836.69745"
+ width="710.73767"
+ height="43.476074"
+ rx="8.2298937"
+ ry="6.7597408"
+ x="31.285275"
+ y="836.70825"
id="rect3239-0-9-4-3-6"
- style="fill:none;stroke:#00233b;stroke-width:0.92794865;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+ style="fill:none;stroke:#00233b;stroke-width:0.949551;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
x="73.804535"
y="864.28137"
id="text4090-8-1-8-65-9-1"
xml:space="preserve"
- style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:0%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
sodipodi:role="line"
x="73.804535"
y="864.28137"
- id="tspan3266-8">git format-patch -[N]</tspan></text>
+ id="tspan3266-8"
+ style="font-size:19px;line-height:1.25;font-family:monospace">git format-patch -[N]</tspan></text>
<text
x="342.70221"
y="862.83478"
id="text4090-8-1-8-65-9-1-7"
xml:space="preserve"
- style="font-size:19px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Monospace;-inkscape-font-specification:Monospace"
- sodipodi:linespacing="125%"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:0%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none"><tspan
sodipodi:role="line"
x="342.70221"
y="862.83478"
id="tspan3266-8-2"
- style="font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Monospace;-inkscape-font-specification:Monospace">// creates .patch files for final review</tspan></text>
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:14px;line-height:125%;font-family:monospace;-inkscape-font-specification:Monospace;text-align:start;writing-mode:lr-tb;text-anchor:start">// creates .patch files for final review</tspan></text>
</g>
</svg>
--
2.22.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 12/14] doc: remove references to make from contributing guide
@ 2020-10-21 8:17 9% ` Ciara Power
2020-10-21 8:17 2% ` [dpdk-dev] [PATCH v7 14/14] doc: update patch cheatsheet to use meson Ciara Power
1 sibling, 0 replies; 200+ results
From: Ciara Power @ 2020-10-21 8:17 UTC (permalink / raw)
To: dev; +Cc: Ciara Power, Louise Kilheeney
Make is no longer supported for compiling DPDK, references are now
removed in the documentation.
Signed-off-by: Ciara Power <ciara.power@intel.com>
Signed-off-by: Louise Kilheeney <louise.kilheeney@intel.com>
---
v7:
- Updated exec_env and arch lists.
- Updated documentation build instruction.
v5:
- Removed reference to test-build.sh used for Make.
- Added point back in for handling specific code, reworded as
necessary.
- Added library statistics section, removing only the mention of
CONFIG options.
---
doc/guides/contributing/design.rst | 37 ++++++++---------------
doc/guides/contributing/documentation.rst | 31 ++++---------------
doc/guides/contributing/patches.rst | 6 ++--
3 files changed, 21 insertions(+), 53 deletions(-)
diff --git a/doc/guides/contributing/design.rst b/doc/guides/contributing/design.rst
index 5fe7f63942..cbd0c3dd8e 100644
--- a/doc/guides/contributing/design.rst
+++ b/doc/guides/contributing/design.rst
@@ -21,7 +21,7 @@ A file located in a subdir of "linux" is specific to this execution environment.
When absolutely necessary, there are several ways to handle specific code:
-* Use a ``#ifdef`` with the CONFIG option in the C code.
+* Use a ``#ifdef`` with a build definition macro in the C code.
This can be done when the differences are small and they can be embedded in the same C file:
.. code-block:: c
@@ -32,30 +32,25 @@ When absolutely necessary, there are several ways to handle specific code:
titi();
#endif
-* Use the CONFIG option in the Makefile. This is done when the differences are more significant.
+* Use build definition macros and conditions in the Meson build file. This is done when the differences are more significant.
In this case, the code is split into two separate files that are architecture or environment specific.
This should only apply inside the EAL library.
-.. note::
-
- As in the linux kernel, the ``CONFIG_`` prefix is not used in C code.
- This is only needed in Makefiles or shell scripts.
-
Per Architecture Sources
~~~~~~~~~~~~~~~~~~~~~~~~
-The following config options can be used:
+The following macro options can be used:
-* ``CONFIG_RTE_ARCH`` is a string that contains the name of the architecture.
-* ``CONFIG_RTE_ARCH_I686``, ``CONFIG_RTE_ARCH_X86_64``, ``CONFIG_RTE_ARCH_X86_64_32`` or ``CONFIG_RTE_ARCH_PPC_64`` are defined only if we are building for those architectures.
+* ``RTE_ARCH`` is a string that contains the name of the architecture.
+* ``RTE_ARCH_I686``, ``RTE_ARCH_X86_64``, ``RTE_ARCH_X86_64_32``, ``RTE_ARCH_PPC_64``, ``RTE_ARCH_ARM``, ``RTE_ARCH_ARMv7`` or ``RTE_ARCH_ARM64`` are defined only if we are building for those architectures.
Per Execution Environment Sources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The following config options can be used:
+The following macro options can be used:
-* ``CONFIG_RTE_EXEC_ENV`` is a string that contains the name of the executive environment.
-* ``CONFIG_RTE_EXEC_ENV_FREEBSD`` or ``CONFIG_RTE_EXEC_ENV_LINUX`` are defined only if we are building for this execution environment.
+* ``RTE_EXEC_ENV`` is a string that contains the name of the executive environment.
+* ``RTE_EXEC_ENV_FREEBSD``, ``RTE_EXEC_ENV_LINUX`` or ``RTE_EXEC_ENV_WINDOWS`` are defined only if we are building for this execution environment.
Mbuf features
-------------
@@ -87,22 +82,14 @@ requirements for preventing ABI changes when implementing statistics.
Mechanism to allow the application to turn library statistics on and off
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Each library that maintains statistics counters should provide a single build
-time flag that decides whether the statistics counter collection is enabled or
-not. This flag should be exposed as a variable within the DPDK configuration
-file. When this flag is set, all the counters supported by current library are
+Having runtime support for enabling/disabling library statistics is recommended,
+as build-time options should be avoided. However, if build-time options are used,
+for example as in the table library, the options can be set using c_args.
+When this flag is set, all the counters supported by current library are
collected for all the instances of every object type provided by the library.
When this flag is cleared, none of the counters supported by the current library
are collected for any instance of any object type provided by the library:
-.. code-block:: console
-
- # DPDK file config/common_linux, config/common_freebsd, etc.
- CONFIG_RTE_<LIBRARY_NAME>_STATS_COLLECT=y/n
-
-The default value for this DPDK configuration file variable (either "yes" or
-"no") is decided by each library.
-
Prevention of ABI changes due to library statistics support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index be985e6cf8..a4e6be6aca 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -218,25 +218,14 @@ Build commands
~~~~~~~~~~~~~~
The documentation is built using the standard DPDK build system.
-Some examples are shown below:
-* Generate all the documentation targets::
+To build the documentation::
- make doc
+ ninja -C build doc
-* Generate the Doxygen API documentation in Html::
+See :doc:`../linux_gsg/build_dpdk` for more detail on compiling DPDK with meson.
- make doc-api-html
-
-* Generate the guides documentation in Html::
-
- make doc-guides-html
-
-* Generate the guides documentation in Pdf::
-
- make doc-guides-pdf
-
-The output of these commands is generated in the ``build`` directory::
+The output is generated in the ``build`` directory::
build/doc
|-- html
@@ -251,10 +240,6 @@ The output of these commands is generated in the ``build`` directory::
Make sure to fix any Sphinx or Doxygen warnings when adding or updating documentation.
-The documentation output files can be removed as follows::
-
- make doc-clean
-
Document Guidelines
-------------------
@@ -304,7 +289,7 @@ Line Length
Long literal command lines can be shown wrapped with backslashes. For
example::
- testpmd -l 2-3 -n 4 \
+ dpdk-testpmd -l 2-3 -n 4 \
--vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \
-- -i --tx-offloads=0x0000002c --enable-lro --txq=2 --rxq=2 \
--txd=1024 --rxd=1024
@@ -456,7 +441,7 @@ Code and Literal block sections
For long literal lines that exceed that limit try to wrap the text at sensible locations.
For example a long command line could be documented like this and still work if copied directly from the docs::
- build/app/testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \
+ ./<build_dir>/app/dpdk-testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \
--vdev=net_pcap1,iface=eth1 \
-- -i --nb-cores=2 --nb-ports=2 \
--total-num-mbufs=2048
@@ -739,9 +724,5 @@ The following are some guidelines for use of Doxygen in the DPDK API documentati
/** Array of physical page addresses for the mempool buffer. */
phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
-* Check for Doxygen warnings in new code by checking the API documentation build::
-
- make doc-api-html >/dev/null
-
* Read the rendered section of the documentation that you have added for correctness, clarity and consistency
with the surrounding text.
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 9ff60944c3..9fa5a79c85 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -486,9 +486,9 @@ By default, ABI compatibility checks are disabled.
To enable them, a reference version must be selected via the environment
variable ``DPDK_ABI_REF_VERSION``.
-The ``devtools/test-build.sh`` and ``devtools/test-meson-builds.sh`` scripts
-then build this reference version in a temporary directory and store the
-results in a subfolder of the current working directory.
+The ``devtools/test-meson-builds.sh`` script then build this reference version
+in a temporary directory and store the results in a subfolder of the current
+working directory.
The environment variable ``DPDK_ABI_REF_DIR`` can be set so that the results go
to a different location.
--
2.22.0
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v2 2/2] lpm: hide internal data
2020-10-21 7:58 0% ` Thomas Monjalon
@ 2020-10-21 8:15 0% ` Ruifeng Wang
0 siblings, 0 replies; 200+ results
From: Ruifeng Wang @ 2020-10-21 8:15 UTC (permalink / raw)
To: thomas
Cc: Bruce Richardson, Vladimir Medvedkin, dev, Honnappa Nagarahalli,
nd, David Marchand, Kevin Traynor, nd
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, October 21, 2020 3:59 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Vladimir Medvedkin
> <vladimir.medvedkin@intel.com>; dev@dpdk.org; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>; David Marchand
> <david.marchand@redhat.com>; Kevin Traynor <ktraynor@redhat.com>
> Subject: Re: [PATCH v2 2/2] lpm: hide internal data
>
> 21/10/2020 05:02, Ruifeng Wang:
> > --- a/doc/guides/rel_notes/release_20_11.rst
> > +++ b/doc/guides/rel_notes/release_20_11.rst
> > @@ -602,6 +602,8 @@ ABI Changes
> >
> > * sched: Added new fields to ``struct rte_sched_subport_port_params``.
> >
> > +* lpm: Removed fields other than ``tbl24`` and ``tbl8`` from the struct
> ``rte_lpm``.
> > + The removed fields were made internal.
> >
> > Known Issues
> > ------------
>
> Can be changed on apply, but please note when adding a new paragraph,
> that you should add a new blank line, keeping 2 blank lines before the next
> section as it was before your patch.
>
> PS: having this kind of minor comment means you are a regular contributor,
> so we expect perfect patches :)
>
Sorry for the extra burden added to merge. Will pay more attention on format and other details.
Thanks.
> Thanks
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/2] lpm: hide internal data
2020-10-21 3:02 5% ` [dpdk-dev] [PATCH v2 2/2] lpm: hide internal data Ruifeng Wang
@ 2020-10-21 7:58 0% ` Thomas Monjalon
2020-10-21 8:15 0% ` Ruifeng Wang
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-10-21 7:58 UTC (permalink / raw)
To: Ruifeng Wang
Cc: Bruce Richardson, Vladimir Medvedkin, dev, honnappa.nagarahalli,
nd, David Marchand, Kevin Traynor
21/10/2020 05:02, Ruifeng Wang:
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -602,6 +602,8 @@ ABI Changes
>
> * sched: Added new fields to ``struct rte_sched_subport_port_params``.
>
> +* lpm: Removed fields other than ``tbl24`` and ``tbl8`` from the struct ``rte_lpm``.
> + The removed fields were made internal.
>
> Known Issues
> ------------
Can be changed on apply, but please note when adding a new paragraph,
that you should add a new blank line, keeping 2 blank lines
before the next section as it was before your patch.
PS: having this kind of minor comment means you are a regular
contributor, so we expect perfect patches :)
Thanks
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 2/2] lpm: hide internal data
@ 2020-10-21 3:02 5% ` Ruifeng Wang
2020-10-21 7:58 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ruifeng Wang @ 2020-10-21 3:02 UTC (permalink / raw)
To: Bruce Richardson, Vladimir Medvedkin
Cc: dev, honnappa.nagarahalli, nd, Ruifeng Wang, David Marchand,
Kevin Traynor, Thomas Monjalon
Fields except tbl24 and tbl8 in rte_lpm structure have no
need to be exposed to the user.
Hide the unneeded exposure of structure fields for better
ABI maintainability.
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
---
v2:
Added release notes.
doc/guides/rel_notes/release_20_11.rst | 2 +
lib/librte_lpm/rte_lpm.c | 152 +++++++++++++++----------
lib/librte_lpm/rte_lpm.h | 7 --
3 files changed, 93 insertions(+), 68 deletions(-)
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 0d45b5003..3b5034ce5 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -602,6 +602,8 @@ ABI Changes
* sched: Added new fields to ``struct rte_sched_subport_port_params``.
+* lpm: Removed fields other than ``tbl24`` and ``tbl8`` from the struct ``rte_lpm``.
+ The removed fields were made internal.
Known Issues
------------
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index 51a0ae578..88d31df6d 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -42,9 +42,17 @@ enum valid_flag {
/** @internal LPM structure. */
struct __rte_lpm {
- /* LPM metadata. */
+ /* Exposed LPM data. */
struct rte_lpm lpm;
+ /* LPM metadata. */
+ char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
+ uint32_t max_rules; /**< Max. balanced rules per lpm. */
+ uint32_t number_tbl8s; /**< Number of tbl8s. */
+ /**< Rule info table. */
+ struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH];
+ struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
+
/* RCU config. */
struct rte_rcu_qsbr *v; /* RCU QSBR variable. */
enum rte_lpm_qsbr_mode rcu_mode;/* Blocking, defer queue. */
@@ -104,7 +112,7 @@ depth_to_range(uint8_t depth)
struct rte_lpm *
rte_lpm_find_existing(const char *name)
{
- struct rte_lpm *l = NULL;
+ struct __rte_lpm *l = NULL;
struct rte_tailq_entry *te;
struct rte_lpm_list *lpm_list;
@@ -123,7 +131,7 @@ rte_lpm_find_existing(const char *name)
return NULL;
}
- return l;
+ return &l->lpm;
}
/*
@@ -157,8 +165,8 @@ rte_lpm_create(const char *name, int socket_id,
/* guarantee there's no existing */
TAILQ_FOREACH(te, lpm_list, next) {
- lpm = te->data;
- if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
+ internal_lpm = te->data;
+ if (strncmp(name, internal_lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
@@ -193,10 +201,10 @@ rte_lpm_create(const char *name, int socket_id,
}
lpm = &internal_lpm->lpm;
- lpm->rules_tbl = rte_zmalloc_socket(NULL,
+ internal_lpm->rules_tbl = rte_zmalloc_socket(NULL,
(size_t)rules_size, RTE_CACHE_LINE_SIZE, socket_id);
- if (lpm->rules_tbl == NULL) {
+ if (internal_lpm->rules_tbl == NULL) {
RTE_LOG(ERR, LPM, "LPM rules_tbl memory allocation failed\n");
rte_free(internal_lpm);
internal_lpm = NULL;
@@ -211,7 +219,7 @@ rte_lpm_create(const char *name, int socket_id,
if (lpm->tbl8 == NULL) {
RTE_LOG(ERR, LPM, "LPM tbl8 memory allocation failed\n");
- rte_free(lpm->rules_tbl);
+ rte_free(internal_lpm->rules_tbl);
rte_free(internal_lpm);
internal_lpm = NULL;
lpm = NULL;
@@ -221,11 +229,11 @@ rte_lpm_create(const char *name, int socket_id,
}
/* Save user arguments. */
- lpm->max_rules = config->max_rules;
- lpm->number_tbl8s = config->number_tbl8s;
- strlcpy(lpm->name, name, sizeof(lpm->name));
+ internal_lpm->max_rules = config->max_rules;
+ internal_lpm->number_tbl8s = config->number_tbl8s;
+ strlcpy(internal_lpm->name, name, sizeof(internal_lpm->name));
- te->data = lpm;
+ te->data = internal_lpm;
TAILQ_INSERT_TAIL(lpm_list, te, next);
@@ -241,7 +249,7 @@ rte_lpm_create(const char *name, int socket_id,
void
rte_lpm_free(struct rte_lpm *lpm)
{
- struct __rte_lpm *internal_lpm;
+ struct __rte_lpm *internal_lpm = NULL;
struct rte_lpm_list *lpm_list;
struct rte_tailq_entry *te;
@@ -255,7 +263,8 @@ rte_lpm_free(struct rte_lpm *lpm)
/* find our tailq entry */
TAILQ_FOREACH(te, lpm_list, next) {
- if (te->data == (void *) lpm)
+ internal_lpm = te->data;
+ if (&internal_lpm->lpm == lpm)
break;
}
if (te != NULL)
@@ -263,11 +272,10 @@ rte_lpm_free(struct rte_lpm *lpm)
rte_mcfg_tailq_write_unlock();
- internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
if (internal_lpm->dq != NULL)
rte_rcu_qsbr_dq_delete(internal_lpm->dq);
rte_free(lpm->tbl8);
- rte_free(lpm->rules_tbl);
+ rte_free(internal_lpm->rules_tbl);
rte_free(internal_lpm);
rte_free(te);
}
@@ -310,11 +318,11 @@ rte_lpm_rcu_qsbr_add(struct rte_lpm *lpm, struct rte_lpm_rcu_config *cfg)
} else if (cfg->mode == RTE_LPM_QSBR_MODE_DQ) {
/* Init QSBR defer queue. */
snprintf(rcu_dq_name, sizeof(rcu_dq_name),
- "LPM_RCU_%s", lpm->name);
+ "LPM_RCU_%s", internal_lpm->name);
params.name = rcu_dq_name;
params.size = cfg->dq_size;
if (params.size == 0)
- params.size = lpm->number_tbl8s;
+ params.size = internal_lpm->number_tbl8s;
params.trigger_reclaim_limit = cfg->reclaim_thd;
params.max_reclaim_size = cfg->reclaim_max;
if (params.max_reclaim_size == 0)
@@ -352,74 +360,79 @@ static int32_t
rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
uint32_t next_hop)
{
- uint32_t rule_gindex, rule_index, last_rule;
+ uint32_t rule_gindex, rule_index, last_rule, first_index;
+ struct __rte_lpm *i_lpm;
int i;
VERIFY_DEPTH(depth);
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
/* Scan through rule group to see if rule already exists. */
- if (lpm->rule_info[depth - 1].used_rules > 0) {
+ if (i_lpm->rule_info[depth - 1].used_rules > 0) {
/* rule_gindex stands for rule group index. */
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
+ rule_gindex = i_lpm->rule_info[depth - 1].first_rule;
/* Initialise rule_index to point to start of rule group. */
rule_index = rule_gindex;
/* Last rule = Last used rule in this rule group. */
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
+ last_rule = rule_gindex
+ + i_lpm->rule_info[depth - 1].used_rules;
for (; rule_index < last_rule; rule_index++) {
/* If rule already exists update next hop and return. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked) {
+ if (i_lpm->rules_tbl[rule_index].ip == ip_masked) {
- if (lpm->rules_tbl[rule_index].next_hop
+ if (i_lpm->rules_tbl[rule_index].next_hop
== next_hop)
return -EEXIST;
- lpm->rules_tbl[rule_index].next_hop = next_hop;
+ i_lpm->rules_tbl[rule_index].next_hop
+ = next_hop;
return rule_index;
}
}
- if (rule_index == lpm->max_rules)
+ if (rule_index == i_lpm->max_rules)
return -ENOSPC;
} else {
/* Calculate the position in which the rule will be stored. */
rule_index = 0;
for (i = depth - 1; i > 0; i--) {
- if (lpm->rule_info[i - 1].used_rules > 0) {
- rule_index = lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules;
+ if (i_lpm->rule_info[i - 1].used_rules > 0) {
+ rule_index = i_lpm->rule_info[i - 1].first_rule
+ + i_lpm->rule_info[i - 1].used_rules;
break;
}
}
- if (rule_index == lpm->max_rules)
+ if (rule_index == i_lpm->max_rules)
return -ENOSPC;
- lpm->rule_info[depth - 1].first_rule = rule_index;
+ i_lpm->rule_info[depth - 1].first_rule = rule_index;
}
/* Make room for the new rule in the array. */
for (i = RTE_LPM_MAX_DEPTH; i > depth; i--) {
- if (lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules == lpm->max_rules)
+ first_index = i_lpm->rule_info[i - 1].first_rule;
+ if (first_index + i_lpm->rule_info[i - 1].used_rules
+ == i_lpm->max_rules)
return -ENOSPC;
- if (lpm->rule_info[i - 1].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i - 1].first_rule
- + lpm->rule_info[i - 1].used_rules]
- = lpm->rules_tbl[lpm->rule_info[i - 1].first_rule];
- lpm->rule_info[i - 1].first_rule++;
+ if (i_lpm->rule_info[i - 1].used_rules > 0) {
+ i_lpm->rules_tbl[first_index
+ + i_lpm->rule_info[i - 1].used_rules]
+ = i_lpm->rules_tbl[first_index];
+ i_lpm->rule_info[i - 1].first_rule++;
}
}
/* Add the new rule. */
- lpm->rules_tbl[rule_index].ip = ip_masked;
- lpm->rules_tbl[rule_index].next_hop = next_hop;
+ i_lpm->rules_tbl[rule_index].ip = ip_masked;
+ i_lpm->rules_tbl[rule_index].next_hop = next_hop;
/* Increment the used rules counter for this rule group. */
- lpm->rule_info[depth - 1].used_rules++;
+ i_lpm->rule_info[depth - 1].used_rules++;
return rule_index;
}
@@ -432,23 +445,25 @@ static void
rule_delete(struct rte_lpm *lpm, int32_t rule_index, uint8_t depth)
{
int i;
+ struct __rte_lpm *i_lpm;
VERIFY_DEPTH(depth);
- lpm->rules_tbl[rule_index] =
- lpm->rules_tbl[lpm->rule_info[depth - 1].first_rule
- + lpm->rule_info[depth - 1].used_rules - 1];
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
+ i_lpm->rules_tbl[rule_index] =
+ i_lpm->rules_tbl[i_lpm->rule_info[depth - 1].first_rule
+ + i_lpm->rule_info[depth - 1].used_rules - 1];
for (i = depth; i < RTE_LPM_MAX_DEPTH; i++) {
- if (lpm->rule_info[i].used_rules > 0) {
- lpm->rules_tbl[lpm->rule_info[i].first_rule - 1] =
- lpm->rules_tbl[lpm->rule_info[i].first_rule
- + lpm->rule_info[i].used_rules - 1];
- lpm->rule_info[i].first_rule--;
+ if (i_lpm->rule_info[i].used_rules > 0) {
+ i_lpm->rules_tbl[i_lpm->rule_info[i].first_rule - 1] =
+ i_lpm->rules_tbl[i_lpm->rule_info[i].first_rule
+ + i_lpm->rule_info[i].used_rules - 1];
+ i_lpm->rule_info[i].first_rule--;
}
}
- lpm->rule_info[depth - 1].used_rules--;
+ i_lpm->rule_info[depth - 1].used_rules--;
}
/*
@@ -459,16 +474,18 @@ static int32_t
rule_find(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth)
{
uint32_t rule_gindex, last_rule, rule_index;
+ struct __rte_lpm *internal_lpm;
VERIFY_DEPTH(depth);
- rule_gindex = lpm->rule_info[depth - 1].first_rule;
- last_rule = rule_gindex + lpm->rule_info[depth - 1].used_rules;
+ internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
+ rule_gindex = internal_lpm->rule_info[depth - 1].first_rule;
+ last_rule = rule_gindex + internal_lpm->rule_info[depth - 1].used_rules;
/* Scan used rules at given depth to find rule. */
for (rule_index = rule_gindex; rule_index < last_rule; rule_index++) {
/* If rule is found return the rule index. */
- if (lpm->rules_tbl[rule_index].ip == ip_masked)
+ if (internal_lpm->rules_tbl[rule_index].ip == ip_masked)
return rule_index;
}
@@ -484,9 +501,11 @@ _tbl8_alloc(struct rte_lpm *lpm)
{
uint32_t group_idx; /* tbl8 group index. */
struct rte_lpm_tbl_entry *tbl8_entry;
+ struct __rte_lpm *i_lpm;
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
/* Scan through tbl8 to find a free (i.e. INVALID) tbl8 group. */
- for (group_idx = 0; group_idx < lpm->number_tbl8s; group_idx++) {
+ for (group_idx = 0; group_idx < i_lpm->number_tbl8s; group_idx++) {
tbl8_entry = &lpm->tbl8[group_idx *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES];
/* If a free tbl8 group is found clean it and set as VALID. */
@@ -844,6 +863,7 @@ uint32_t *next_hop)
{
uint32_t ip_masked;
int32_t rule_index;
+ struct __rte_lpm *internal_lpm;
/* Check user arguments. */
if ((lpm == NULL) ||
@@ -855,8 +875,9 @@ uint32_t *next_hop)
ip_masked = ip & depth_to_mask(depth);
rule_index = rule_find(lpm, ip_masked, depth);
+ internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
if (rule_index >= 0) {
- *next_hop = lpm->rules_tbl[rule_index].next_hop;
+ *next_hop = internal_lpm->rules_tbl[rule_index].next_hop;
return 1;
}
@@ -897,7 +918,9 @@ delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
tbl24_range = depth_to_range(depth);
tbl24_index = (ip_masked >> 8);
struct rte_lpm_tbl_entry zero_tbl24_entry = {0};
+ struct __rte_lpm *i_lpm;
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
/*
* Firstly check the sub_rule_index. A -1 indicates no replacement rule
* and a positive number indicates a sub_rule_index.
@@ -939,7 +962,7 @@ delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
*/
struct rte_lpm_tbl_entry new_tbl24_entry = {
- .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
+ .next_hop = i_lpm->rules_tbl[sub_rule_index].next_hop,
.valid = VALID,
.valid_group = 0,
.depth = sub_rule_depth,
@@ -949,7 +972,7 @@ delete_depth_small(struct rte_lpm *lpm, uint32_t ip_masked,
.valid = VALID,
.valid_group = VALID,
.depth = sub_rule_depth,
- .next_hop = lpm->rules_tbl
+ .next_hop = i_lpm->rules_tbl
[sub_rule_index].next_hop,
};
@@ -1048,6 +1071,7 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
uint32_t tbl24_index, tbl8_group_index, tbl8_group_start, tbl8_index,
tbl8_range, i;
int32_t tbl8_recycle_index, status = 0;
+ struct __rte_lpm *i_lpm;
/*
* Calculate the index into tbl24 and range. Note: All depths larger
@@ -1061,6 +1085,7 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
tbl8_index = tbl8_group_start + (ip_masked & 0xFF);
tbl8_range = depth_to_range(depth);
+ i_lpm = container_of(lpm, struct __rte_lpm, lpm);
if (sub_rule_index < 0) {
/*
* Loop through the range of entries on tbl8 for which the
@@ -1076,7 +1101,7 @@ delete_depth_big(struct rte_lpm *lpm, uint32_t ip_masked,
.valid = VALID,
.depth = sub_rule_depth,
.valid_group = lpm->tbl8[tbl8_group_start].valid_group,
- .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
+ .next_hop = i_lpm->rules_tbl[sub_rule_index].next_hop,
};
/*
@@ -1188,16 +1213,21 @@ rte_lpm_delete(struct rte_lpm *lpm, uint32_t ip, uint8_t depth)
void
rte_lpm_delete_all(struct rte_lpm *lpm)
{
+ struct __rte_lpm *internal_lpm;
+
+ internal_lpm = container_of(lpm, struct __rte_lpm, lpm);
/* Zero rule information. */
- memset(lpm->rule_info, 0, sizeof(lpm->rule_info));
+ memset(internal_lpm->rule_info, 0, sizeof(internal_lpm->rule_info));
/* Zero tbl24. */
memset(lpm->tbl24, 0, sizeof(lpm->tbl24));
/* Zero tbl8. */
memset(lpm->tbl8, 0, sizeof(lpm->tbl8[0])
- * RTE_LPM_TBL8_GROUP_NUM_ENTRIES * lpm->number_tbl8s);
+ * RTE_LPM_TBL8_GROUP_NUM_ENTRIES
+ * internal_lpm->number_tbl8s);
/* Delete all rules form the rules table. */
- memset(lpm->rules_tbl, 0, sizeof(lpm->rules_tbl[0]) * lpm->max_rules);
+ memset(internal_lpm->rules_tbl, 0,
+ sizeof(internal_lpm->rules_tbl[0]) * internal_lpm->max_rules);
}
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 5b3b7b5b5..9a0ac97ab 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
/** @internal LPM structure. */
struct rte_lpm {
- /* LPM metadata. */
- char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
- uint32_t max_rules; /**< Max. balanced rules per lpm. */
- uint32_t number_tbl8s; /**< Number of tbl8s. */
- struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**< Rule info table. */
-
/* LPM Tables. */
struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
__rte_cache_aligned; /**< LPM tbl24 table. */
struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
- struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
};
/** LPM RCU QSBR configuration structure. */
--
2.20.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v2 5/5] doc: change references to blacklist and whitelist
@ 2020-10-20 16:20 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-20 16:20 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Luca Boccassi
There are two areas where documentation needed update.
The first was use of whitelist when describing address
filtering.
The other is the legacy -w whitelist option for PCI
which is used in many examples
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Luca Boccassi <bluca@debian.org>
doc: replace -w with -a in the documentation
The -w option is deprecated and replaced with -a
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/cryptodevs/dpaa2_sec.rst | 6 ++--
doc/guides/cryptodevs/dpaa_sec.rst | 6 ++--
doc/guides/cryptodevs/qat.rst | 12 ++++----
doc/guides/eventdevs/octeontx2.rst | 20 ++++++-------
doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/build_sample_apps.rst | 2 +-
doc/guides/linux_gsg/eal_args.include.rst | 14 +++++-----
doc/guides/linux_gsg/linux_drivers.rst | 4 +--
doc/guides/mempool/octeontx2.rst | 4 +--
doc/guides/nics/bnxt.rst | 12 ++++----
doc/guides/nics/cxgbe.rst | 12 ++++----
doc/guides/nics/dpaa.rst | 6 ++--
doc/guides/nics/dpaa2.rst | 6 ++--
doc/guides/nics/enic.rst | 6 ++--
doc/guides/nics/fail_safe.rst | 16 +++++------
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 16 +++++------
doc/guides/nics/ice.rst | 28 +++++++++++++------
doc/guides/nics/ixgbe.rst | 4 +--
doc/guides/nics/mlx4.rst | 16 +++++------
doc/guides/nics/mlx5.rst | 12 ++++----
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/octeontx2.rst | 22 +++++++--------
doc/guides/nics/sfc_efx.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
doc/guides/prog_guide/multi_proc_support.rst | 4 +--
doc/guides/prog_guide/poll_mode_drv.rst | 6 ++--
.../prog_guide/switch_representation.rst | 6 ++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
doc/guides/sample_app_ug/bbdev_app.rst | 14 +++++-----
.../sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/ipsec_secgw.rst | 12 ++++----
doc/guides/sample_app_ug/l3_forward.rst | 6 ++--
.../sample_app_ug/l3_forward_access_ctrl.rst | 2 +-
.../sample_app_ug/l3_forward_power_man.rst | 2 +-
doc/guides/sample_app_ug/vdpa.rst | 2 +-
doc/guides/tools/cryptoperf.rst | 6 ++--
doc/guides/tools/flow-perf.rst | 2 +-
doc/guides/tools/testregex.rst | 2 +-
41 files changed, 166 insertions(+), 149 deletions(-)
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index 3053636b8295..b50fee76954a 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index db3c8e918945..38ad45e66d76 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -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
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index a0becf689109..d41ee82aff52 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -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.
@@ -264,7 +264,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 CONFIG_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
@@ -302,7 +302,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
@@ -662,7 +662,7 @@ QAT SYM crypto PMD can be tested by running the test application::
make defconfig
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_autotest
QAT ASYM crypto PMD can be tested by running the test application::
@@ -670,7 +670,7 @@ QAT ASYM crypto PMD can be tested by running the test application::
make defconfig
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>cryptodev_qat_asym_autotest
QAT compression PMD can be tested by running the test application::
@@ -679,7 +679,7 @@ QAT compression PMD can be tested by running the test application::
sed -i 's,\(CONFIG_RTE_COMPRESSDEV_TEST\)=n,\1=y,' build/.config
make -j
cd ./build/app
- ./test -l1 -n1 -w <your qat bdf>
+ ./test -l1 -n1 -a <your qat bdf>
RTE>>compressdev_autotest
diff --git a/doc/guides/eventdevs/octeontx2.rst b/doc/guides/eventdevs/octeontx2.rst
index 6502f6415fb4..1c671518a4db 100644
--- a/doc/guides/eventdevs/octeontx2.rst
+++ b/doc/guides/eventdevs/octeontx2.rst
@@ -66,7 +66,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``
@@ -74,7 +74,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``
@@ -89,7 +89,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``
@@ -98,7 +98,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``
@@ -107,7 +107,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``
@@ -118,7 +118,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``
@@ -126,7 +126,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``
@@ -136,7 +136,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``
@@ -146,7 +146,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``
@@ -156,7 +156,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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2a68f5fc3820..4fba671e4f5b 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 542246df686a..043a1dcee109 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -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``:
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 01afa1b42f94..dbd48ab4fafa 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -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.
+ PCI skip probe cannot be used with the only 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 probed devices.
.. Note::
- PCI whitelist cannot be used with ``-b`` option.
+ PCI only list cannot be used with the skip probe ``-b`` option.
* ``--vdev <device arguments>``
diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst
index 080b44955a11..ef8798569a80 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -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).
diff --git a/doc/guides/mempool/octeontx2.rst b/doc/guides/mempool/octeontx2.rst
index 49b45a04e8ec..efaef85f90fc 100644
--- a/doc/guides/mempool/octeontx2.rst
+++ b/doc/guides/mempool/octeontx2.rst
@@ -50,7 +50,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.
@@ -69,7 +69,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
~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index 28973fc3e2e9..82cabab6885d 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -258,8 +258,8 @@ The BNXT PMD supports hardware-based packet filtering:
Unicast MAC Filter
^^^^^^^^^^^^^^^^^^
-The application adds (or removes) MAC addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) MAC addresses to enable (or disable)
+filtering on MAC address used to accept packets.
.. code-block:: console
@@ -269,8 +269,8 @@ whitelist filtering to accept packets.
Multicast MAC Filter
^^^^^^^^^^^^^^^^^^^^
-Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+The application can add (or remove) Multicast addresses that enable (or disable)
+filtering on multicast MAC address used to accept packets.
.. code-block:: console
@@ -278,7 +278,7 @@ whitelist filtering to accept packets.
testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX)
Application adds (or removes) Multicast addresses to enable (or disable)
-whitelist filtering to accept packets.
+allowlist filtering to accept packets.
Note that the BNXT PMD supports up to 16 MC MAC filters. if the user adds more
than 16 MC MACs, the BNXT PMD puts the port into the Allmulticast mode.
@@ -728,7 +728,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
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 54a4c138998c..ee91c85ebfee 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -40,8 +40,8 @@ expose a single PCI bus address, thus, librte_pmd_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:
@@ -112,7 +112,7 @@ be passed as part of EAL arguments. For example,
.. code-block:: console
- testpmd -w 02:00.4,keep_ovlan=1 -- -i
+ testpmd -a 02:00.4,keep_ovlan=1 -- -i
Common Runtime Options
^^^^^^^^^^^^^^^^^^^^^^
@@ -317,7 +317,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
- testpmd -w 02:00.4,filtermode=0x88 -- -i
+ testpmd -a 02:00.4,filtermode=0x88 -- -i
- ``filtermask`` (default **0**)
@@ -344,7 +344,7 @@ CXGBE PF Only Runtime Options
.. code-block:: console
- testpmd -w 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
+ testpmd -a 02:00.4,filtermode=0x88,filtermask=0x80 -- -i
.. _driver-compilation:
@@ -776,7 +776,7 @@ devices managed by librte_pmd_cxgbe in FreeBSD operating system.
.. code-block:: console
- ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
+ ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -a 0000:02:00.4 -- -i
Example output:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 74d4a6058ef0..eb9defca0f09 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -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
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index ca6ba5b5e291..693be5ce8707 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -527,10 +527,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
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index a28a7f4e477a..fa8459435730 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -312,7 +312,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
@@ -378,7 +378,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``).
@@ -427,7 +427,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**
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index f80346a35898..25525ef19aad 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -60,7 +60,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
@@ -68,11 +68,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.
@@ -123,8 +123,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
@@ -132,13 +132,13 @@ 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
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 16e00b8f64b5..14b8d0f33fae 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -261,7 +261,7 @@ Supports enabling/disabling receiving multicast frames.
Unicast MAC filter
------------------
-Supports adding MAC addresses to enable whitelist filtering to accept packets.
+Supports adding MAC addresses to enable incoming filtering of packets.
* **[implements] eth_dev_ops**: ``mac_addr_set``, ``mac_addr_add``, ``mac_addr_remove``.
* **[implements] rte_eth_dev_data**: ``mac_addrs``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a0b81e66950f..0eb1d7c1af2f 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -194,7 +194,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
@@ -207,7 +207,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
@@ -222,7 +222,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.
@@ -234,7 +234,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``)
@@ -244,7 +244,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
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -479,7 +479,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.
@@ -487,7 +487,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.
@@ -822,7 +822,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::
- ./l3fwd -l 18-21 -n 4 -w 82:00.0 -w 85:00.0 \
+ ./l3fwd -l 18-21 -n 4 -a 82:00.0 -w 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,
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 25a821177a4c..bb76d62a0139 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -47,7 +47,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,
@@ -58,7 +58,7 @@ Runtime Config Options
In pipeline mode, a flow can be set at one specific stage by setting parameter
``priority``. Currently, we support two stages: priority = 0 or !0. Flows with
priority 0 located at the first pipeline stage which typically be used as a firewall
- to drop the packet on a blacklist(we called it permission stage). At this stage,
+ to drop the packet on a blocklist(we called it permission stage). At this stage,
flow rules are created for the device's exact match engine: switch. Flows with priority
!0 located at the second stage, typically packets are classified here and be steered to
specific queue or queue group (we called it distribution stage), At this stage, flow
@@ -70,7 +70,19 @@ 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
+
+- ``Flow Mark Support`` (default ``0``)
+
+ This is a hint to the driver to select the data path that supports flow mark extraction
+ by default.
+ NOTE: This is an experimental devarg, it will be removed when any of below conditions
+ is ready.
+ 1) all data paths support flow mark (currently vPMD does not)
+ 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a standard way to hint.
+ Example::
+
+ -a 80:00.0,flow-mark-support=1
- ``Protocol extraction for per queue``
@@ -79,8 +91,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.
@@ -91,14 +103,14 @@ Runtime Config Options
.. code-block:: console
- testpmd -w 18:00.0,proto_xtr='[(1,2-3,8-9):tcp,10-13:vlan]'
+ 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
- testpmd -w 18:00.0,proto_xtr=vlan,proto_xtr='[(1,2-3,8-9):tcp,10-23:ipv6]'
+ 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.
@@ -250,7 +262,7 @@ responses for the same from PF.
#. Bind the VF0, and run testpmd with 'cap=dcf' devarg::
- testpmd -l 22-25 -n 4 -w 18:01.0,cap=dcf -- -i
+ testpmd -l 22-25 -n 4 -a 18:01.0,cap=dcf -- -i
#. Monitor the VF2 interface network traffic::
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1f424b38ac3d..c801dbae8146 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -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.
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index 6818b6af515e..67e3964b2b3b 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -29,8 +29,8 @@ Most Mellanox ConnectX-3 devices provide two ports but expose a single PCI
bus address, thus unlike most drivers, librte_pmd_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 use block (or allow) a single port without also
+blocking (o allowing) the others on the same device.
Besides its dependency on libibverbs (that implies libmlx4 and associated
kernel support), librte_pmd_mlx4 relies heavily on system calls for control
@@ -422,7 +422,7 @@ devices managed by librte_pmd_mlx4.
eth4
eth5
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow argument::
{
for intf in eth2 eth3 eth4 eth5;
@@ -434,10 +434,10 @@ devices managed by librte_pmd_mlx4.
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::
@@ -450,7 +450,7 @@ devices managed by librte_pmd_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::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index a071db276fe4..b44490cfe5e4 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1537,7 +1537,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
eth32
eth33
-#. Optionally, retrieve their PCI bus addresses for whitelisting::
+#. Optionally, retrieve their PCI bus addresses for use in allow list::
{
for intf in eth2 eth3 eth4 eth5;
@@ -1549,10 +1549,10 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_mlx5.
Example output::
- -w 0000:05:00.1
- -w 0000:06:00.0
- -w 0000:06:00.1
- -w 0000:05:00.0
+ -i 0000:05:00.1
+ -i 0000:06:00.0
+ -i 0000:06:00.1
+ -i 0000:05:00.0
#. Request huge pages::
@@ -1560,7 +1560,7 @@ ConnectX-4/ConnectX-5/ConnectX-6/BlueField devices managed by librte_pmd_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 -i 05:00.0 -w 05:00.1 -w 06:00.0 -w 06:00.1 -- --rxq=2 --txq=2 -i
Example output::
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index 10f33a025ede..7766a76d7a6d 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -78,7 +78,7 @@ products) and the device argument `timestamp=1` must be used.
.. code-block:: console
- $RTE_TARGET/app/testpmd -w b3:00.0,timestamp=1 <other EAL params> -- <testpmd params>
+ $RTE_TARGET/app/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.
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index f3be79bbb8a3..9862a1d4508c 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -74,7 +74,7 @@ use arm64-octeontx2-linux-gcc as target.
.. code-block:: console
- ./build/app/testpmd -c 0x300 -w 0002:02:00.0 -- --portmask=0x1 --nb-cores=1 --port-topology=loop --rxq=1 --txq=1
+ ./build/app/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
@@ -127,7 +127,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.
@@ -138,7 +138,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.
@@ -150,7 +150,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.
@@ -162,7 +162,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.
@@ -174,7 +174,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
@@ -196,7 +196,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``)
@@ -205,7 +205,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).
@@ -216,7 +216,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``
@@ -224,7 +224,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::
@@ -240,7 +240,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:
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 959b52c1c333..64322442a003 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -295,7 +295,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.
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 7e44f846206c..3ce696b605d1 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -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
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index b1ef9eba59b8..db64503a9ab8 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -178,7 +178,7 @@ This section provides instructions to configure SR-IOV with Linux OS.
.. code-block:: console
- ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
+ ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -a 0002:01:00.2 \
-- -i --no-flush-rx \
--port-topology=loop
@@ -398,7 +398,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
-----------
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a470fd7f29bb..9af4d6192fd4 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -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
+Blocklisting
~~~~~~~~~~~~
-The EAL PCI device blacklist functionality can be used to mark certain NIC ports as blacklisted,
+The EAL PCI device blocklist 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 blocklisted are identified using the PCIe* description (Domain:Bus:Device.Function).
Misc Functions
~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a84083b96c8a..2d083b8a4f68 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -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 blocklisted in every other process.
Running Multiple Independent Groups of DPDK Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst
index 86e0a141e6c7..239ec820eaf5 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -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.
diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst
index cc1d0d7569cb..07ba12bea67e 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -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
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 0d45b500325f..28ab5a03be8c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -539,6 +539,11 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: The definitions related to including and excluding devices
+ has been changed from blacklist/whitelist to include/exclude.
+ 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.
ABI Changes
-----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 54ff6574aed8..f0947a7544e4 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -79,19 +79,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/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
+ $ ./build/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,
@@ -111,20 +111,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 white list. The argument format is <[domain:]bus:devid.func>.
* ``-m <string>``: Matrix for mapping ports to logical cores.
* ``-P``: PROMISCUOUS mode
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index dc7972aa9a5c..e4c23da9ebcb 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -46,7 +46,7 @@ these settings is shown below:
.. code-block:: console
- ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
+ ./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -i 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
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 434f484138d0..db2685660ff7 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -329,15 +329,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 allowed the Ethernet devices needed and therefore implicitly
+blocklisting all hardware crypto devices.
For example, something like the following command line:
.. code-block:: console
./build/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)" \
@@ -935,13 +935,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
@@ -1029,4 +1029,4 @@ Available options:
* ``-h`` Show usage.
If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 07c8d44936d6..5173da8b108a 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -138,17 +138,17 @@ Following is the sample command:
.. code-block:: console
- ./build/l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x3 --eventq-sched=ordered
+ ./build/l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered
or
.. code-block:: console
- ./build/l3fwd -l 0-3 -n 4 -w <event device> -- -p 0x03 --mode=eventdev --eventq-sched=ordered
+ ./build/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 adds the event device supported by platform. Way to pass this device may vary based on platform.
* The --mode option defines PMD to be used for packet I/O.
diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
index c2d4ca73abde..1e580ff86cf4 100644
--- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
+++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
@@ -18,7 +18,7 @@ The application loads two types of rules at initialization:
* Route information rules, which are used for L3 forwarding
-* Access Control List (ACL) rules that blacklist (or block) packets with a specific characteristic
+* Access Control List (ACL) rules that block packets with a specific characteristic
When packets are received from a port,
the application extracts the necessary information from the TCP/IP header of the received packet and
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index f05816d9b24e..bc162a0118ac 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -378,7 +378,7 @@ See :doc:`Power Management<../prog_guide/power_man>` chapter in the DPDK Program
.. code-block:: console
- ./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
+ ./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,
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index d66a724827af..60a7eb227db2 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -52,7 +52,7 @@ Take IFCVF driver for example:
.. code-block:: console
./vdpa -c 0x2 -n 4 --socket-mem 1024,1024 \
- -w 0000:06:00.3,vdpa=1 -w 0000:06:00.4,vdpa=1 \
+ -i 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
-- --interactive
.. note::
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 28b729dbda8b..72707e9a4a9d 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -417,7 +417,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
@@ -427,7 +427,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
@@ -437,7 +437,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
diff --git a/doc/guides/tools/flow-perf.rst b/doc/guides/tools/flow-perf.rst
index 7e5dc0c54b1a..4771e8ecf04d 100644
--- a/doc/guides/tools/flow-perf.rst
+++ b/doc/guides/tools/flow-perf.rst
@@ -59,7 +59,7 @@ with a ``--`` separator:
.. code-block:: console
- sudo ./dpdk-test-flow_perf -n 4 -w 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
+ sudo ./dpdk-test-flow_perf -n 4 -a 08:00.0 -- --ingress --ether --ipv4 --queue --flows-count=1000000
The command line options are:
diff --git a/doc/guides/tools/testregex.rst b/doc/guides/tools/testregex.rst
index 4317aab533e2..112b2bb773e7 100644
--- a/doc/guides/tools/testregex.rst
+++ b/doc/guides/tools/testregex.rst
@@ -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
--
2.27.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v3] mbuf: minor cleanup
@ 2020-10-20 11:55 0% ` Thomas Monjalon
2020-11-04 22:17 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-10-20 11:55 UTC (permalink / raw)
To: Morten Brørup; +Cc: dev, Olivier Matz
Hi Morten,
Any update about this patch please?
07/10/2020 11:16, Olivier Matz:
> Hi Morten,
>
> Thanks for this cleanup. Please see some comments below.
>
> On Wed, Sep 16, 2020 at 12:40:13PM +0200, Morten Brørup wrote:
> > The mbuf header files had some commenting style errors that affected the
> > API documentation.
> > Also, the RTE_ prefix was missing on a macro and a definition.
> >
> > Note: This patch does not touch the offload and attachment flags that are
> > also missing the RTE_ prefix.
> >
> > Changes only affecting documentation:
> > * Removed the MBUF_INVALID_PORT definition from rte_mbuf.h; it is
> > already defined in rte_mbuf_core.h.
> > This removal also reestablished the description of the
> > rte_pktmbuf_reset() function.
> > * Corrected the comment related to RTE_MBUF_MAX_NB_SEGS.
> > * Corrected the comment related to PKT_TX_QINQ_PKT.
> >
> > Changes regarding missing RTE_ prefix:
> > * Converted the MBUF_RAW_ALLOC_CHECK() macro to an
> > __rte_mbuf_raw_sanity_check() inline function.
> > Added backwards compatible macro with the original name.
> > * Renamed the MBUF_INVALID_PORT definition to RTE_MBUF_PORT_INVALID.
> > Added backwards compatible definition with the original name.
> >
> > v2:
> > * Use RTE_MBUF_PORT_INVALID instead of MBUF_INVALID_PORT in rte_mbuf.c.
> >
> > v3:
> > * The functions/macros used in __rte_mbuf_raw_sanity_check() require
> > RTE_ENABLE_ASSERT or RTE_LIBRTE_MBUF_DEBUG, or they don't use the mbuf
> > parameter, which generates a compiler waning. So mark the mbuf parameter
> > __rte_unused if none of them are defined.
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 7 ----
> > lib/librte_mbuf/rte_mbuf.c | 4 +-
> > lib/librte_mbuf/rte_mbuf.h | 55 +++++++++++++++++++---------
> > lib/librte_mbuf/rte_mbuf_core.h | 9 +++--
> > 4 files changed, 45 insertions(+), 30 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index 279eccb04..88d7d0761 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -294,13 +294,6 @@ Deprecation Notices
> > - https://patches.dpdk.org/patch/71457/
> > - https://patches.dpdk.org/patch/71456/
> >
> > -* rawdev: The rawdev APIs which take a device-specific structure as
> > - parameter directly, or indirectly via a "private" pointer inside another
> > - structure, will be modified to take an additional parameter of the
> > - structure size. The affected APIs will include ``rte_rawdev_info_get``,
> > - ``rte_rawdev_configure``, ``rte_rawdev_queue_conf_get`` and
> > - ``rte_rawdev_queue_setup``.
> > -
> > * acl: ``RTE_ACL_CLASSIFY_NUM`` enum value will be removed.
> > This enum value is not used inside DPDK, while it prevents to add new
> > classify algorithms without causing an ABI breakage.
>
> I think this change is not related.
>
> This makes me think that a deprecation notice could be done for the
> old names without the RTE_ prefix, to be removed in 21.11.
>
>
> > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> > index 8a456e5e6..53a015311 100644
> > --- a/lib/librte_mbuf/rte_mbuf.c
> > +++ b/lib/librte_mbuf/rte_mbuf.c
> > @@ -104,7 +104,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
> > /* init some constant fields */
> > m->pool = mp;
> > m->nb_segs = 1;
> > - m->port = MBUF_INVALID_PORT;
> > + m->port = RTE_MBUF_PORT_INVALID;
> > rte_mbuf_refcnt_set(m, 1);
> > m->next = NULL;
> > }
> > @@ -207,7 +207,7 @@ __rte_pktmbuf_init_extmem(struct rte_mempool *mp,
> > /* init some constant fields */
> > m->pool = mp;
> > m->nb_segs = 1;
> > - m->port = MBUF_INVALID_PORT;
> > + m->port = RTE_MBUF_PORT_INVALID;
> > m->ol_flags = EXT_ATTACHED_MBUF;
> > rte_mbuf_refcnt_set(m, 1);
> > m->next = NULL;
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index 7259575a7..406d3abb2 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -554,12 +554,36 @@ __rte_experimental
> > int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
> > const char **reason);
> >
> > -#define MBUF_RAW_ALLOC_CHECK(m) do { \
> > - RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1); \
> > - RTE_ASSERT((m)->next == NULL); \
> > - RTE_ASSERT((m)->nb_segs == 1); \
> > - __rte_mbuf_sanity_check(m, 0); \
> > -} while (0)
> > +#if defined(RTE_ENABLE_ASSERT) || defined(RTE_LIBRTE_MBUF_DEBUG)
>
> I don't see why this #if is needed. Wouldn't it work to have only
> one function definition with the __rte_unused attribute?
>
> > +/**
> > + * Sanity checks on a reinitialized mbuf.
> > + *
> > + * Check the consistency of the given reinitialized mbuf.
> > + * The function will cause a panic if corruption is detected.
> > + *
> > + * Check that the mbuf is properly reinitialized (refcnt=1, next=NULL,
> > + * nb_segs=1), as done by rte_pktmbuf_prefree_seg().
> > + *
>
> Maybe indicate that these checks are only done when debug is on.
>
> > + * @param m
> > + * The mbuf to be checked.
> > + */
> > +static __rte_always_inline void
> > +__rte_mbuf_raw_sanity_check(const struct rte_mbuf *m)
> > +{
> > + RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
> > + RTE_ASSERT(m->next == NULL);
> > + RTE_ASSERT(m->nb_segs == 1);
> > + __rte_mbuf_sanity_check(m, 0);
> > +}
> > +#else
> > +static __rte_always_inline void
> > +__rte_mbuf_raw_sanity_check(const struct rte_mbuf *m __rte_unused)
> > +{
> > + /* Nothing here. */
> > +}
> > +#endif
> > +/** For backwards compatibility. */
> > +#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_sanity_check(m)
>
> It looks that MBUF_RAW_ALLOC_CHECK() is also used in drivers/net/sfc,
> I think it should be updated too.
>
> >
> > /**
> > * Allocate an uninitialized mbuf from mempool *mp*.
> > @@ -586,7 +610,7 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct rte_mempool *mp)
> >
> > if (rte_mempool_get(mp, (void **)&m) < 0)
> > return NULL;
> > - MBUF_RAW_ALLOC_CHECK(m);
> > + __rte_mbuf_raw_sanity_check(m);
> > return m;
> > }
> >
> > @@ -609,10 +633,7 @@ rte_mbuf_raw_free(struct rte_mbuf *m)
> > {
> > RTE_ASSERT(!RTE_MBUF_CLONED(m) &&
> > (!RTE_MBUF_HAS_EXTBUF(m) || RTE_MBUF_HAS_PINNED_EXTBUF(m)));
> > - RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
> > - RTE_ASSERT(m->next == NULL);
> > - RTE_ASSERT(m->nb_segs == 1);
> > - __rte_mbuf_sanity_check(m, 0);
> > + __rte_mbuf_raw_sanity_check(m);
> > rte_mempool_put(m->pool, m);
> > }
> >
> > @@ -858,8 +879,6 @@ static inline void rte_pktmbuf_reset_headroom(struct rte_mbuf *m)
> > * @param m
> > * The packet mbuf to be reset.
> > */
> > -#define MBUF_INVALID_PORT UINT16_MAX
> > -
> > static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> > {
> > m->next = NULL;
> > @@ -868,7 +887,7 @@ static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> > m->vlan_tci = 0;
> > m->vlan_tci_outer = 0;
> > m->nb_segs = 1;
> > - m->port = MBUF_INVALID_PORT;
> > + m->port = RTE_MBUF_PORT_INVALID;
> >
> > m->ol_flags &= EXT_ATTACHED_MBUF;
> > m->packet_type = 0;
> > @@ -931,22 +950,22 @@ static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
> > switch (count % 4) {
> > case 0:
> > while (idx != count) {
> > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > case 3:
> > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > case 2:
> > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > case 1:
> > - MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
> > + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> > rte_pktmbuf_reset(mbufs[idx]);
> > idx++;
> > /* fall-through */
> > diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h
> > index 8cd7137ac..4ac5609e3 100644
> > --- a/lib/librte_mbuf/rte_mbuf_core.h
> > +++ b/lib/librte_mbuf/rte_mbuf_core.h
> > @@ -272,7 +272,7 @@ extern "C" {
> > * mbuf 'vlan_tci' & 'vlan_tci_outer' must be valid when this flag is set.
> > */
> > #define PKT_TX_QINQ (1ULL << 49)
> > -/* this old name is deprecated */
> > +/** This old name is deprecated. */
> > #define PKT_TX_QINQ_PKT PKT_TX_QINQ
> >
> > /**
> > @@ -686,7 +686,7 @@ struct rte_mbuf_ext_shared_info {
> > };
> > };
> >
> > -/**< Maximum number of nb_segs allowed. */
> > +/** Maximum number of nb_segs allowed. */
> > #define RTE_MBUF_MAX_NB_SEGS UINT16_MAX
> >
> > /**
> > @@ -714,7 +714,10 @@ struct rte_mbuf_ext_shared_info {
> > #define RTE_MBUF_DIRECT(mb) \
> > (!((mb)->ol_flags & (IND_ATTACHED_MBUF | EXT_ATTACHED_MBUF)))
> >
> > -#define MBUF_INVALID_PORT UINT16_MAX
> > +/** NULL value for the uint16_t port type. */
> > +#define RTE_MBUF_PORT_INVALID UINT16_MAX
>
> I don't really like talking about "NULL". What do you think instead of
> this wording?
>
> /** Uninitialized or unspecified port */
>
> > +/** For backwards compatibility. */
> > +#define MBUF_INVALID_PORT RTE_MBUF_PORT_INVALID
> >
> > /**
> > * A macro that points to an offset into the data in the mbuf.
>
> Thanks,
> Olivier
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/8] eal: cleanup resources on shutdown
@ 2020-10-19 22:24 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-10-19 22:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, David Marchand, ferruh.yigit, bruce.richardson, andrew.rybchenko
That's a pity this patchset is not concluded.
Please Stephen, could you respin with a fix?
03/05/2020 19:21, David Marchand:
> On Wed, Apr 29, 2020 at 1:58 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > Started using valgrind with DPDK, and there are lots of leftover
> > memory and file descriptors. This makes it hard to find application
> > leaks versus DPDK leaks.
> >
> > The DPDK has a function that applications can use to tell it
> > to cleanup resources on shutdown (rte_eal_cleanup). But the
> > current coverage of that API is spotty. Many internal parts of
> > DPDK leave files and allocated memory behind.
> >
> > This patch set is a first step at getting the sub-parts of
> > DPDK to cleanup after themselves. These are the easier ones,
> > the harder and more critical ones are in the drivers
> > and the memory subsystem.
> >
> > There are no new exposed API or ABI changes here.
> >
> > v3
> > - fix a couple of minor checkpatch complaints
> >
> > v2
> > - rebase after 20.05 file renames
> > - incorporate review comment feedback
> > - hold off some of the more involved patches for later
>
> Same segfault as v1.
>
> $ ./devtools/test-null.sh ./build/app/dpdk-testpmd 0x3 --plop
> ./build/app/dpdk-testpmd: unrecognized option '--plop'
> EAL: Detected 8 lcore(s)
> EAL: Detected 1 NUMA nodes
>
> Usage: ./build/app/dpdk-testpmd [options]
>
> (snip)
>
> EAL: FATAL: Invalid 'command line' arguments.
> EAL: Invalid 'command line' arguments.
> EAL: Error - exiting with code: 1
> Cause: Cannot init EAL: Invalid argument
> ./devtools/test-null.sh: line 32: 23134 Broken pipe (
> sleep 1 && echo stop )
> 23135 Segmentation fault (core dumped) | $testpmd -c
> $coremask --no-huge -m 20 $libs -w 0:0.0 --vdev net_null1 --vdev
> net_null2 $eal_options -- --no-mlockall --total-num-mbufs=2048
> $testpmd_options -ia
>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 13:53 0% ` Kevin Traynor
@ 2020-10-19 17:53 0% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2020-10-19 17:53 UTC (permalink / raw)
To: Ruifeng Wang, Kevin Traynor, Medvedkin, Vladimir, Bruce Richardson
Cc: dev, nd, Honnappa Nagarahalli, nd
<snip>
> > >>
> > >> Hi Ruifeng,
> > >>
> > >> On 15/09/2020 17:02, Bruce Richardson wrote:
> > >>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
> > >>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to
> > >>>> be exposed to the user.
> > >>>> Hide the unneeded exposure of structure fields for better ABI
> > >>>> maintainability.
> > >>>>
> > >>>> Suggested-by: David Marchand <david.marchand@redhat.com>
> > >>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > >>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
<snip>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate ABI version
@ 2020-10-19 9:41 9% ` David Marchand
2020-10-27 12:13 4% ` David Marchand
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: David Marchand @ 2020-10-19 9:41 UTC (permalink / raw)
To: dev; +Cc: thomas, Matan Azrad, Shahaf Shuler, Viacheslav Ovsiienko
The glue libraries are tightly bound to the mlx drivers of a dpdk version
and are packaged with them.
Keeping a separate ABI version prevents us from installing two versions of
dpdk.
Maintaining this separate version just adds confusion.
Align the glue library ABI version to the global ABI version.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
drivers/common/mlx5/linux/meson.build | 2 +-
drivers/common/mlx5/linux/mlx5_glue.h | 1 -
drivers/net/mlx4/meson.build | 2 +-
drivers/net/mlx4/mlx4_glue.h | 1 -
4 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/common/mlx5/linux/meson.build b/drivers/common/mlx5/linux/meson.build
index 9ef8e181d7..483df0e181 100644
--- a/drivers/common/mlx5/linux/meson.build
+++ b/drivers/common/mlx5/linux/meson.build
@@ -6,7 +6,7 @@ includes += include_directories('.')
static_ibverbs = (get_option('ibverbs_link') == 'static')
dlopen_ibverbs = (get_option('ibverbs_link') == 'dlopen')
LIB_GLUE_BASE = 'librte_pmd_mlx5_glue.so'
-LIB_GLUE_VERSION = '20.02.0'
+LIB_GLUE_VERSION = abi_version
LIB_GLUE = LIB_GLUE_BASE + '.' + LIB_GLUE_VERSION
if dlopen_ibverbs
dpdk_conf.set('RTE_IBVERBS_LINK_DLOPEN', 1)
diff --git a/drivers/common/mlx5/linux/mlx5_glue.h b/drivers/common/mlx5/linux/mlx5_glue.h
index 42b2f61523..ace36c6b07 100644
--- a/drivers/common/mlx5/linux/mlx5_glue.h
+++ b/drivers/common/mlx5/linux/mlx5_glue.h
@@ -131,7 +131,6 @@ struct mlx5dv_var { uint32_t page_id; uint32_t length; off_t mmap_off;
#define IBV_ACCESS_RELAXED_ORDERING 0
#endif
-/* LIB_GLUE_VERSION must be updated every time this structure is modified. */
struct mlx5_glue {
const char *version;
int (*fork_init)(void);
diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
index 5a25e11a7b..395776a495 100644
--- a/drivers/net/mlx4/meson.build
+++ b/drivers/net/mlx4/meson.build
@@ -11,7 +11,7 @@ endif
static_ibverbs = (get_option('ibverbs_link') == 'static')
dlopen_ibverbs = (get_option('ibverbs_link') == 'dlopen')
LIB_GLUE_BASE = 'librte_pmd_mlx4_glue.so'
-LIB_GLUE_VERSION = '18.02.0'
+LIB_GLUE_VERSION = abi_version
LIB_GLUE = LIB_GLUE_BASE + '.' + LIB_GLUE_VERSION
if dlopen_ibverbs
dpdk_conf.set('RTE_IBVERBS_LINK_DLOPEN', 1)
diff --git a/drivers/net/mlx4/mlx4_glue.h b/drivers/net/mlx4/mlx4_glue.h
index 5d9e985495..96d5cb16b4 100644
--- a/drivers/net/mlx4/mlx4_glue.h
+++ b/drivers/net/mlx4/mlx4_glue.h
@@ -23,7 +23,6 @@
#define MLX4_GLUE_VERSION ""
#endif
-/* LIB_GLUE_VERSION must be updated every time this structure is modified. */
struct mlx4_glue {
const char *version;
int (*fork_init)(void);
--
2.23.0
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int
2020-10-16 17:13 0% ` Andrew Rybchenko
@ 2020-10-19 9:37 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-19 9:37 UTC (permalink / raw)
To: Andrew Rybchenko, Andrew Rybchenko, Neil Horman, Thomas Monjalon,
Ferruh Yigit
Cc: dev, Ivan Ilchenko
On 16/10/2020 18:13, Andrew Rybchenko wrote:
> On 10/16/20 2:20 PM, Kinsella, Ray wrote:
>> On 15/10/2020 14:30, Andrew Rybchenko wrote:
>>> From: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>>>
>>> Change rte_eth_dev_stop() return value from void to int
>>> and return negative errno values in case of error conditions.
>>> Also update the usage of the function in ethdev according to
>>> the new return type.
>>>
>>> Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>>> ---
>>> doc/guides/rel_notes/deprecation.rst | 1 -
>>> doc/guides/rel_notes/release_20_11.rst | 3 +++
>>> lib/librte_ethdev/rte_ethdev.c | 27 +++++++++++++++++++-------
>>> lib/librte_ethdev/rte_ethdev.h | 5 ++++-
>>> 4 files changed, 27 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>>> index d1f5ed39db..2e04e24374 100644
>>> --- a/doc/guides/rel_notes/deprecation.rst
>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>> @@ -127,7 +127,6 @@ Deprecation Notices
>>> negative errno values to indicate various error conditions (e.g.
>>> invalid port ID, unsupported operation, failed operation):
>>>
>>> - - ``rte_eth_dev_stop``
>>> - ``rte_eth_dev_close``
>>>
>>> * ethdev: New offload flags ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11.
>>> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
>>> index f8686a50db..c8c30937fa 100644
>>> --- a/doc/guides/rel_notes/release_20_11.rst
>>> +++ b/doc/guides/rel_notes/release_20_11.rst
>>> @@ -355,6 +355,9 @@ API Changes
>>> * vhost: Add a new function ``rte_vhost_crypto_driver_start`` to be called
>>> instead of ``rte_vhost_driver_start`` by crypto applications.
>>>
>>> +* ethdev: changed ``rte_eth_dev_stop`` return value from ``void`` to
>>> + ``int`` to provide a way to report various error conditions.
>>> +
>>>
>>> ABI Changes
>>> -----------
>>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
>>> index d9b82df073..b8cf04ef4d 100644
>>> --- a/lib/librte_ethdev/rte_ethdev.c
>>> +++ b/lib/librte_ethdev/rte_ethdev.c
>>> @@ -1661,7 +1661,7 @@ rte_eth_dev_start(uint16_t port_id)
>>> struct rte_eth_dev *dev;
>>> struct rte_eth_dev_info dev_info;
>>> int diag;
>>> - int ret;
>>> + int ret, ret_stop;
>>>
>>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
>>>
>>> @@ -1695,7 +1695,13 @@ rte_eth_dev_start(uint16_t port_id)
>>> RTE_ETHDEV_LOG(ERR,
>>> "Error during restoring configuration for device (port %u): %s\n",
>>> port_id, rte_strerror(-ret));
>>> - rte_eth_dev_stop(port_id);
>>> + ret_stop = rte_eth_dev_stop(port_id);
>>> + if (ret_stop != 0) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Failed to stop device (port %u): %s\n",
>>> + port_id, rte_strerror(-ret_stop));
>>> + }
>>> +
>>> return ret;
>>> }
>>>
>>> @@ -1708,26 +1714,28 @@ rte_eth_dev_start(uint16_t port_id)
>>> return 0;
>>> }
>>>
>>> -void
>>> +int
>>> rte_eth_dev_stop(uint16_t port_id)
>>> {
>>> struct rte_eth_dev *dev;
>>>
>>> - RTE_ETH_VALID_PORTID_OR_RET(port_id);
>>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>> dev = &rte_eth_devices[port_id];
>>>
>>> - RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_stop);
>>> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_stop, -ENOTSUP);
>>>
>>> if (dev->data->dev_started == 0) {
>>> RTE_ETHDEV_LOG(INFO,
>>> "Device with port_id=%"PRIu16" already stopped\n",
>>> port_id);
>>> - return;
>>> + return 0;
>>> }
>>>
>>> dev->data->dev_started = 0;
>>> (*dev->dev_ops->dev_stop)(dev);
>>> rte_ethdev_trace_stop(port_id);
>>> +
>>> + return 0;
>>> }
>>>
>>> int
>>> @@ -1783,7 +1791,12 @@ rte_eth_dev_reset(uint16_t port_id)
>>>
>>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_reset, -ENOTSUP);
>>>
>>> - rte_eth_dev_stop(port_id);
>>> + ret = rte_eth_dev_stop(port_id);
>>> + if (ret != 0) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Failed to stop device (port %u) before reset: %s - ignore\n",
>>> + port_id, rte_strerror(-ret));
>> ABI change is 100%,
>> Just question the logic of continuing here to do a reset, if you failed to stop the device.
>
> In the case of reset I'm sure that we should ignore stop failure here.
> Typically reset is required to recover from bad state etc and stop
> failure in such condition could definitely happen.
Ok - thanks for that.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 00/22] Add DLB PMD
@ 2020-10-17 19:03 3% ` Timothy McDaniel
2020-10-23 18:32 3% ` [dpdk-dev] [PATCH v6 00/23] " Timothy McDaniel
1 sibling, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-17 19:03 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, jerinj
The following patch series adds support for a new eventdev PMD. The DLB
PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware.
The DLB is a PCIe device that provides load-balanced, prioritized
scheduling of core-to-core communication. The device consists of
queues and arbiters that connect producer and consumer cores, and
implements load-balanced queueing features including:
- Lock-free multi-producer/multi-consumer operation.
- Multiple priority levels for varying traffic types.
- 'Direct' traffic (i.e. multi-producer/single-consumer)
- Simple unordered load-balanced distribution.
- Atomic lock-free load balancing across multiple consumers.
- Queue element reordering feature allowing ordered load-balanced
distribution.
The DLB hardware supports both load balanced and directed ports and
queues. Unlike other eventdev devices already in the repo, not all
DLB ports and queues are equally capable. In particular, directed
ports are limited to a single link, and must be connected to a directed
queue.
Additionally, even though LDB ports may link multiple queues, the
number of queues that may be linked is limited by hardware. Another
difference is that DLB does not have a straightforward way of carrying
the flow_id in the queue elements (QE) that the hardware operates on.
While reviewing the code, please be aware that this PMD has full
control over the DLB hardware. Intel will be extending the DLB PMD
in the future (not as part of this first series) with a mode that we
refer to as the bifurcated PMD. The bifurcated PMD communicates with a
kernel driver to configure the device, ports, and queues, and memory
maps device MMIO so datapath operations occur purely in user-space.
The framework to support both the PF PMD and bifurcated PMD exists in
this patchset, and is why the iface.[ch] layer is present.
Major changes in v5 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- implement changes requested in code reviews by Gage Eads and Mike Chen
- fix a memzone leak
- convert to use eal rte-cpuflags patch from Liang Ma
Major changes in v4 after dpdk reviews and additional internal reviews
by colleagues at Intel:
================
- Remove make infrastructure
- shared code (pf/base) is now added incrementally
- flexible interface (iface.[ch]) is now added incrementally
- removed calls to rte_panic
- do not call pthread_create directly
- remove unused internal API, os_time
- convert rte_atomic to __atomic builtins
- broke out eventdev ABI changes, test/api changes, and new internal PCI
named probe API
- relocated enqueue logic to enqueue patch
Major Changes in V3:
================
- Fixed a memory corruption issue due to not allocating enough CQ
memory for depths < 8. Hardware requires minimum allocation to be
at least 8 entries.
- Address review comments from Gage and Mattias.
- Remove versioning
- minor formatting changes
Major changes in V2:
================
- Correct ABI break that was present in V1.
- Address some of the review comments received from Mattias.
I will address the remaining items identified by Mattias in the next
patch delivery.
- General code cleanup based on internal code reviews
Depends-on: patch-79539 ("eal: add new x86 cpuid support for WAITPKG")
Timothy McDaniel (22):
event/dlb: add documentation and meson infrastructure
event/dlb: add dynamic logging
event/dlb: add private data structures and constants
event/dlb: add definitions shared with LKM or shared code
event/dlb: add inline functions
event/dlb: add probe
event/dlb: add xstats
event/dlb: add infos get and configure
event/dlb: add queue and port default conf
event/dlb: add queue setup
event/dlb: add port setup
event/dlb: add port link
event/dlb: add port unlink and port unlinks in progress
event/dlb: add eventdev start
event/dlb: add enqueue and its burst variants
event/dlb: add dequeue and its burst variants
event/dlb: add eventdev stop and close
event/dlb: add PMD's token pop public interface
event/dlb: add PMD self-tests
event/dlb: add queue and port release
event/dlb: add timeout ticks entry point
doc: Add new DLB eventdev driver to relnotes
MAINTAINERS | 5 +
app/test/test_eventdev.c | 7 +
config/rte_config.h | 8 +-
doc/api/doxy-api-index.md | 1 +
doc/guides/eventdevs/dlb.rst | 341 ++
doc/guides/eventdevs/index.rst | 1 +
doc/guides/rel_notes/release_20_11.rst | 5 +
drivers/event/dlb/dlb.c | 4129 ++++++++++++++
drivers/event/dlb/dlb_iface.c | 79 +
drivers/event/dlb/dlb_iface.h | 82 +
drivers/event/dlb/dlb_inline_fns.h | 79 +
drivers/event/dlb/dlb_log.h | 25 +
drivers/event/dlb/dlb_priv.h | 513 ++
drivers/event/dlb/dlb_selftest.c | 1551 +++++
drivers/event/dlb/dlb_user.h | 814 +++
drivers/event/dlb/dlb_xstats.c | 1222 ++++
drivers/event/dlb/meson.build | 15 +
drivers/event/dlb/pf/base/dlb_hw_types.h | 334 ++
drivers/event/dlb/pf/base/dlb_osdep.h | 326 ++
drivers/event/dlb/pf/base/dlb_osdep_bitmap.h | 441 ++
drivers/event/dlb/pf/base/dlb_osdep_list.h | 131 +
drivers/event/dlb/pf/base/dlb_osdep_types.h | 31 +
drivers/event/dlb/pf/base/dlb_regs.h | 2368 ++++++++
drivers/event/dlb/pf/base/dlb_resource.c | 6902 +++++++++++++++++++++++
drivers/event/dlb/pf/base/dlb_resource.h | 876 +++
drivers/event/dlb/pf/dlb_main.c | 591 ++
drivers/event/dlb/pf/dlb_main.h | 52 +
drivers/event/dlb/pf/dlb_pf.c | 746 +++
drivers/event/dlb/rte_pmd_dlb.c | 38 +
drivers/event/dlb/rte_pmd_dlb.h | 72 +
drivers/event/dlb/rte_pmd_dlb_event_version.map | 9 +
drivers/event/meson.build | 4 +
32 files changed, 21797 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/eventdevs/dlb.rst
create mode 100644 drivers/event/dlb/dlb.c
create mode 100644 drivers/event/dlb/dlb_iface.c
create mode 100644 drivers/event/dlb/dlb_iface.h
create mode 100644 drivers/event/dlb/dlb_inline_fns.h
create mode 100644 drivers/event/dlb/dlb_log.h
create mode 100644 drivers/event/dlb/dlb_priv.h
create mode 100644 drivers/event/dlb/dlb_selftest.c
create mode 100644 drivers/event/dlb/dlb_user.h
create mode 100644 drivers/event/dlb/dlb_xstats.c
create mode 100644 drivers/event/dlb/meson.build
create mode 100644 drivers/event/dlb/pf/base/dlb_hw_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_bitmap.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_list.h
create mode 100644 drivers/event/dlb/pf/base/dlb_osdep_types.h
create mode 100644 drivers/event/dlb/pf/base/dlb_regs.h
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.c
create mode 100644 drivers/event/dlb/pf/base/dlb_resource.h
create mode 100644 drivers/event/dlb/pf/dlb_main.c
create mode 100644 drivers/event/dlb/pf/dlb_main.h
create mode 100644 drivers/event/dlb/pf/dlb_pf.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.c
create mode 100644 drivers/event/dlb/rte_pmd_dlb.h
create mode 100644 drivers/event/dlb/rte_pmd_dlb_event_version.map
--
2.6.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int
2020-10-16 11:20 3% ` Kinsella, Ray
@ 2020-10-16 17:13 0% ` Andrew Rybchenko
2020-10-19 9:37 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2020-10-16 17:13 UTC (permalink / raw)
To: Kinsella, Ray, Andrew Rybchenko, Neil Horman, Thomas Monjalon,
Ferruh Yigit
Cc: dev, Ivan Ilchenko
On 10/16/20 2:20 PM, Kinsella, Ray wrote:
>
> On 15/10/2020 14:30, Andrew Rybchenko wrote:
>> From: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>>
>> Change rte_eth_dev_stop() return value from void to int
>> and return negative errno values in case of error conditions.
>> Also update the usage of the function in ethdev according to
>> the new return type.
>>
>> Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>> ---
>> doc/guides/rel_notes/deprecation.rst | 1 -
>> doc/guides/rel_notes/release_20_11.rst | 3 +++
>> lib/librte_ethdev/rte_ethdev.c | 27 +++++++++++++++++++-------
>> lib/librte_ethdev/rte_ethdev.h | 5 ++++-
>> 4 files changed, 27 insertions(+), 9 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>> index d1f5ed39db..2e04e24374 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -127,7 +127,6 @@ Deprecation Notices
>> negative errno values to indicate various error conditions (e.g.
>> invalid port ID, unsupported operation, failed operation):
>>
>> - - ``rte_eth_dev_stop``
>> - ``rte_eth_dev_close``
>>
>> * ethdev: New offload flags ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11.
>> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
>> index f8686a50db..c8c30937fa 100644
>> --- a/doc/guides/rel_notes/release_20_11.rst
>> +++ b/doc/guides/rel_notes/release_20_11.rst
>> @@ -355,6 +355,9 @@ API Changes
>> * vhost: Add a new function ``rte_vhost_crypto_driver_start`` to be called
>> instead of ``rte_vhost_driver_start`` by crypto applications.
>>
>> +* ethdev: changed ``rte_eth_dev_stop`` return value from ``void`` to
>> + ``int`` to provide a way to report various error conditions.
>> +
>>
>> ABI Changes
>> -----------
>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
>> index d9b82df073..b8cf04ef4d 100644
>> --- a/lib/librte_ethdev/rte_ethdev.c
>> +++ b/lib/librte_ethdev/rte_ethdev.c
>> @@ -1661,7 +1661,7 @@ rte_eth_dev_start(uint16_t port_id)
>> struct rte_eth_dev *dev;
>> struct rte_eth_dev_info dev_info;
>> int diag;
>> - int ret;
>> + int ret, ret_stop;
>>
>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
>>
>> @@ -1695,7 +1695,13 @@ rte_eth_dev_start(uint16_t port_id)
>> RTE_ETHDEV_LOG(ERR,
>> "Error during restoring configuration for device (port %u): %s\n",
>> port_id, rte_strerror(-ret));
>> - rte_eth_dev_stop(port_id);
>> + ret_stop = rte_eth_dev_stop(port_id);
>> + if (ret_stop != 0) {
>> + RTE_ETHDEV_LOG(ERR,
>> + "Failed to stop device (port %u): %s\n",
>> + port_id, rte_strerror(-ret_stop));
>> + }
>> +
>> return ret;
>> }
>>
>> @@ -1708,26 +1714,28 @@ rte_eth_dev_start(uint16_t port_id)
>> return 0;
>> }
>>
>> -void
>> +int
>> rte_eth_dev_stop(uint16_t port_id)
>> {
>> struct rte_eth_dev *dev;
>>
>> - RTE_ETH_VALID_PORTID_OR_RET(port_id);
>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> dev = &rte_eth_devices[port_id];
>>
>> - RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_stop);
>> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_stop, -ENOTSUP);
>>
>> if (dev->data->dev_started == 0) {
>> RTE_ETHDEV_LOG(INFO,
>> "Device with port_id=%"PRIu16" already stopped\n",
>> port_id);
>> - return;
>> + return 0;
>> }
>>
>> dev->data->dev_started = 0;
>> (*dev->dev_ops->dev_stop)(dev);
>> rte_ethdev_trace_stop(port_id);
>> +
>> + return 0;
>> }
>>
>> int
>> @@ -1783,7 +1791,12 @@ rte_eth_dev_reset(uint16_t port_id)
>>
>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_reset, -ENOTSUP);
>>
>> - rte_eth_dev_stop(port_id);
>> + ret = rte_eth_dev_stop(port_id);
>> + if (ret != 0) {
>> + RTE_ETHDEV_LOG(ERR,
>> + "Failed to stop device (port %u) before reset: %s - ignore\n",
>> + port_id, rte_strerror(-ret));
> ABI change is 100%,
> Just question the logic of continuing here to do a reset, if you failed to stop the device.
In the case of reset I'm sure that we should ignore stop failure here.
Typically reset is required to recover from bad state etc and stop
failure in such condition could definitely happen.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model
@ 2020-10-16 15:41 3% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-16 15:41 UTC (permalink / raw)
To: Gregory Etelson, dev
Cc: matan, rasland, elibr, ozsh, asafp, Eli Britstein, Ori Kam,
Viacheslav Ovsiienko, Neil Horman, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko
On 16/10/2020 13:51, Gregory Etelson wrote:
> From: Eli Britstein <elibr@mellanox.com>
>
> rte_flow API provides the building blocks for vendor-agnostic flow
> classification offloads. The rte_flow "patterns" and "actions"
> primitives are fine-grained, thus enabling DPDK applications the
> flexibility to offload network stacks and complex pipelines.
> Applications wishing to offload tunneled traffic are required to use
> the rte_flow primitives, such as group, meta, mark, tag, and others to
> model their high-level objects. The hardware model design for
> high-level software objects is not trivial. Furthermore, an optimal
> design is often vendor-specific.
>
> When hardware offloads tunneled traffic in multi-group logic,
> partially offloaded packets may arrive to the application after they
> were modified in hardware. In this case, the application may need to
> restore the original packet headers. Consider the following sequence:
> The application decaps a packet in one group and jumps to a second
> group where it tries to match on a 5-tuple, that will miss and send
> the packet to the application. In this case, the application does not
> receive the original packet but a modified one. Also, in this case,
> the application cannot match on the outer header fields, such as VXLAN
> vni and 5-tuple.
>
> There are several possible ways to use rte_flow "patterns" and
> "actions" to resolve the issues above. For example:
> 1 Mapping headers to a hardware registers using the
> rte_flow_action_mark/rte_flow_action_tag/rte_flow_set_meta objects.
> 2 Apply the decap only at the last offload stage after all the
> "patterns" were matched and the packet will be fully offloaded.
> Every approach has its pros and cons and is highly dependent on the
> hardware vendor. For example, some hardware may have a limited number
> of registers while other hardware could not support inner actions and
> must decap before accessing inner headers.
>
> The tunnel offload model resolves these issues. The model goals are:
> 1 Provide a unified application API to offload tunneled traffic that
> is capable to match on outer headers after decap.
> 2 Allow the application to restore the outer header of partially
> offloaded packets.
>
> The tunnel offload model does not introduce new elements to the
> existing RTE flow model and is implemented as a set of helper
> functions.
>
> For the application to work with the tunnel offload API it
> has to adjust flow rules in multi-table tunnel offload in the
> following way:
> 1 Remove explicit call to decap action and replace it with PMD actions
> obtained from rte_flow_tunnel_decap_and_set() helper.
> 2 Add PMD items obtained from rte_flow_tunnel_match() helper to all
> other rules in the tunnel offload sequence.
>
> VXLAN Code example:
>
> Assume application needs to do inner NAT on the VXLAN packet.
> The first rule in group 0:
>
> flow create <port id> ingress group 0
> pattern eth / ipv4 / udp dst is 4789 / vxlan / end
> actions {pmd actions} / jump group 3 / end
>
> The first VXLAN packet that arrives matches the rule in group 0 and
> jumps to group 3. In group 3 the packet will miss since there is no
> flow to match and will be sent to the application. Application will
> call rte_flow_get_restore_info() to get the packet outer header.
>
> Application will insert a new rule in group 3 to match outer and inner
> headers:
>
> flow create <port id> ingress group 3
> pattern {pmd items} / eth / ipv4 dst is 172.10.10.1 /
> udp dst 4789 / vxlan vni is 10 /
> ipv4 dst is 184.1.2.3 / end
> actions set_ipv4_dst 186.1.1.1 / queue index 3 / end
>
> Resulting of the rules will be that VXLAN packet with vni=10, outer
> IPv4 dst=172.10.10.1 and inner IPv4 dst=184.1.2.3 will be received
> decapped on queue 3 with IPv4 dst=186.1.1.1
>
> Note: The packet in group 3 is considered decapped. All actions in
> that group will be done on the header that was inner before decap. The
> application may specify an outer header to be matched on. It's PMD
> responsibility to translate these items to outer metadata.
>
> API usage:
>
> /**
> * 1. Initiate RTE flow tunnel object
> */
> const struct rte_flow_tunnel tunnel = {
> .type = RTE_FLOW_ITEM_TYPE_VXLAN,
> .tun_id = 10,
> }
>
> /**
> * 2. Obtain PMD tunnel actions
> *
> * pmd_actions is an intermediate variable application uses to
> * compile actions array
> */
> struct rte_flow_action **pmd_actions;
> rte_flow_tunnel_decap_and_set(&tunnel, &pmd_actions,
> &num_pmd_actions, &error);
> /**
> * 3. offload the first rule
> * matching on VXLAN traffic and jumps to group 3
> * (implicitly decaps packet)
> */
> app_actions = jump group 3
> rule_items = app_items; /** eth / ipv4 / udp / vxlan */
> rule_actions = { pmd_actions, app_actions };
> attr.group = 0;
> flow_1 = rte_flow_create(port_id, &attr,
> rule_items, rule_actions, &error);
>
> /**
> * 4. after flow creation application does not need to keep the
> * tunnel action resources.
> */
> rte_flow_tunnel_action_release(port_id, pmd_actions,
> num_pmd_actions);
> /**
> * 5. After partially offloaded packet miss because there was no
> * matching rule handle miss on group 3
> */
> struct rte_flow_restore_info info;
> rte_flow_get_restore_info(port_id, mbuf, &info, &error);
>
> /**
> * 6. Offload NAT rule:
> */
> app_items = { eth / ipv4 dst is 172.10.10.1 / udp dst 4789 /
> vxlan vni is 10 / ipv4 dst is 184.1.2.3 }
> app_actions = { set_ipv4_dst 186.1.1.1 / queue index 3 }
>
> rte_flow_tunnel_match(&info.tunnel, &pmd_items,
> &num_pmd_items, &error);
> rule_items = {pmd_items, app_items};
> rule_actions = app_actions;
> attr.group = info.group_id;
> flow_2 = rte_flow_create(port_id, &attr,
> rule_items, rule_actions, &error);
>
> /**
> * 7. Release PMD items after rule creation
> */
> rte_flow_tunnel_item_release(port_id,
> pmd_items, num_pmd_items);
>
> References
> 1. https://mails.dpdk.org/archives/dev/2020-June/index.html
>
> Signed-off-by: Eli Britstein <elibr@mellanox.com>
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
>
> ---
> v5:
> * rebase to next-net
>
> v6:
> * update the patch comment
> * update tunnel offload section in rte_flow.rst
> ---
> doc/guides/prog_guide/rte_flow.rst | 78 +++++++++
> doc/guides/rel_notes/release_20_11.rst | 5 +
> lib/librte_ethdev/rte_ethdev_version.map | 5 +
> lib/librte_ethdev/rte_flow.c | 112 +++++++++++++
> lib/librte_ethdev/rte_flow.h | 195 +++++++++++++++++++++++
> lib/librte_ethdev/rte_flow_driver.h | 32 ++++
> 6 files changed, 427 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 7fb5ec9059..8dc048c6f4 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -3131,6 +3131,84 @@ operations include:
> - Duplication of a complete flow rule description.
> - Pattern item or action name retrieval.
>
> +Tunneled traffic offload
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +rte_flow API provides the building blocks for vendor-agnostic flow
> +classification offloads. The rte_flow "patterns" and "actions"
> +primitives are fine-grained, thus enabling DPDK applications the
> +flexibility to offload network stacks and complex pipelines.
> +Applications wishing to offload tunneled traffic are required to use
> +the rte_flow primitives, such as group, meta, mark, tag, and others to
> +model their high-level objects. The hardware model design for
> +high-level software objects is not trivial. Furthermore, an optimal
> +design is often vendor-specific.
> +
> +When hardware offloads tunneled traffic in multi-group logic,
> +partially offloaded packets may arrive to the application after they
> +were modified in hardware. In this case, the application may need to
> +restore the original packet headers. Consider the following sequence:
> +The application decaps a packet in one group and jumps to a second
> +group where it tries to match on a 5-tuple, that will miss and send
> +the packet to the application. In this case, the application does not
> +receive the original packet but a modified one. Also, in this case,
> +the application cannot match on the outer header fields, such as VXLAN
> +vni and 5-tuple.
> +
> +There are several possible ways to use rte_flow "patterns" and
> +"actions" to resolve the issues above. For example:
> +
> +1 Mapping headers to a hardware registers using the
> +rte_flow_action_mark/rte_flow_action_tag/rte_flow_set_meta objects.
> +
> +2 Apply the decap only at the last offload stage after all the
> +"patterns" were matched and the packet will be fully offloaded.
> +
> +Every approach has its pros and cons and is highly dependent on the
> +hardware vendor. For example, some hardware may have a limited number
> +of registers while other hardware could not support inner actions and
> +must decap before accessing inner headers.
> +
> +The tunnel offload model resolves these issues. The model goals are:
> +
> +1 Provide a unified application API to offload tunneled traffic that
> +is capable to match on outer headers after decap.
> +
> +2 Allow the application to restore the outer header of partially
> +offloaded packets.
> +
> +The tunnel offload model does not introduce new elements to the
> +existing RTE flow model and is implemented as a set of helper
> +functions.
> +
> +For the application to work with the tunnel offload API it
> +has to adjust flow rules in multi-table tunnel offload in the
> +following way:
> +
> +1 Remove explicit call to decap action and replace it with PMD actions
> +obtained from rte_flow_tunnel_decap_and_set() helper.
> +
> +2 Add PMD items obtained from rte_flow_tunnel_match() helper to all
> +other rules in the tunnel offload sequence.
> +
> +The model requirements:
> +
> +Software application must initialize
> +rte_tunnel object with tunnel parameters before calling
> +rte_flow_tunnel_decap_set() & rte_flow_tunnel_match().
> +
> +PMD actions array obtained in rte_flow_tunnel_decap_set() must be
> +released by application with rte_flow_action_release() call.
> +
> +PMD items array obtained with rte_flow_tunnel_match() must be released
Should be rte_flow_tunnel_item_release ?
> +by application with rte_flow_item_release() call. Application can
> +release PMD items and actions after rule was created. However, if the
> +application needs to create additional rule for the same tunnel it
> +will need to obtain PMD items again.
> +
> +Application cannot destroy rte_tunnel object before it releases all
> +PMD actions & PMD items referencing that tunnel.
> +
> Caveats
> -------
>
> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
> index 9155b468d6..f125ce79dd 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -121,6 +121,11 @@ New Features
> * Flow rule verification was updated to accept private PMD
> items and actions.
>
> +* **Added generic API to offload tunneled traffic and restore missed packet.**
> +
> + * Added a new hardware independent helper API to RTE flow library that
> + offloads tunneled traffic and restores missed packets.
> +
> * **Updated Cisco enic driver.**
>
> * Added support for VF representors with single-queue Tx/Rx and flow API
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index f64c379ac2..8ddda2547f 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -239,6 +239,11 @@ EXPERIMENTAL {
> rte_flow_shared_action_destroy;
> rte_flow_shared_action_query;
> rte_flow_shared_action_update;
> + rte_flow_tunnel_decap_set;
> + rte_flow_tunnel_match;
> + rte_flow_get_restore_info;
> + rte_flow_tunnel_action_decap_release;
> + rte_flow_tunnel_item_release;
> };
>
> INTERNAL {
> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
> index b74ea5593a..380c5cae2c 100644
> --- a/lib/librte_ethdev/rte_flow.c
> +++ b/lib/librte_ethdev/rte_flow.c
> @@ -1143,3 +1143,115 @@ rte_flow_shared_action_query(uint16_t port_id,
> data, error);
> return flow_err(port_id, ret, error);
> }
> +
> +int
> +rte_flow_tunnel_decap_set(uint16_t port_id,
> + struct rte_flow_tunnel *tunnel,
> + struct rte_flow_action **actions,
> + uint32_t *num_of_actions,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->tunnel_decap_set)) {
> + return flow_err(port_id,
> + ops->tunnel_decap_set(dev, tunnel, actions,
> + num_of_actions, error),
> + error);
> + }
> + return rte_flow_error_set(error, ENOTSUP,
> + RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> +}
> +
> +int
> +rte_flow_tunnel_match(uint16_t port_id,
> + struct rte_flow_tunnel *tunnel,
> + struct rte_flow_item **items,
> + uint32_t *num_of_items,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->tunnel_match)) {
> + return flow_err(port_id,
> + ops->tunnel_match(dev, tunnel, items,
> + num_of_items, error),
> + error);
> + }
> + return rte_flow_error_set(error, ENOTSUP,
> + RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> +}
> +
> +int
> +rte_flow_get_restore_info(uint16_t port_id,
> + struct rte_mbuf *m,
> + struct rte_flow_restore_info *restore_info,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->get_restore_info)) {
> + return flow_err(port_id,
> + ops->get_restore_info(dev, m, restore_info,
> + error),
> + error);
> + }
> + return rte_flow_error_set(error, ENOTSUP,
> + RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> +}
> +
> +int
> +rte_flow_tunnel_action_decap_release(uint16_t port_id,
> + struct rte_flow_action *actions,
> + uint32_t num_of_actions,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->action_release)) {
> + return flow_err(port_id,
> + ops->action_release(dev, actions,
> + num_of_actions, error),
> + error);
> + }
> + return rte_flow_error_set(error, ENOTSUP,
> + RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> +}
> +
> +int
> +rte_flow_tunnel_item_release(uint16_t port_id,
> + struct rte_flow_item *items,
> + uint32_t num_of_items,
> + struct rte_flow_error *error)
> +{
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> +
> + if (unlikely(!ops))
> + return -rte_errno;
> + if (likely(!!ops->item_release)) {
> + return flow_err(port_id,
> + ops->item_release(dev, items,
> + num_of_items, error),
> + error);
> + }
> + return rte_flow_error_set(error, ENOTSUP,
> + RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, rte_strerror(ENOTSUP));
> +}
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 48395284b5..a8eac4deb8 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -3620,6 +3620,201 @@ rte_flow_shared_action_query(uint16_t port_id,
> void *data,
> struct rte_flow_error *error);
>
> +/* Tunnel has a type and the key information. */
> +struct rte_flow_tunnel {
> + /**
> + * Tunnel type, for example RTE_FLOW_ITEM_TYPE_VXLAN,
> + * RTE_FLOW_ITEM_TYPE_NVGRE etc.
> + */
> + enum rte_flow_item_type type;
> + uint64_t tun_id; /**< Tunnel identification. */
> +
> + RTE_STD_C11
> + union {
> + struct {
> + rte_be32_t src_addr; /**< IPv4 source address. */
> + rte_be32_t dst_addr; /**< IPv4 destination address. */
> + } ipv4;
> + struct {
> + uint8_t src_addr[16]; /**< IPv6 source address. */
> + uint8_t dst_addr[16]; /**< IPv6 destination address. */
> + } ipv6;
> + };
> + rte_be16_t tp_src; /**< Tunnel port source. */
> + rte_be16_t tp_dst; /**< Tunnel port destination. */
> + uint16_t tun_flags; /**< Tunnel flags. */
> +
> + bool is_ipv6; /**< True for valid IPv6 fields. Otherwise IPv4. */
> +
> + /**
> + * the following members are required to restore packet
> + * after miss
> + */
> + uint8_t tos; /**< TOS for IPv4, TC for IPv6. */
> + uint8_t ttl; /**< TTL for IPv4, HL for IPv6. */
> + uint32_t label; /**< Flow Label for IPv6. */
> +};
> +
> +/**
> + * Indicate that the packet has a tunnel.
> + */
> +#define RTE_FLOW_RESTORE_INFO_TUNNEL (1ULL << 0)
> +
> +/**
> + * Indicate that the packet has a non decapsulated tunnel header.
> + */
> +#define RTE_FLOW_RESTORE_INFO_ENCAPSULATED (1ULL << 1)
> +
> +/**
> + * Indicate that the packet has a group_id.
> + */
> +#define RTE_FLOW_RESTORE_INFO_GROUP_ID (1ULL << 2)
> +
> +/**
> + * Restore information structure to communicate the current packet processing
> + * state when some of the processing pipeline is done in hardware and should
> + * continue in software.
> + */
> +struct rte_flow_restore_info {
> + /**
> + * Bitwise flags (RTE_FLOW_RESTORE_INFO_*) to indicate validation of
> + * other fields in struct rte_flow_restore_info.
> + */
> + uint64_t flags;
> + uint32_t group_id; /**< Group ID where packed missed */
> + struct rte_flow_tunnel tunnel; /**< Tunnel information. */
> +};
> +
> +/**
> + * Allocate an array of actions to be used in rte_flow_create, to implement
> + * tunnel-decap-set for the given tunnel.
> + * Sample usage:
> + * actions vxlan_decap / tunnel-decap-set(tunnel properties) /
> + * jump group 0 / end
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] tunnel
> + * Tunnel properties.
> + * @param[out] actions
> + * Array of actions to be allocated by the PMD. This array should be
> + * concatenated with the actions array provided to rte_flow_create.
> + * @param[out] num_of_actions
> + * Number of actions allocated.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL. PMDs initialize this
> + * structure in case of error only.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_tunnel_decap_set(uint16_t port_id,
> + struct rte_flow_tunnel *tunnel,
> + struct rte_flow_action **actions,
> + uint32_t *num_of_actions,
> + struct rte_flow_error *error);
> +
> +/**
> + * Allocate an array of items to be used in rte_flow_create, to implement
> + * tunnel-match for the given tunnel.
> + * Sample usage:
> + * pattern tunnel-match(tunnel properties) / outer-header-matches /
> + * inner-header-matches / end
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] tunnel
> + * Tunnel properties.
> + * @param[out] items
> + * Array of items to be allocated by the PMD. This array should be
> + * concatenated with the items array provided to rte_flow_create.
> + * @param[out] num_of_items
> + * Number of items allocated.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL. PMDs initialize this
> + * structure in case of error only.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_tunnel_match(uint16_t port_id,
> + struct rte_flow_tunnel *tunnel,
> + struct rte_flow_item **items,
> + uint32_t *num_of_items,
> + struct rte_flow_error *error);
> +
> +/**
> + * Populate the current packet processing state, if exists, for the given mbuf.
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] m
> + * Mbuf struct.
> + * @param[out] info
> + * Restore information. Upon success contains the HW state.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL. PMDs initialize this
> + * structure in case of error only.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_get_restore_info(uint16_t port_id,
> + struct rte_mbuf *m,
> + struct rte_flow_restore_info *info,
> + struct rte_flow_error *error);
> +
> +/**
> + * Release the action array as allocated by rte_flow_tunnel_decap_set.
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] actions
> + * Array of actions to be released.
> + * @param[in] num_of_actions
> + * Number of elements in actions array.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL. PMDs initialize this
> + * structure in case of error only.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_tunnel_action_decap_release(uint16_t port_id,
> + struct rte_flow_action *actions,
> + uint32_t num_of_actions,
> + struct rte_flow_error *error);
> +
> +/**
> + * Release the item array as allocated by rte_flow_tunnel_match.
> + *
> + * @param port_id
> + * Port identifier of Ethernet device.
> + * @param[in] items
> + * Array of items to be released.
> + * @param[in] num_of_items
> + * Number of elements in item array.
> + * @param[out] error
> + * Perform verbose error reporting if not NULL. PMDs initialize this
> + * structure in case of error only.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +__rte_experimental
> +int
> +rte_flow_tunnel_item_release(uint16_t port_id,
> + struct rte_flow_item *items,
> + uint32_t num_of_items,
> + struct rte_flow_error *error);
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_ethdev/rte_flow_driver.h b/lib/librte_ethdev/rte_flow_driver.h
> index 58f56b0262..bd5ffc0bb1 100644
> --- a/lib/librte_ethdev/rte_flow_driver.h
> +++ b/lib/librte_ethdev/rte_flow_driver.h
> @@ -131,6 +131,38 @@ struct rte_flow_ops {
> const struct rte_flow_shared_action *shared_action,
> void *data,
> struct rte_flow_error *error);
> + /** See rte_flow_tunnel_decap_set() */
> + int (*tunnel_decap_set)
> + (struct rte_eth_dev *dev,
> + struct rte_flow_tunnel *tunnel,
> + struct rte_flow_action **pmd_actions,
> + uint32_t *num_of_actions,
> + struct rte_flow_error *err);
> + /** See rte_flow_tunnel_match() */
> + int (*tunnel_match)
> + (struct rte_eth_dev *dev,
> + struct rte_flow_tunnel *tunnel,
> + struct rte_flow_item **pmd_items,
> + uint32_t *num_of_items,
> + struct rte_flow_error *err);
Should be rte_flow_get_restore_info
> + /** See rte_flow_get_rte_flow_restore_info() */> + int (*get_restore_info)
> + (struct rte_eth_dev *dev,
> + struct rte_mbuf *m,
> + struct rte_flow_restore_info *info,
> + struct rte_flow_error *err);
Should be rte_flow_tunnel_action_decap_release
> + /** See rte_flow_action_tunnel_decap_release() */
> + int (*action_release)
> + (struct rte_eth_dev *dev,
> + struct rte_flow_action *pmd_actions,
> + uint32_t num_of_actions,
> + struct rte_flow_error *err);
Should rte_flow_tunnel_item_release?
> + /** See rte_flow_item_release() */
> + int (*item_release)
> + (struct rte_eth_dev *dev,
> + struct rte_flow_item *pmd_items,
> + uint32_t num_of_items,
> + struct rte_flow_error *err);
> };
>
> /**
>
ABI Changes Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v9 1/6] ethdev: introduce Rx buffer split
2020-10-16 11:21 4% ` Ferruh Yigit
@ 2020-10-16 13:08 0% ` Slava Ovsiienko
0 siblings, 0 replies; 200+ results
From: Slava Ovsiienko @ 2020-10-16 13:08 UTC (permalink / raw)
To: Ferruh Yigit, dev
Cc: NBU-Contact-Thomas Monjalon, stephen, olivier.matz, jerinjacobk,
maxime.coquelin, david.marchand, arybchenko
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, October 16, 2020 14:21
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; dev@dpdk.org
> Cc: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> stephen@networkplumber.org; olivier.matz@6wind.com;
> jerinjacobk@gmail.com; maxime.coquelin@redhat.com;
> david.marchand@redhat.com; arybchenko@solarflare.com
> Subject: Re: [PATCH v9 1/6] ethdev: introduce Rx buffer split
>
> On 10/16/2020 11:22 AM, Viacheslav Ovsiienko wrote:
> > The DPDK datapath in the transmit direction is very flexible.
> > An application can build the multi-segment packet and manages almost
> > all data aspects - the memory pools where segments are allocated from,
> > the segment lengths, the memory attributes like external buffers,
> > registered for DMA, etc.
> >
[snip]
> > +
> > +* **[uses] rte_eth_rxconf,rte_eth_rxmode**:
> ``offloads:RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT``.
> > +* **[uses] rte_eth_rxconf**: ``rx_conf.rx_seg, rx_conf.rx_nseg``.
> > +* **[implements] datapath**: ``Buffer Split functionality``.
> > +* **[provides] rte_eth_dev_info**:
> ``rx_offload_capa:RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT``.
> > +* **[provides] eth_dev_ops**: ``rxq_info_get:buffer_split``.
>
> Previously you mentioned this is because 'rxq_info_get()' can provide
> buffer_split information, but with current implementation it doesn't and there
> is no filed in the struct to report such.
>
> I suggest either add it now, while you can :) [with a techboard approval], or
> remove above documentation of it.
>
> <...>
>
Mmm, I messed up with rx_burst_mode_get(). Will fix, thanks.
> > /**
> > + * Ethernet device Rx buffer segmentation capabilities.
> > + */
> > +__rte_experimental
> > +struct rte_eth_rxseg_capa {
> > + __extension__
> > + uint32_t max_nseg:16; /**< Maximum amount of segments to split. */
> > + uint32_t multi_pools:1; /**< Supports receiving to multiple pools.*/
> > + uint32_t offset_allowed:1; /**< Supports buffer offsets. */
> > + uint32_t offset_align_log2:4; /**< Required offset alignment. */ };
>
> Now we are fiddling details, but,
>
> I am not fun of the bitfields [1], but I assumed Thomas' request was to enable
> expanding capabilities later without breaking the ABI, which makes senses and
> suits to this kind of capability struct, if this is correct why made the 'max_nseg'
> a bitfield too?
>
> Why not,
> uint16_t max_nseg;
> uint16_t multi_pools:1
> uint16_t offset_allowed:1;
> uint16_t offset_align_log2:4;
> < This still leaves 10 bits to expand without ABI break>
>
> [1]
> unles very space critical use case, otherwise they just add more code to extract
> the same value, and not as simple as a simple variable :)
It seems not to be the case, there is the listing of the rte_eth_rx_queue_check_split():
8963 4b67 440FB784 movzwl 188(%rsp),%r8d ; [SO] max_nseg is fetched as regular uint16_t
8963 24BC0000
8963 00
8964 4b70 664539C1 cmpw %r8w,%r9w
8965 4b74 0F87A402 ja .L1749
8965 0000
I would prefer to keep uint32_t - it is more generic, IMO.
With best regards, Slava
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v9 1/6] ethdev: introduce Rx buffer split
@ 2020-10-16 11:21 4% ` Ferruh Yigit
2020-10-16 13:08 0% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-10-16 11:21 UTC (permalink / raw)
To: Viacheslav Ovsiienko, dev
Cc: thomas, stephen, olivier.matz, jerinjacobk, maxime.coquelin,
david.marchand, arybchenko
On 10/16/2020 11:22 AM, Viacheslav Ovsiienko wrote:
> The DPDK datapath in the transmit direction is very flexible.
> An application can build the multi-segment packet and manages
> almost all data aspects - the memory pools where segments
> are allocated from, the segment lengths, the memory attributes
> like external buffers, registered for DMA, etc.
>
> In the receiving direction, the datapath is much less flexible,
> an application can only specify the memory pool to configure the
> receiving queue and nothing more. In order to extend receiving
> datapath capabilities it is proposed to add the way to provide
> extended information how to split the packets being received.
>
> The new offload flag RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT in device
> capabilities is introduced to present the way for PMD to report to
> application about supporting Rx packet split to configurable
> segments. Prior invoking the rte_eth_rx_queue_setup() routine
> application should check RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag.
>
> The following structure is introduced to specify the Rx packet
> segment for RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT offload:
>
> struct rte_eth_rxseg_split {
>
> struct rte_mempool *mp; /* memory pools to allocate segment from */
> uint16_t length; /* segment maximal data length,
> configures "split point" */
> uint16_t offset; /* data offset from beginning
> of mbuf data buffer */
> uint32_t reserved; /* reserved field */
> };
>
> The segment descriptions are added to the rte_eth_rxconf structure:
> rx_seg - pointer the array of segment descriptions, each element
> describes the memory pool, maximal data length, initial
> data offset from the beginning of data buffer in mbuf.
> This array allows to specify the different settings for
> each segment in individual fashion.
> rx_nseg - number of elements in the array
>
> If the extended segment descriptions is provided with these new
> fields the mp parameter of the rte_eth_rx_queue_setup must be
> specified as NULL to avoid ambiguity.
>
> There are two options to specify Rx buffer configuration:
> - mp is not NULL, rx_conf.rx_seg is NULL, rx_conf.rx_nseg is zero,
> it is compatible configuration, follows existing implementation,
> provides single pool and no description for segment sizes
> and offsets.
> - mp is NULL, rx_conf.rx_seg is not NULL, rx_conf.rx_nseg is not
> zero, it provides the extended configuration, individually for
> each segment.
>
> f the Rx queue is configured with new settings the packets being
> received will be split into multiple segments pushed to the mbufs
> with specified attributes. The PMD will split the received packets
> into multiple segments according to the specification in the
> description array.
>
> For example, let's suppose we configured the Rx queue with the
> following segments:
> seg0 - pool0, len0=14B, off0=2
> seg1 - pool1, len1=20B, off1=128B
> seg2 - pool2, len2=20B, off2=0B
> seg3 - pool3, len3=512B, off3=0B
>
> The packet 46 bytes long will look like the following:
> seg0 - 14B long @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0
> seg1 - 20B long @ 128 in mbuf from pool1
> seg2 - 12B long @ 0 in mbuf from pool2
>
> The packet 1500 bytes long will look like the following:
> seg0 - 14B @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0
> seg1 - 20B @ 128 in mbuf from pool1
> seg2 - 20B @ 0 in mbuf from pool2
> seg3 - 512B @ 0 in mbuf from pool3
> seg4 - 512B @ 0 in mbuf from pool3
> seg5 - 422B @ 0 in mbuf from pool3
>
> The offload RTE_ETH_RX_OFFLOAD_SCATTER must be present and
> configured to support new buffer split feature (if rx_nseg
> is greater than one).
>
> The split limitations imposed by underlying PMD is reported
> in the new introduced rte_eth_dev_info->rx_seg_capa field.
>
> The new approach would allow splitting the ingress packets into
> multiple parts pushed to the memory with different attributes.
> For example, the packet headers can be pushed to the embedded
> data buffers within mbufs and the application data into
> the external buffers attached to mbufs allocated from the
> different memory pools. The memory attributes for the split
> parts may differ either - for example the application data
> may be pushed into the external memory located on the dedicated
> physical device, say GPU or NVMe. This would improve the DPDK
> receiving datapath flexibility with preserving compatibility
> with existing API.
>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Acked-by: Jerin Jacob <jerinj@marvell.com>
> Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
<...>
> +.. _nic_features_buffer_split:
> +
> +Buffer Split on Rx
> +------------------
> +
> +Scatters the packets being received on specified boundaries to segmented mbufs.
> +
> +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT``.
> +* **[uses] rte_eth_rxconf**: ``rx_conf.rx_seg, rx_conf.rx_nseg``.
> +* **[implements] datapath**: ``Buffer Split functionality``.
> +* **[provides] rte_eth_dev_info**: ``rx_offload_capa:RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT``.
> +* **[provides] eth_dev_ops**: ``rxq_info_get:buffer_split``.
Previously you mentioned this is because 'rxq_info_get()' can provide
buffer_split information, but with current implementation it doesn't and there
is no filed in the struct to report such.
I suggest either add it now, while you can :) [with a techboard approval], or
remove above documentation of it.
<...>
> /**
> + * Ethernet device Rx buffer segmentation capabilities.
> + */
> +__rte_experimental
> +struct rte_eth_rxseg_capa {
> + __extension__
> + uint32_t max_nseg:16; /**< Maximum amount of segments to split. */
> + uint32_t multi_pools:1; /**< Supports receiving to multiple pools.*/
> + uint32_t offset_allowed:1; /**< Supports buffer offsets. */
> + uint32_t offset_align_log2:4; /**< Required offset alignment. */
> +};
Now we are fiddling details, but,
I am not fun of the bitfields [1], but I assumed Thomas' request was to enable
expanding capabilities later without breaking the ABI, which makes senses and
suits to this kind of capability struct, if this is correct why made the
'max_nseg' a bitfield too?
Why not,
uint16_t max_nseg;
uint16_t multi_pools:1
uint16_t offset_allowed:1;
uint16_t offset_align_log2:4;
< This still leaves 10 bits to expand without ABI break>
[1]
unles very space critical use case, otherwise they just add more code to extract
the same value, and not as simple as a simple variable :)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int
2020-10-15 13:30 4% ` [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int Andrew Rybchenko
2020-10-16 9:22 0% ` Ferruh Yigit
@ 2020-10-16 11:20 3% ` Kinsella, Ray
2020-10-16 17:13 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Kinsella, Ray @ 2020-10-16 11:20 UTC (permalink / raw)
To: Andrew Rybchenko, Neil Horman, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko
Cc: dev, Ivan Ilchenko
On 15/10/2020 14:30, Andrew Rybchenko wrote:
> From: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>
> Change rte_eth_dev_stop() return value from void to int
> and return negative errno values in case of error conditions.
> Also update the usage of the function in ethdev according to
> the new return type.
>
> Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> doc/guides/rel_notes/deprecation.rst | 1 -
> doc/guides/rel_notes/release_20_11.rst | 3 +++
> lib/librte_ethdev/rte_ethdev.c | 27 +++++++++++++++++++-------
> lib/librte_ethdev/rte_ethdev.h | 5 ++++-
> 4 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index d1f5ed39db..2e04e24374 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -127,7 +127,6 @@ Deprecation Notices
> negative errno values to indicate various error conditions (e.g.
> invalid port ID, unsupported operation, failed operation):
>
> - - ``rte_eth_dev_stop``
> - ``rte_eth_dev_close``
>
> * ethdev: New offload flags ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11.
> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
> index f8686a50db..c8c30937fa 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -355,6 +355,9 @@ API Changes
> * vhost: Add a new function ``rte_vhost_crypto_driver_start`` to be called
> instead of ``rte_vhost_driver_start`` by crypto applications.
>
> +* ethdev: changed ``rte_eth_dev_stop`` return value from ``void`` to
> + ``int`` to provide a way to report various error conditions.
> +
>
> ABI Changes
> -----------
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index d9b82df073..b8cf04ef4d 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -1661,7 +1661,7 @@ rte_eth_dev_start(uint16_t port_id)
> struct rte_eth_dev *dev;
> struct rte_eth_dev_info dev_info;
> int diag;
> - int ret;
> + int ret, ret_stop;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
>
> @@ -1695,7 +1695,13 @@ rte_eth_dev_start(uint16_t port_id)
> RTE_ETHDEV_LOG(ERR,
> "Error during restoring configuration for device (port %u): %s\n",
> port_id, rte_strerror(-ret));
> - rte_eth_dev_stop(port_id);
> + ret_stop = rte_eth_dev_stop(port_id);
> + if (ret_stop != 0) {
> + RTE_ETHDEV_LOG(ERR,
> + "Failed to stop device (port %u): %s\n",
> + port_id, rte_strerror(-ret_stop));
> + }
> +
> return ret;
> }
>
> @@ -1708,26 +1714,28 @@ rte_eth_dev_start(uint16_t port_id)
> return 0;
> }
>
> -void
> +int
> rte_eth_dev_stop(uint16_t port_id)
> {
> struct rte_eth_dev *dev;
>
> - RTE_ETH_VALID_PORTID_OR_RET(port_id);
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
>
> - RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_stop);
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_stop, -ENOTSUP);
>
> if (dev->data->dev_started == 0) {
> RTE_ETHDEV_LOG(INFO,
> "Device with port_id=%"PRIu16" already stopped\n",
> port_id);
> - return;
> + return 0;
> }
>
> dev->data->dev_started = 0;
> (*dev->dev_ops->dev_stop)(dev);
> rte_ethdev_trace_stop(port_id);
> +
> + return 0;
> }
>
> int
> @@ -1783,7 +1791,12 @@ rte_eth_dev_reset(uint16_t port_id)
>
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_reset, -ENOTSUP);
>
> - rte_eth_dev_stop(port_id);
> + ret = rte_eth_dev_stop(port_id);
> + if (ret != 0) {
> + RTE_ETHDEV_LOG(ERR,
> + "Failed to stop device (port %u) before reset: %s - ignore\n",
> + port_id, rte_strerror(-ret));
ABI change is 100%,
Just question the logic of continuing here to do a reset, if you failed to stop the device.
> + }
> ret = dev->dev_ops->dev_reset(dev);
>
> return eth_err(port_id, ret);
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index a61ca115a0..b85861cf2b 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -2277,8 +2277,11 @@ int rte_eth_dev_start(uint16_t port_id);
> *
> * @param port_id
> * The port identifier of the Ethernet device.
> + * @return
> + * - 0: Success, Ethernet device stopped.
> + * - <0: Error code of the driver device stop function.
> */
> -void rte_eth_dev_stop(uint16_t port_id);
> +int rte_eth_dev_stop(uint16_t port_id);
>
> /**
> * Link up an Ethernet device.
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int
2020-10-15 13:30 4% ` [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int Andrew Rybchenko
@ 2020-10-16 9:22 0% ` Ferruh Yigit
2020-10-16 11:20 3% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2020-10-16 9:22 UTC (permalink / raw)
To: Andrew Rybchenko, Ray Kinsella, Neil Horman, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Ivan Ilchenko
On 10/15/2020 2:30 PM, Andrew Rybchenko wrote:
> From: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>
> Change rte_eth_dev_stop() return value from void to int
> and return negative errno values in case of error conditions.
> Also update the usage of the function in ethdev according to
> the new return type.
>
> Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
<...>
> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
> index f8686a50db..c8c30937fa 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -355,6 +355,9 @@ API Changes
> * vhost: Add a new function ``rte_vhost_crypto_driver_start`` to be called
> instead of ``rte_vhost_driver_start`` by crypto applications.
>
> +* ethdev: changed ``rte_eth_dev_stop`` return value from ``void`` to
> + ``int`` to provide a way to report various error conditions.
> +
>
If there will be a new version, there is a ethdev block already in this section
can you please move the paragraph up there?
> ABI Changes
> -----------
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index d9b82df073..b8cf04ef4d 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -1661,7 +1661,7 @@ rte_eth_dev_start(uint16_t port_id)
> struct rte_eth_dev *dev;
> struct rte_eth_dev_info dev_info;
> int diag;
> - int ret;
> + int ret, ret_stop;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
>
> @@ -1695,7 +1695,13 @@ rte_eth_dev_start(uint16_t port_id)
> RTE_ETHDEV_LOG(ERR,
> "Error during restoring configuration for device (port %u): %s\n",
> port_id, rte_strerror(-ret));
> - rte_eth_dev_stop(port_id);
> + ret_stop = rte_eth_dev_stop(port_id);
> + if (ret_stop != 0) {
> + RTE_ETHDEV_LOG(ERR,
> + "Failed to stop device (port %u): %s\n",
> + port_id, rte_strerror(-ret_stop));
> + }
> +
Again, if there will be a new version already,
This is the 'rte_eth_dev_start()' function and error log is "Failed to stop
device .." :)
What do you think about adding a little more detail, like "failed to stop back
on error" etc...
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] performance degradation with fpic
@ 2020-10-16 8:35 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2020-10-16 8:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, Ali Alnubani, dev, Asaf Penso, david.marchand,
arybchenko, ferruh.yigit, honnappa.nagarahalli, jerinj
On Thu, Oct 15, 2020 at 02:44:49PM -0700, Stephen Hemminger wrote:
> On Thu, 15 Oct 2020 19:14:48 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 15/10/2020 19:08, Bruce Richardson:
> > > On Thu, Oct 15, 2020 at 04:00:44PM +0000, Ali Alnubani wrote:
> > > > We have been seeing in some cases that the DPDK forwarding performance
> > > > is up to 9% lower when DPDK is built as static with meson compared to a
> > > > build with makefiles.
> > > >
> > > > The same degradation can be reproduced with makefiles on older DPDK
> > > > releases when building with EXTAR_CFLAGS set to “-fPIC”, it can also be
> > > > resolved in meson when passing “pic: false” to meson’s static_library
> > > > call (more tweaking needs to be done to prevent building shared
> > > > libraries because this change breaks them).
> > [...]
> > > > Should we disable PIC in static builds?
> > >
> > > thanks for reporting, though it's strange that you see such a big impact.
> > > In my previous tests with i40e driver I never noticed a difference between
> > > make and meson builds, and I and some others here have been using meson
> > > builds for any performance work for over a year now. That being said let me
> > > reverify what I see on my end.
> > >
> > > In terms of solutions, disabling the -fPIC flag globally implies that we
> > > can no longer build static and shared libs from the same sources, so we
> > > would need to revert to doing either a static or a shared library build
> > > but not both. If the issue is limited to only some drivers or some cases,
> > > we can perhaps add in a build option to have no-fpic-static builds, to be
> > > used in a cases where it is problematic.
> >
> > I assume only some Rx/Tx functions are impacted.
> > We probably need such disabling option per-file.
> >
> > > However, at this point, I think we need a little more investigation. Is
> > > there any testing you can do to see if it's just in your driver, or in
> > > perhaps a mempool driver/lib that the issue appears, or if it's just a
> > > global slowdown? Do you see the impact with both clang and gcc? I'll
> > > retest things a bit tomorrow on my end to see what I see.
> >
> > Yes we need to know which libs or files are impacted by -fPIC.
>
> The issue is that all shared libraries need to be built with PIC.
> So it is a question of static vs shared library build.
Well, partially yes, but really using fPIC should only have a very small
difference in drivers. Therefore I'd like to know what's causing this
massive drop because, while disabling fPIC in the static builds (perhaps
per-component to avoid doubling the build time) will improve perf in the
static case, it will still leave a perf drop when a user switches to shared
libs. Since we want to move to a model where people are using shared
libraries and can update seamlessly due to constant ABI, I therefore think
we need to root cause this so we can fix the shared lib builds too - since
disabling fPIC is not an option there.
/Bruce
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 03/20] eal: rename lcore word choices
@ 2020-10-15 22:57 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-15 22:57 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Anatoly Burakov
Replace master lcore with main lcore and
replace slave lcore with worker lcore.
Keep the old functions and macros but mark them as deprecated
for this release.
The "--master-lcore" command line option is also deprecated
and any usage will print a warning and use "--main-lcore"
as replacement.
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 19 -------
doc/guides/rel_notes/release_20_11.rst | 11 ++++
lib/librte_eal/common/eal_common_dynmem.c | 10 ++--
lib/librte_eal/common/eal_common_launch.c | 36 ++++++------
lib/librte_eal/common/eal_common_lcore.c | 8 +--
lib/librte_eal/common/eal_common_options.c | 64 ++++++++++++----------
lib/librte_eal/common/eal_options.h | 2 +
lib/librte_eal/common/eal_private.h | 6 +-
lib/librte_eal/common/rte_random.c | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
lib/librte_eal/freebsd/eal.c | 28 +++++-----
lib/librte_eal/freebsd/eal_thread.c | 32 +++++------
lib/librte_eal/include/rte_eal.h | 4 +-
lib/librte_eal/include/rte_eal_trace.h | 4 +-
lib/librte_eal/include/rte_launch.h | 60 ++++++++++----------
lib/librte_eal/include/rte_lcore.h | 35 ++++++++----
lib/librte_eal/linux/eal.c | 28 +++++-----
lib/librte_eal/linux/eal_memory.c | 10 ++--
lib/librte_eal/linux/eal_thread.c | 32 +++++------
lib/librte_eal/rte_eal_version.map | 2 +-
lib/librte_eal/windows/eal.c | 16 +++---
lib/librte_eal/windows/eal_thread.c | 30 +++++-----
22 files changed, 230 insertions(+), 211 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 604f198059c5..1eb8bd3643f1 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,25 +20,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: To be more inclusive in choice of naming, the DPDK project
- will replace uses of master/slave in the API's and command line arguments.
-
- References to master/slave in relation to lcore will be renamed
- to initial/worker. The function ``rte_get_master_lcore()``
- will be renamed to ``rte_get_initial_lcore()``.
- For the 20.11 release, both names will be present and the
- old function will be marked with the deprecated tag.
- The old function will be removed in a future version.
-
- The iterator for worker lcores will also change:
- ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
- ``RTE_LCORE_FOREACH_WORKER``.
-
- The ``master-lcore`` argument to testpmd will be replaced
- with ``initial-lcore``. The old ``master-lcore`` argument
- will produce a runtime notification in 20.11 release, and
- be removed completely in a future release.
-
* 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 as well as macros.
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 708ebb01c85d..c1a907390a79 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -430,6 +430,17 @@ API Changes
* sched: Removed ``tb_rate``, ``tc_rate``, ``tc_period`` and ``tb_size``
from ``struct rte_sched_subport_params``.
+* eal: Changed the function ``rte_get_master_lcore()`` is
+ replaced to ``rte_get_main_lcore()``. The old function is deprecated.
+
+ The iterator for worker lcores will also change:
+ ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
+ ``RTE_LCORE_FOREACH_WORKER``.
+
+ The ``master-lcore`` argument to testpmd will be replaced
+ with ``main-lcore``. The old ``master-lcore`` argument
+ will produce a runtime notification in 20.11 release, and
+ be removed completely in a future release.
ABI Changes
-----------
diff --git a/lib/librte_eal/common/eal_common_dynmem.c b/lib/librte_eal/common/eal_common_dynmem.c
index 614648d8a4de..1cefe52443c4 100644
--- a/lib/librte_eal/common/eal_common_dynmem.c
+++ b/lib/librte_eal/common/eal_common_dynmem.c
@@ -427,19 +427,19 @@ eal_dynmem_calc_num_pages_per_socket(
total_size -= default_size;
}
#else
- /* in 32-bit mode, allocate all of the memory only on master
+ /* in 32-bit mode, allocate all of the memory only on main
* lcore socket
*/
total_size = internal_conf->memory;
for (socket = 0; socket < RTE_MAX_NUMA_NODES && total_size != 0;
socket++) {
struct rte_config *cfg = rte_eal_get_configuration();
- unsigned int master_lcore_socket;
+ unsigned int main_lcore_socket;
- master_lcore_socket =
- rte_lcore_to_socket_id(cfg->master_lcore);
+ main_lcore_socket =
+ rte_lcore_to_socket_id(cfg->main_lcore);
- if (master_lcore_socket != socket)
+ if (main_lcore_socket != socket)
continue;
/* Update sizes */
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index cf52d717f68e..34f854ad80c8 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -21,55 +21,55 @@
* Wait until a lcore finished its job.
*/
int
-rte_eal_wait_lcore(unsigned slave_id)
+rte_eal_wait_lcore(unsigned worker_id)
{
- if (lcore_config[slave_id].state == WAIT)
+ if (lcore_config[worker_id].state == WAIT)
return 0;
- while (lcore_config[slave_id].state != WAIT &&
- lcore_config[slave_id].state != FINISHED)
+ while (lcore_config[worker_id].state != WAIT &&
+ lcore_config[worker_id].state != FINISHED)
rte_pause();
rte_rmb();
/* we are in finished state, go to wait state */
- lcore_config[slave_id].state = WAIT;
- return lcore_config[slave_id].ret;
+ lcore_config[worker_id].state = WAIT;
+ return lcore_config[worker_id].ret;
}
/*
- * Check that every SLAVE lcores are in WAIT state, then call
- * rte_eal_remote_launch() for all of them. If call_master is true
- * (set to CALL_MASTER), also call the function on the master lcore.
+ * Check that every WORKER lcores are in WAIT state, then call
+ * rte_eal_remote_launch() for all of them. If call_main is true
+ * (set to CALL_MAIN), also call the function on the main lcore.
*/
int
rte_eal_mp_remote_launch(int (*f)(void *), void *arg,
- enum rte_rmt_call_master_t call_master)
+ enum rte_rmt_call_main_t call_main)
{
int lcore_id;
- int master = rte_get_master_lcore();
+ int main_lcore = rte_get_main_lcore();
/* check state of lcores */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (lcore_config[lcore_id].state != WAIT)
return -EBUSY;
}
/* send messages to cores */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_remote_launch(f, arg, lcore_id);
}
- if (call_master == CALL_MASTER) {
- lcore_config[master].ret = f(arg);
- lcore_config[master].state = FINISHED;
+ if (call_main == CALL_MAIN) {
+ lcore_config[main_lcore].ret = f(arg);
+ lcore_config[main_lcore].state = FINISHED;
}
return 0;
}
/*
- * Return the state of the lcore identified by slave_id.
+ * Return the state of the lcore identified by worker_id.
*/
enum rte_lcore_state_t
rte_eal_get_lcore_state(unsigned lcore_id)
@@ -86,7 +86,7 @@ rte_eal_mp_wait_lcore(void)
{
unsigned lcore_id;
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_wait_lcore(lcore_id);
}
}
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index d64569b3c758..66d6bad1a7d7 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -18,9 +18,9 @@
#include "eal_private.h"
#include "eal_thread.h"
-unsigned int rte_get_master_lcore(void)
+unsigned int rte_get_main_lcore(void)
{
- return rte_eal_get_configuration()->master_lcore;
+ return rte_eal_get_configuration()->main_lcore;
}
unsigned int rte_lcore_count(void)
@@ -93,7 +93,7 @@ int rte_lcore_is_enabled(unsigned int lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap)
+unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap)
{
i++;
if (wrap)
@@ -101,7 +101,7 @@ unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap)
while (i < RTE_MAX_LCORE) {
if (!rte_lcore_is_enabled(i) ||
- (skip_master && (i == rte_get_master_lcore()))) {
+ (skip_main && (i == rte_get_main_lcore()))) {
i++;
if (wrap)
i %= RTE_MAX_LCORE;
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index a5426e12346a..d221886eb22c 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -81,6 +81,7 @@ eal_long_options[] = {
{OPT_TRACE_BUF_SIZE, 1, NULL, OPT_TRACE_BUF_SIZE_NUM },
{OPT_TRACE_MODE, 1, NULL, OPT_TRACE_MODE_NUM },
{OPT_MASTER_LCORE, 1, NULL, OPT_MASTER_LCORE_NUM },
+ {OPT_MAIN_LCORE, 1, NULL, OPT_MAIN_LCORE_NUM },
{OPT_MBUF_POOL_OPS_NAME, 1, NULL, OPT_MBUF_POOL_OPS_NAME_NUM},
{OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
{OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
@@ -144,7 +145,7 @@ struct device_option {
static struct device_option_list devopt_list =
TAILQ_HEAD_INITIALIZER(devopt_list);
-static int master_lcore_parsed;
+static int main_lcore_parsed;
static int mem_parsed;
static int core_parsed;
@@ -575,12 +576,12 @@ eal_parse_service_coremask(const char *coremask)
for (j = 0; j < BITS_PER_HEX && idx < RTE_MAX_LCORE;
j++, idx++) {
if ((1 << j) & val) {
- /* handle master lcore already parsed */
+ /* handle main lcore already parsed */
uint32_t lcore = idx;
- if (master_lcore_parsed &&
- cfg->master_lcore == lcore) {
+ if (main_lcore_parsed &&
+ cfg->main_lcore == lcore) {
RTE_LOG(ERR, EAL,
- "lcore %u is master lcore, cannot use as service core\n",
+ "lcore %u is main lcore, cannot use as service core\n",
idx);
return -1;
}
@@ -748,12 +749,12 @@ eal_parse_service_corelist(const char *corelist)
min = idx;
for (idx = min; idx <= max; idx++) {
if (cfg->lcore_role[idx] != ROLE_SERVICE) {
- /* handle master lcore already parsed */
+ /* handle main lcore already parsed */
uint32_t lcore = idx;
- if (cfg->master_lcore == lcore &&
- master_lcore_parsed) {
+ if (cfg->main_lcore == lcore &&
+ main_lcore_parsed) {
RTE_LOG(ERR, EAL,
- "Error: lcore %u is master lcore, cannot use as service core\n",
+ "Error: lcore %u is main lcore, cannot use as service core\n",
idx);
return -1;
}
@@ -836,25 +837,25 @@ eal_parse_corelist(const char *corelist, int *cores)
return 0;
}
-/* Changes the lcore id of the master thread */
+/* Changes the lcore id of the main thread */
static int
-eal_parse_master_lcore(const char *arg)
+eal_parse_main_lcore(const char *arg)
{
char *parsing_end;
struct rte_config *cfg = rte_eal_get_configuration();
errno = 0;
- cfg->master_lcore = (uint32_t) strtol(arg, &parsing_end, 0);
+ cfg->main_lcore = (uint32_t) strtol(arg, &parsing_end, 0);
if (errno || parsing_end[0] != 0)
return -1;
- if (cfg->master_lcore >= RTE_MAX_LCORE)
+ if (cfg->main_lcore >= RTE_MAX_LCORE)
return -1;
- master_lcore_parsed = 1;
+ main_lcore_parsed = 1;
- /* ensure master core is not used as service core */
- if (lcore_config[cfg->master_lcore].core_role == ROLE_SERVICE) {
+ /* ensure main core is not used as service core */
+ if (lcore_config[cfg->main_lcore].core_role == ROLE_SERVICE) {
RTE_LOG(ERR, EAL,
- "Error: Master lcore is used as a service core\n");
+ "Error: Main lcore is used as a service core\n");
return -1;
}
@@ -1593,9 +1594,14 @@ eal_parse_common_option(int opt, const char *optarg,
break;
case OPT_MASTER_LCORE_NUM:
- if (eal_parse_master_lcore(optarg) < 0) {
+ fprintf(stderr,
+ "Option --" OPT_MASTER_LCORE
+ " is deprecated use " OPT_MAIN_LCORE "\n");
+ /* fallthrough */
+ case OPT_MAIN_LCORE_NUM:
+ if (eal_parse_main_lcore(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
- OPT_MASTER_LCORE "\n");
+ OPT_MAIN_LCORE "\n");
return -1;
}
break;
@@ -1763,9 +1769,9 @@ compute_ctrl_threads_cpuset(struct internal_config *internal_cfg)
RTE_CPU_AND(cpuset, cpuset, &default_set);
- /* if no remaining cpu, use master lcore cpu affinity */
+ /* if no remaining cpu, use main lcore cpu affinity */
if (!CPU_COUNT(cpuset)) {
- memcpy(cpuset, &lcore_config[rte_get_master_lcore()].cpuset,
+ memcpy(cpuset, &lcore_config[rte_get_main_lcore()].cpuset,
sizeof(*cpuset));
}
}
@@ -1797,12 +1803,12 @@ eal_adjust_config(struct internal_config *internal_cfg)
if (internal_conf->process_type == RTE_PROC_AUTO)
internal_conf->process_type = eal_proc_type_detect();
- /* default master lcore is the first one */
- if (!master_lcore_parsed) {
- cfg->master_lcore = rte_get_next_lcore(-1, 0, 0);
- if (cfg->master_lcore >= RTE_MAX_LCORE)
+ /* default main lcore is the first one */
+ if (!main_lcore_parsed) {
+ cfg->main_lcore = rte_get_next_lcore(-1, 0, 0);
+ if (cfg->main_lcore >= RTE_MAX_LCORE)
return -1;
- lcore_config[cfg->master_lcore].core_role = ROLE_RTE;
+ lcore_config[cfg->main_lcore].core_role = ROLE_RTE;
}
compute_ctrl_threads_cpuset(internal_cfg);
@@ -1822,8 +1828,8 @@ eal_check_common_options(struct internal_config *internal_cfg)
const struct internal_config *internal_conf =
eal_get_internal_configuration();
- if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
- RTE_LOG(ERR, EAL, "Master lcore is not enabled for DPDK\n");
+ if (cfg->lcore_role[cfg->main_lcore] != ROLE_RTE) {
+ RTE_LOG(ERR, EAL, "Main lcore is not enabled for DPDK\n");
return -1;
}
@@ -1921,7 +1927,7 @@ eal_common_usage(void)
" '( )' can be omitted for single element group,\n"
" '@' can be omitted if cpus and lcores have the same value\n"
" -s SERVICE COREMASK Hexadecimal bitmask of cores to be used as service cores\n"
- " --"OPT_MASTER_LCORE" ID Core ID that is used as master\n"
+ " --"OPT_MAIN_LCORE" ID Core ID that is used as main\n"
" --"OPT_MBUF_POOL_OPS_NAME" Pool ops name for mbuf to use\n"
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index 89769d48b487..d363228a7a25 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -43,6 +43,8 @@ enum {
OPT_TRACE_BUF_SIZE_NUM,
#define OPT_TRACE_MODE "trace-mode"
OPT_TRACE_MODE_NUM,
+#define OPT_MAIN_LCORE "main-lcore"
+ OPT_MAIN_LCORE_NUM,
#define OPT_MASTER_LCORE "master-lcore"
OPT_MASTER_LCORE_NUM,
#define OPT_MBUF_POOL_OPS_NAME "mbuf-pool-ops-name"
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index a6a6381567f4..4684c4c7df19 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -20,8 +20,8 @@
*/
struct lcore_config {
pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
+ int pipe_main2worker[2]; /**< communication pipe with main */
+ int pipe_worker2main[2]; /**< communication pipe with main */
lcore_function_t * volatile f; /**< function to call */
void * volatile arg; /**< argument of function */
@@ -42,7 +42,7 @@ extern struct lcore_config lcore_config[RTE_MAX_LCORE];
* The global RTE configuration structure.
*/
struct rte_config {
- uint32_t master_lcore; /**< Id of the master lcore */
+ uint32_t main_lcore; /**< Id of the main lcore */
uint32_t lcore_count; /**< Number of available logical cores. */
uint32_t numa_node_count; /**< Number of detected NUMA nodes. */
uint32_t numa_nodes[RTE_MAX_NUMA_NODES]; /**< List of detected NUMA nodes. */
diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
index b2c5416b331d..ce21c2242a22 100644
--- a/lib/librte_eal/common/rte_random.c
+++ b/lib/librte_eal/common/rte_random.c
@@ -122,7 +122,7 @@ struct rte_rand_state *__rte_rand_get_state(void)
lcore_id = rte_lcore_id();
if (unlikely(lcore_id == LCORE_ID_ANY))
- lcore_id = rte_get_master_lcore();
+ lcore_id = rte_get_main_lcore();
return &rand_states[lcore_id];
}
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 98565bbef340..6c955d319ad4 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -107,7 +107,7 @@ rte_service_init(void)
struct rte_config *cfg = rte_eal_get_configuration();
for (i = 0; i < RTE_MAX_LCORE; i++) {
if (lcore_config[i].core_role == ROLE_SERVICE) {
- if ((unsigned int)i == cfg->master_lcore)
+ if ((unsigned int)i == cfg->main_lcore)
continue;
rte_service_lcore_add(i);
count++;
diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
index ccea60afe77b..d6ea02375025 100644
--- a/lib/librte_eal/freebsd/eal.c
+++ b/lib/librte_eal/freebsd/eal.c
@@ -625,10 +625,10 @@ eal_check_mem_on_local_socket(void)
int socket_id;
const struct rte_config *config = rte_eal_get_configuration();
- socket_id = rte_lcore_to_socket_id(config->master_lcore);
+ socket_id = rte_lcore_to_socket_id(config->main_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
- RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
+ RTE_LOG(WARNING, EAL, "WARNING: Main core has no memory on local socket!\n");
}
@@ -851,29 +851,29 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
if (pthread_setaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
- &lcore_config[config->master_lcore].cpuset) != 0) {
+ &lcore_config[config->main_lcore].cpuset) != 0) {
rte_eal_init_alert("Cannot set affinity");
rte_errno = EINVAL;
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%p;cpuset=[%s%s])\n",
- config->master_lcore, thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Main lcore %u is ready (tid=%p;cpuset=[%s%s])\n",
+ config->main_lcore, thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_main2worker) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_worker2main) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -886,7 +886,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-worker-%d", i);
rte_thread_setname(lcore_config[i].thread_id, thread_name);
ret = pthread_setaffinity_np(lcore_config[i].thread_id,
@@ -896,10 +896,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
/* initialize services so vdevs register service during bus_probe. */
diff --git a/lib/librte_eal/freebsd/eal_thread.c b/lib/librte_eal/freebsd/eal_thread.c
index 99b5fefc4c5b..1dce9b04f24a 100644
--- a/lib/librte_eal/freebsd/eal_thread.c
+++ b/lib/librte_eal/freebsd/eal_thread.c
@@ -26,35 +26,35 @@
#include "eal_thread.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
+rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
int rc = -EBUSY;
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
goto finish;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
+ n = write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = read(s2m, &c, 1);
+ n = read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -62,7 +62,7 @@ rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
rc = 0;
finish:
- rte_eal_trace_thread_remote_launch(f, arg, slave_id, rc);
+ rte_eal_trace_thread_remote_launch(f, arg, worker_id, rc);
return rc;
}
@@ -74,21 +74,21 @@ eal_thread_loop(__rte_unused void *arg)
int n, ret;
unsigned lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -104,7 +104,7 @@ eal_thread_loop(__rte_unused void *arg)
/* wait command */
do {
- n = read(m2s, &c, 1);
+ n = read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -115,7 +115,7 @@ eal_thread_loop(__rte_unused void *arg)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(s2m, &c, 1);
+ n = write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
diff --git a/lib/librte_eal/include/rte_eal.h b/lib/librte_eal/include/rte_eal.h
index e3c2ef185eed..0ae12cf4fbac 100644
--- a/lib/librte_eal/include/rte_eal.h
+++ b/lib/librte_eal/include/rte_eal.h
@@ -65,11 +65,11 @@ int rte_eal_iopl_init(void);
/**
* Initialize the Environment Abstraction Layer (EAL).
*
- * This function is to be executed on the MASTER lcore only, as soon
+ * This function is to be executed on the MAIN lcore only, as soon
* as possible in the application's main() function.
*
* The function finishes the initialization process before main() is called.
- * It puts the SLAVE lcores in the WAIT state.
+ * It puts the WORKER lcores in the WAIT state.
*
* When the multi-partition feature is supported, depending on the
* configuration (if CONFIG_RTE_EAL_MAIN_PARTITION is disabled), this
diff --git a/lib/librte_eal/include/rte_eal_trace.h b/lib/librte_eal/include/rte_eal_trace.h
index 19df549d29be..495ae1ee1d61 100644
--- a/lib/librte_eal/include/rte_eal_trace.h
+++ b/lib/librte_eal/include/rte_eal_trace.h
@@ -264,10 +264,10 @@ RTE_TRACE_POINT(
RTE_TRACE_POINT(
rte_eal_trace_thread_remote_launch,
RTE_TRACE_POINT_ARGS(int (*f)(void *), void *arg,
- unsigned int slave_id, int rc),
+ unsigned int worker_id, int rc),
rte_trace_point_emit_ptr(f);
rte_trace_point_emit_ptr(arg);
- rte_trace_point_emit_u32(slave_id);
+ rte_trace_point_emit_u32(worker_id);
rte_trace_point_emit_int(rc);
)
RTE_TRACE_POINT(
diff --git a/lib/librte_eal/include/rte_launch.h b/lib/librte_eal/include/rte_launch.h
index 06a671752ace..22a901ce62f6 100644
--- a/lib/librte_eal/include/rte_launch.h
+++ b/lib/librte_eal/include/rte_launch.h
@@ -32,12 +32,12 @@ typedef int (lcore_function_t)(void *);
/**
* Launch a function on another lcore.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * Sends a message to a slave lcore (identified by the slave_id) that
+ * Sends a message to a worker lcore (identified by the worker_id) that
* is in the WAIT state (this is true after the first call to
* rte_eal_init()). This can be checked by first calling
- * rte_eal_wait_lcore(slave_id).
+ * rte_eal_wait_lcore(worker_id).
*
* When the remote lcore receives the message, it switches to
* the RUNNING state, then calls the function f with argument arg. Once the
@@ -45,7 +45,7 @@ typedef int (lcore_function_t)(void *);
* the return value of f is stored in a local variable to be read using
* rte_eal_wait_lcore().
*
- * The MASTER lcore returns as soon as the message is sent and knows
+ * The MAIN lcore returns as soon as the message is sent and knows
* nothing about the completion of f.
*
* Note: This function is not designed to offer optimum
@@ -56,37 +56,41 @@ typedef int (lcore_function_t)(void *);
* The function to be called.
* @param arg
* The argument for the function.
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore on which the function should be executed.
* @return
* - 0: Success. Execution of function f started on the remote lcore.
* - (-EBUSY): The remote lcore is not in a WAIT state.
*/
-int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned slave_id);
+int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned worker_id);
/**
- * This enum indicates whether the master core must execute the handler
+ * This enum indicates whether the main core must execute the handler
* launched on all logical cores.
*/
-enum rte_rmt_call_master_t {
- SKIP_MASTER = 0, /**< lcore handler not executed by master core. */
- CALL_MASTER, /**< lcore handler executed by master core. */
+enum rte_rmt_call_main_t {
+ SKIP_MAIN = 0, /**< lcore handler not executed by main core. */
+ CALL_MAIN, /**< lcore handler executed by main core. */
};
+/* These legacy definitions will be removed in future release */
+#define SKIP_MASTER RTE_DEPRECATED(SKIP_MASTER) SKIP_MAIN
+#define CALL_MASTER RTE_DEPRECATED(CALL_MASTER) CALL_MAIN
+
/**
* Launch a function on all lcores.
*
- * Check that each SLAVE lcore is in a WAIT state, then call
+ * Check that each WORKER lcore is in a WAIT state, then call
* rte_eal_remote_launch() for each lcore.
*
* @param f
* The function to be called.
* @param arg
* The argument for the function.
- * @param call_master
- * If call_master set to SKIP_MASTER, the MASTER lcore does not call
- * the function. If call_master is set to CALL_MASTER, the function
- * is also called on master before returning. In any case, the master
+ * @param call_main
+ * If call_main set to SKIP_MAIN, the MAIN lcore does not call
+ * the function. If call_main is set to CALL_MAIN, the function
+ * is also called on main before returning. In any case, the main
* lcore returns as soon as it finished its job and knows nothing
* about the completion of f on the other lcores.
* @return
@@ -95,49 +99,49 @@ enum rte_rmt_call_master_t {
* case, no message is sent to any of the lcores.
*/
int rte_eal_mp_remote_launch(lcore_function_t *f, void *arg,
- enum rte_rmt_call_master_t call_master);
+ enum rte_rmt_call_main_t call_main);
/**
- * Get the state of the lcore identified by slave_id.
+ * Get the state of the lcore identified by worker_id.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore.
* @return
* The state of the lcore.
*/
-enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned slave_id);
+enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned int worker_id);
/**
* Wait until an lcore finishes its job.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * If the slave lcore identified by the slave_id is in a FINISHED state,
+ * If the worker lcore identified by the worker_id is in a FINISHED state,
* switch to the WAIT state. If the lcore is in RUNNING state, wait until
* the lcore finishes its job and moves to the FINISHED state.
*
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore.
* @return
- * - 0: If the lcore identified by the slave_id is in a WAIT state.
+ * - 0: If the lcore identified by the worker_id is in a WAIT state.
* - The value that was returned by the previous remote launch
- * function call if the lcore identified by the slave_id was in a
+ * function call if the lcore identified by the worker_id was in a
* FINISHED or RUNNING state. In this case, it changes the state
* of the lcore to WAIT.
*/
-int rte_eal_wait_lcore(unsigned slave_id);
+int rte_eal_wait_lcore(unsigned worker_id);
/**
* Wait until all lcores finish their jobs.
*
- * To be executed on the MASTER lcore only. Issue an
+ * To be executed on the MAIN lcore only. Issue an
* rte_eal_wait_lcore() for every lcore. The return values are
* ignored.
*
* After a call to rte_eal_mp_wait_lcore(), the caller can assume
- * that all slave lcores are in a WAIT state.
+ * that all worker lcores are in a WAIT state.
*/
void rte_eal_mp_wait_lcore(void);
diff --git a/lib/librte_eal/include/rte_lcore.h b/lib/librte_eal/include/rte_lcore.h
index b8b64a625200..48b87e253afa 100644
--- a/lib/librte_eal/include/rte_lcore.h
+++ b/lib/librte_eal/include/rte_lcore.h
@@ -78,12 +78,24 @@ rte_lcore_id(void)
}
/**
- * Get the id of the master lcore
+ * Get the id of the main lcore
*
* @return
- * the id of the master lcore
+ * the id of the main lcore
*/
-unsigned int rte_get_master_lcore(void);
+unsigned int rte_get_main_lcore(void);
+
+/**
+ * Deprecated function the id of the main lcore
+ *
+ * @return
+ * the id of the main lcore
+ */
+__rte_deprecated
+static inline unsigned int rte_get_master_lcore(void)
+{
+ return rte_get_main_lcore();
+}
/**
* Return the number of execution units (lcores) on the system.
@@ -203,32 +215,35 @@ int rte_lcore_is_enabled(unsigned int lcore_id);
*
* @param i
* The current lcore (reference).
- * @param skip_master
- * If true, do not return the ID of the master lcore.
+ * @param skip_main
+ * If true, do not return the ID of the main lcore.
* @param wrap
* If true, go back to 0 when RTE_MAX_LCORE is reached; otherwise,
* return RTE_MAX_LCORE.
* @return
* The next lcore_id or RTE_MAX_LCORE if not found.
*/
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap);
+unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap);
/**
* Macro to browse all running lcores.
*/
#define RTE_LCORE_FOREACH(i) \
for (i = rte_get_next_lcore(-1, 0, 0); \
- i<RTE_MAX_LCORE; \
+ i < RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 0, 0))
/**
- * Macro to browse all running lcores except the master lcore.
+ * Macro to browse all running lcores except the main lcore.
*/
-#define RTE_LCORE_FOREACH_SLAVE(i) \
+#define RTE_LCORE_FOREACH_WORKER(i) \
for (i = rte_get_next_lcore(-1, 1, 0); \
- i<RTE_MAX_LCORE; \
+ i < RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 1, 0))
+#define RTE_LCORE_FOREACH_SLAVE(l) \
+ RTE_DEPRECATED(RTE_LCORE_FOREACH_SLAVE) RTE_LCORE_FOREACH_WORKER(l)
+
/**
* Callback prototype for initializing lcores.
*
diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
index 9cf0e2ec0137..1c9dd8db1e6a 100644
--- a/lib/librte_eal/linux/eal.c
+++ b/lib/librte_eal/linux/eal.c
@@ -883,10 +883,10 @@ eal_check_mem_on_local_socket(void)
int socket_id;
const struct rte_config *config = rte_eal_get_configuration();
- socket_id = rte_lcore_to_socket_id(config->master_lcore);
+ socket_id = rte_lcore_to_socket_id(config->main_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
- RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
+ RTE_LOG(WARNING, EAL, "WARNING: Main core has no memory on local socket!\n");
}
static int
@@ -1215,28 +1215,28 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
if (pthread_setaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
- &lcore_config[config->master_lcore].cpuset) != 0) {
+ &lcore_config[config->main_lcore].cpuset) != 0) {
rte_eal_init_alert("Cannot set affinity");
rte_errno = EINVAL;
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
- config->master_lcore, (uintptr_t)thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Main lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
+ config->main_lcore, (uintptr_t)thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_main2worker) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_worker2main) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -1249,7 +1249,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-worker-%d", i);
ret = rte_thread_setname(lcore_config[i].thread_id,
thread_name);
if (ret != 0)
@@ -1263,10 +1263,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
/* initialize services so vdevs register service during bus_probe. */
diff --git a/lib/librte_eal/linux/eal_memory.c b/lib/librte_eal/linux/eal_memory.c
index 89725291b0ce..3e47efe58212 100644
--- a/lib/librte_eal/linux/eal_memory.c
+++ b/lib/librte_eal/linux/eal_memory.c
@@ -1737,7 +1737,7 @@ memseg_primary_init_32(void)
/* the allocation logic is a little bit convoluted, but here's how it
* works, in a nutshell:
* - if user hasn't specified on which sockets to allocate memory via
- * --socket-mem, we allocate all of our memory on master core socket.
+ * --socket-mem, we allocate all of our memory on main core socket.
* - if user has specified sockets to allocate memory on, there may be
* some "unused" memory left (e.g. if user has specified --socket-mem
* such that not all memory adds up to 2 gigabytes), so add it to all
@@ -1751,7 +1751,7 @@ memseg_primary_init_32(void)
for (i = 0; i < rte_socket_count(); i++) {
int hp_sizes = (int) internal_conf->num_hugepage_sizes;
uint64_t max_socket_mem, cur_socket_mem;
- unsigned int master_lcore_socket;
+ unsigned int main_lcore_socket;
struct rte_config *cfg = rte_eal_get_configuration();
bool skip;
@@ -1767,10 +1767,10 @@ memseg_primary_init_32(void)
skip = active_sockets != 0 &&
internal_conf->socket_mem[socket_id] == 0;
/* ...or if we didn't specifically request memory on *any*
- * socket, and this is not master lcore
+ * socket, and this is not main lcore
*/
- master_lcore_socket = rte_lcore_to_socket_id(cfg->master_lcore);
- skip |= active_sockets == 0 && socket_id != master_lcore_socket;
+ main_lcore_socket = rte_lcore_to_socket_id(cfg->main_lcore);
+ skip |= active_sockets == 0 && socket_id != main_lcore_socket;
if (skip) {
RTE_LOG(DEBUG, EAL, "Will not preallocate memory on socket %u\n",
diff --git a/lib/librte_eal/linux/eal_thread.c b/lib/librte_eal/linux/eal_thread.c
index 068de2559555..83c2034b93d5 100644
--- a/lib/librte_eal/linux/eal_thread.c
+++ b/lib/librte_eal/linux/eal_thread.c
@@ -26,35 +26,35 @@
#include "eal_thread.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
+rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned int worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
int rc = -EBUSY;
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
goto finish;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
+ n = write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = read(s2m, &c, 1);
+ n = read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -62,7 +62,7 @@ rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
rc = 0;
finish:
- rte_eal_trace_thread_remote_launch(f, arg, slave_id, rc);
+ rte_eal_trace_thread_remote_launch(f, arg, worker_id, rc);
return rc;
}
@@ -74,21 +74,21 @@ eal_thread_loop(__rte_unused void *arg)
int n, ret;
unsigned lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -104,7 +104,7 @@ eal_thread_loop(__rte_unused void *arg)
/* wait command */
do {
- n = read(m2s, &c, 1);
+ n = read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -115,7 +115,7 @@ eal_thread_loop(__rte_unused void *arg)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(s2m, &c, 1);
+ n = write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f56de02d8f6c..cd41167b2121 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -73,7 +73,7 @@ DPDK_21 {
rte_free;
rte_get_hpet_cycles;
rte_get_hpet_hz;
- rte_get_master_lcore;
+ rte_get_main_lcore;
rte_get_next_lcore;
rte_get_tsc_hz;
rte_hexdump;
diff --git a/lib/librte_eal/windows/eal.c b/lib/librte_eal/windows/eal.c
index 141f22adb7dc..6334aca03df2 100644
--- a/lib/librte_eal/windows/eal.c
+++ b/lib/librte_eal/windows/eal.c
@@ -355,8 +355,8 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
bscan = rte_bus_scan();
if (bscan < 0) {
@@ -365,16 +365,16 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (_pipe(lcore_config[i].pipe_master2slave,
+ if (_pipe(lcore_config[i].pipe_main2worker,
sizeof(char), _O_BINARY) < 0)
rte_panic("Cannot create pipe\n");
- if (_pipe(lcore_config[i].pipe_slave2master,
+ if (_pipe(lcore_config[i].pipe_worker2main,
sizeof(char), _O_BINARY) < 0)
rte_panic("Cannot create pipe\n");
@@ -399,10 +399,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
return fctret;
}
diff --git a/lib/librte_eal/windows/eal_thread.c b/lib/librte_eal/windows/eal_thread.c
index 20889b6196c9..908e726d16cc 100644
--- a/lib/librte_eal/windows/eal_thread.c
+++ b/lib/librte_eal/windows/eal_thread.c
@@ -17,34 +17,34 @@
#include "eal_windows.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned int slave_id)
+rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned int worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
return -EBUSY;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = _write(m2s, &c, 1);
+ n = _write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = _read(s2m, &c, 1);
+ n = _read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -61,21 +61,21 @@ eal_thread_loop(void *arg __rte_unused)
int n, ret;
unsigned int lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -88,7 +88,7 @@ eal_thread_loop(void *arg __rte_unused)
/* wait command */
do {
- n = _read(m2s, &c, 1);
+ n = _read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -99,7 +99,7 @@ eal_thread_loop(void *arg __rte_unused)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = _write(s2m, &c, 1);
+ n = _write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
--
2.27.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 13:07 0% ` Andrew Rybchenko
2020-10-15 13:57 0% ` Slava Ovsiienko
@ 2020-10-15 20:22 0% ` Slava Ovsiienko
1 sibling, 0 replies; 200+ results
From: Slava Ovsiienko @ 2020-10-15 20:22 UTC (permalink / raw)
To: Andrew Rybchenko, NBU-Contact-Thomas Monjalon, Ferruh Yigit,
Jerin Jacob, Andrew Rybchenko
Cc: dpdk-dev, Stephen Hemminger, Olivier Matz, Maxime Coquelin,
David Marchand
Hi,
Evening update:
- addressed code comments
- provided the union of segmentation description with dedicated feature structures according Jerin's proposal
- added the reporting of split limitation
With best regards, Slava
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Thursday, October 15, 2020 16:07
> To: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Cc: dpdk-dev <dev@dpdk.org>; Stephen Hemminger
> <stephen@networkplumber.org>; Olivier Matz <olivier.matz@6wind.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; David Marchand
> <david.marchand@redhat.com>
> Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
>
> On 10/15/20 3:49 PM, Thomas Monjalon wrote:
> > 15/10/2020 13:49, Slava Ovsiienko:
> >> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>> On 10/15/2020 12:26 PM, Jerin Jacob wrote:
> >>>
> >>> <...>
> >>>
> >>>>>>>> If we see some of the features of such kind or other PMDs
> >>>>>>>> adopts the split feature - we'll try to find the common root
> >>>>>>>> and consider the way how
> >>>>>> to report it.
> >>>>>>>
> >>>>>>> My only concern with that approach will be ABI break again if
> >>>>>>> something needs to exposed over rte_eth_dev_info().
> >>>>>
> >>>>> Let's reserve the pointer to struct rte_eth_rxseg_limitations in
> >>>>> the rte_eth_dev_info to avoid ABI break?
> >>>>
> >>>> Works for me. If we add an additional reserved field.
> >>>>
> >>>> Due to RC1 time constraint, I am OK to leave it as a reserved filed
> >>>> and fill meat when it is required if other ethdev maintainers are OK.
> >>>> I will be required for feature complete.
> >>>>
> >>>
> >>> Sounds good to me.
> >
> > OK for me.
>
> OK as well, but I dislike the idea with pointer in dev_info.
> It sounds like it breaks existing practice.
> We should either reserve enough space or simply add dedicated API call to
> report Rx seg capabilities.
>
> >
> >> OK, let's introduce the pointer in the rte_eth_dev_info and define
> >> struct rte_eth_rxseg_limitations as experimental.
> >> Will it be allowed to update this one later (after 20.11)?
> >> Is ABI break is allowed for the case?
> >
> > If it is experimental, you can change it at anytime.
> >
> > Ideally, we could try to have a first version of the limitations
> > during 20.11-rc2.
>
> Yes, please.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement
2020-10-15 18:07 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
@ 2020-10-15 18:27 4% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2020-10-15 18:27 UTC (permalink / raw)
To: Timothy McDaniel
Cc: Jerin Jacob, Mattias Rönnblom, Liang Ma, Peter Mccarthy,
Nipun Gupta, Pavan Nikhilesh, dpdk-dev, Erik Gabriel Carrillo,
Gage Eads, Van Haaren, Harry, Hemant Agrawal, Richardson, Bruce
On Thu, Oct 15, 2020 at 11:36 PM Timothy McDaniel
<timothy.mcdaniel@intel.com> wrote:
>
> The announcement made in 20.08 is no longer required.
>
> Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 13 -------------
Acked-by: Jerin Jacob <jerinj@marvell.com>
Series squashed and applied to dpdk-next-eventdev/for-main. Thanks.
> 1 file changed, 13 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index efd7710..08f1c04 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -189,19 +189,6 @@ Deprecation Notices
> ``rte_cryptodev_scheduler_worker_detach`` and
> ``rte_cryptodev_scheduler_workers_get`` accordingly.
>
> -* eventdev: Following structures will be modified to support DLB PMD
> - and future extensions:
> -
> - - ``rte_event_dev_info``
> - - ``rte_event_dev_config``
> - - ``rte_event_port_conf``
> -
> - Patches containing justification, documentation, and proposed modifications
> - can be found at:
> -
> - - https://patches.dpdk.org/patch/71457/
> - - https://patches.dpdk.org/patch/71456/
> -
> * sched: To allow more traffic classes, flexible mapping of pipe queues to
> traffic classes, and subport level configuration of pipes and queues
> changes will be made to macros, data structures and API functions defined
> --
> 2.6.4
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes
2020-10-15 18:07 9% ` [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-15 18:07 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-15 18:07 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
@ 2020-10-15 18:07 13% ` Timothy McDaniel
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 18:07 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
The eventdev ABI changes announced in 20.08 have been implemented
in 20.11. This commit announces the implementation of those changes, and
lists the data structures that were modified.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
---
doc/guides/rel_notes/release_20_11.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 7878e8e..0f8ee2a 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -352,6 +352,14 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+* ``eventdev`` changes
+
+ * Following structures are modified to support DLB/DLB2 PMDs
+ and future extensions:
+
+ * ``rte_event_dev_info``
+ * ``rte_event_dev_config``
+ * ``rte_event_port_conf``
Known Issues
------------
--
2.6.4
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement
2020-10-15 18:07 9% ` [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-15 18:07 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
@ 2020-10-15 18:07 4% ` Timothy McDaniel
2020-10-15 18:27 4% ` Jerin Jacob
2020-10-15 18:07 13% ` [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes Timothy McDaniel
2 siblings, 1 reply; 200+ results
From: Timothy McDaniel @ 2020-10-15 18:07 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
The announcement made in 20.08 is no longer required.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index efd7710..08f1c04 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -189,19 +189,6 @@ Deprecation Notices
``rte_cryptodev_scheduler_worker_detach`` and
``rte_cryptodev_scheduler_workers_get`` accordingly.
-* eventdev: Following structures will be modified to support DLB PMD
- and future extensions:
-
- - ``rte_event_dev_info``
- - ``rte_event_dev_config``
- - ``rte_event_port_conf``
-
- Patches containing justification, documentation, and proposed modifications
- can be found at:
-
- - https://patches.dpdk.org/patch/71457/
- - https://patches.dpdk.org/patch/71456/
-
* sched: To allow more traffic classes, flexible mapping of pipe queues to
traffic classes, and subport level configuration of pipes and queues
changes will be made to macros, data structures and API functions defined
--
2.6.4
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints
2020-10-15 18:07 9% ` [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
@ 2020-10-15 18:07 1% ` Timothy McDaniel
2020-10-15 18:07 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
2020-10-15 18:07 13% ` [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes Timothy McDaniel
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 18:07 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
This commit implements the eventdev ABI changes required by
the DLB/DLB2 PMDs. Several data structures and constants are modified
or added in this patch, thereby requiring modifications to the
dependent apps and examples.
The DLB/DLB2 hardware does not conform exactly to the eventdev interface.
1) It has a limit on the number of queues that may be linked to a port.
2) Some ports a further restricted to a maximum of 1 linked queue.
3) DLB does not have the ability to carry the flow_id as part
of the event (QE) payload. Note that the DLB2 hardware is capable of
carrying the flow_id.
Following is a detailed description of the changes that have been made.
1) Add new fields to the rte_event_dev_info struct. These fields allow
the device to advertize its capabilities so that applications can take
the appropriate actions based on those capabilities.
struct rte_event_dev_info {
uint32_t max_event_port_links;
/**< Maximum number of queues that can be linked to a single event
* port by this device.
*/
uint8_t max_single_link_event_port_queue_pairs;
/**< Maximum number of event ports and queues that are optimized for
* (and only capable of) single-link configurations supported by this
* device. These ports and queues are not accounted for in
* max_event_ports or max_event_queues.
*/
}
2) Add a new field to the rte_event_dev_config struct. This field allows
the application to specify how many of its ports are limited to a single
link, or will be used in single link mode.
/** Event device configuration structure */
struct rte_event_dev_config {
uint8_t nb_single_link_event_port_queues;
/**< Number of event ports and queues that will be singly-linked to
* each other. These are a subset of the overall event ports and
* queues; this value cannot exceed *nb_event_ports* or
* *nb_event_queues*. If the device has ports and queues that are
* optimized for single-link usage, this field is a hint for how many
* to allocate; otherwise, regular event ports and queues can be used.
*/
}
3) Replace the dedicated implicit_release_disabled field with a bit field
of explicit port capabilities. The implicit_release_disable functionality
is assigned to one bit, and a port-is-single-link-only attribute is
assigned to other, with the remaining bits available for future assignment.
* Event port configuration bitmap flags */
#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL (1ULL << 0)
/**< Configure the port not to release outstanding events in
* rte_event_dev_dequeue_burst(). If set, all events received through
* the port must be explicitly released with RTE_EVENT_OP_RELEASE or
* RTE_EVENT_OP_FORWARD. Must be unset if the device is not
* RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
*/
#define RTE_EVENT_PORT_CFG_SINGLE_LINK (1ULL << 1)
/**< This event port links only to a single event queue.
*
* @see rte_event_port_setup(), rte_event_port_link()
*/
#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
/**
* The implicit release disable attribute of the port
*/
struct rte_event_port_conf {
uint32_t event_port_cfg;
/**< Port cfg flags(EVENT_PORT_CFG_) */
}
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
app/test-eventdev/evt_common.h | 11 ++++
app/test-eventdev/test_order_atq.c | 28 +++++++---
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 +++++++---
app/test/test_eventdev.c | 4 +-
drivers/event/dpaa/dpaa_eventdev.c | 3 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
drivers/event/dsw/dsw_evdev.c | 3 +-
drivers/event/octeontx/ssovf_evdev.c | 5 +-
drivers/event/octeontx2/otx2_evdev.c | 3 +-
drivers/event/opdl/opdl_evdev.c | 3 +-
drivers/event/skeleton/skeleton_eventdev.c | 5 +-
drivers/event/sw/sw_evdev.c | 8 ++-
drivers/event/sw/sw_evdev_selftest.c | 6 +-
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +-
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++-
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +-
examples/l3fwd/l3fwd_event_generic.c | 7 ++-
examples/l3fwd/l3fwd_event_internal_port.c | 6 +-
lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/librte_eventdev/rte_eventdev.c | 65 +++++++++++++++++++---
lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++---
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
lib/librte_eventdev/rte_eventdev_trace.h | 7 ++-
lib/librte_eventdev/rte_eventdev_version.map | 4 +-
26 files changed, 213 insertions(+), 64 deletions(-)
diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
index f9d7378..a1da1cf 100644
--- a/app/test-eventdev/evt_common.h
+++ b/app/test-eventdev/evt_common.h
@@ -104,6 +104,16 @@ evt_has_all_types_queue(uint8_t dev_id)
true : false;
}
+static inline bool
+evt_has_flow_id(uint8_t dev_id)
+{
+ struct rte_event_dev_info dev_info;
+
+ rte_event_dev_info_get(dev_id, &dev_info);
+ return (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_CARRY_FLOW_ID) ?
+ true : false;
+}
+
static inline int
evt_service_setup(uint32_t service_id)
{
@@ -169,6 +179,7 @@ evt_configure_eventdev(struct evt_options *opt, uint8_t nb_queues,
.dequeue_timeout_ns = opt->deq_tmo_nsec,
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = info.max_num_events,
.nb_event_queue_flows = opt->nb_flows,
.nb_event_port_dequeue_depth =
diff --git a/app/test-eventdev/test_order_atq.c b/app/test-eventdev/test_order_atq.c
index 3366cfc..cfcb1dc 100644
--- a/app/test-eventdev/test_order_atq.c
+++ b/app/test-eventdev/test_order_atq.c
@@ -19,7 +19,7 @@ order_atq_process_stage_0(struct rte_event *const ev)
}
static int
-order_atq_worker(void *arg)
+order_atq_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_atq_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.sub_event_type == 0) { /* stage 0 from producer */
order_atq_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_atq_worker(void *arg)
}
static int
-order_atq_worker_burst(void *arg)
+order_atq_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,9 @@ order_atq_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].sub_event_type == 0) { /*stage 0 */
order_atq_process_stage_0(&ev[i]);
} else if (ev[i].sub_event_type == 1) { /* stage 1 */
@@ -95,11 +101,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_atq_worker_burst(arg);
- else
- return order_atq_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_atq_worker_burst(arg, true);
+ else
+ return order_atq_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_atq_worker(arg, true);
+ else
+ return order_atq_worker(arg, false);
+ }
}
static int
diff --git a/app/test-eventdev/test_order_common.c b/app/test-eventdev/test_order_common.c
index 4190f9a..7942390 100644
--- a/app/test-eventdev/test_order_common.c
+++ b/app/test-eventdev/test_order_common.c
@@ -49,6 +49,7 @@ order_producer(void *arg)
const uint32_t flow = (uintptr_t)m % nb_flows;
/* Maintain seq number per flow */
m->seqn = producer_flow_seq[flow]++;
+ m->udata64 = flow;
ev.flow_id = flow;
ev.mbuf = m;
diff --git a/app/test-eventdev/test_order_queue.c b/app/test-eventdev/test_order_queue.c
index 495efd9..1511c00 100644
--- a/app/test-eventdev/test_order_queue.c
+++ b/app/test-eventdev/test_order_queue.c
@@ -19,7 +19,7 @@ order_queue_process_stage_0(struct rte_event *const ev)
}
static int
-order_queue_worker(void *arg)
+order_queue_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_queue_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_queue_worker(void *arg)
}
static int
-order_queue_worker_burst(void *arg)
+order_queue_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,10 @@ order_queue_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev[i]);
} else if (ev[i].queue_id == 1) {/* from atomic queue */
@@ -95,11 +102,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_queue_worker_burst(arg);
- else
- return order_queue_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_queue_worker_burst(arg, true);
+ else
+ return order_queue_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_queue_worker(arg, true);
+ else
+ return order_queue_worker(arg, false);
+ }
}
static int
diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index 43ccb1c..62019c1 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -559,10 +559,10 @@ test_eventdev_port_setup(void)
if (!(info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
pconf.enqueue_depth = info.max_event_port_enqueue_depth;
- pconf.disable_implicit_release = 1;
+ pconf.event_port_cfg = RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
ret = rte_event_port_setup(TEST_DEV_ID, 0, &pconf);
TEST_ASSERT(ret == -EINVAL, "Expected -EINVAL, %d", ret);
- pconf.disable_implicit_release = 0;
+ pconf.event_port_cfg = 0;
}
ret = rte_event_port_setup(TEST_DEV_ID, info.max_event_ports,
diff --git a/drivers/event/dpaa/dpaa_eventdev.c b/drivers/event/dpaa/dpaa_eventdev.c
index b5ae87a..07cd079 100644
--- a/drivers/event/dpaa/dpaa_eventdev.c
+++ b/drivers/event/dpaa/dpaa_eventdev.c
@@ -355,7 +355,8 @@ dpaa_event_dev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED |
RTE_EVENT_DEV_CAP_BURST_MODE |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static int
diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c b/drivers/event/dpaa2/dpaa2_eventdev.c
index f7383ca..95f03c8 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev.c
+++ b/drivers/event/dpaa2/dpaa2_eventdev.c
@@ -406,7 +406,8 @@ dpaa2_eventdev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
RTE_EVENT_DEV_CAP_NONSEQ_MODE |
- RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES;
+ RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
@@ -536,7 +537,7 @@ dpaa2_eventdev_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
DPAA2_EVENT_MAX_PORT_DEQUEUE_DEPTH;
port_conf->enqueue_depth =
DPAA2_EVENT_MAX_PORT_ENQUEUE_DEPTH;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static int
diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
index e796975..933a5a5 100644
--- a/drivers/event/dsw/dsw_evdev.c
+++ b/drivers/event/dsw/dsw_evdev.c
@@ -224,7 +224,8 @@ dsw_info_get(struct rte_eventdev *dev __rte_unused,
.event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE|
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED|
RTE_EVENT_DEV_CAP_NONSEQ_MODE|
- RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT
+ RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT|
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID
};
}
diff --git a/drivers/event/octeontx/ssovf_evdev.c b/drivers/event/octeontx/ssovf_evdev.c
index 33cb502..6f242aa 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -152,7 +152,8 @@ ssovf_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *dev_info)
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
@@ -218,7 +219,7 @@ ssovf_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = edev->max_num_events;
port_conf->dequeue_depth = 1;
port_conf->enqueue_depth = 1;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static void
diff --git a/drivers/event/octeontx2/otx2_evdev.c b/drivers/event/octeontx2/otx2_evdev.c
index 256b6a5..b31c26e 100644
--- a/drivers/event/octeontx2/otx2_evdev.c
+++ b/drivers/event/octeontx2/otx2_evdev.c
@@ -501,7 +501,8 @@ otx2_sso_info_get(struct rte_eventdev *event_dev,
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static void
diff --git a/drivers/event/opdl/opdl_evdev.c b/drivers/event/opdl/opdl_evdev.c
index 9b2f75f..3050578 100644
--- a/drivers/event/opdl/opdl_evdev.c
+++ b/drivers/event/opdl/opdl_evdev.c
@@ -374,7 +374,8 @@ opdl_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
.max_event_port_dequeue_depth = MAX_OPDL_CONS_Q_DEPTH,
.max_event_port_enqueue_depth = MAX_OPDL_CONS_Q_DEPTH,
.max_num_events = OPDL_INFLIGHT_EVENTS_TOTAL,
- .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE,
+ .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID,
};
*info = evdev_opdl_info;
diff --git a/drivers/event/skeleton/skeleton_eventdev.c b/drivers/event/skeleton/skeleton_eventdev.c
index c889220..6fd1102 100644
--- a/drivers/event/skeleton/skeleton_eventdev.c
+++ b/drivers/event/skeleton/skeleton_eventdev.c
@@ -101,7 +101,8 @@ skeleton_eventdev_info_get(struct rte_eventdev *dev,
dev_info->max_num_events = (1ULL << 20);
dev_info->event_dev_cap = RTE_EVENT_DEV_CAP_QUEUE_QOS |
RTE_EVENT_DEV_CAP_BURST_MODE |
- RTE_EVENT_DEV_CAP_EVENT_QOS;
+ RTE_EVENT_DEV_CAP_EVENT_QOS |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static int
@@ -209,7 +210,7 @@ skeleton_eventdev_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = 32 * 1024;
port_conf->dequeue_depth = 16;
port_conf->enqueue_depth = 16;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static void
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index e310c8c..0d8013a 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -179,7 +179,8 @@ sw_port_setup(struct rte_eventdev *dev, uint8_t port_id,
}
p->inflight_max = conf->new_event_threshold;
- p->implicit_release = !conf->disable_implicit_release;
+ p->implicit_release = !(conf->event_port_cfg &
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
/* check if ring exists, same as rx_worker above */
snprintf(buf, sizeof(buf), "sw%d_p%u, %s", dev->data->dev_id,
@@ -501,7 +502,7 @@ sw_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = 1024;
port_conf->dequeue_depth = 16;
port_conf->enqueue_depth = 16;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static int
@@ -608,7 +609,8 @@ sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE),
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID),
};
*info = evdev_sw_info;
diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
index 38c21fa..4a7d823 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -172,7 +172,6 @@ create_ports(struct test *t, int num_ports)
.new_event_threshold = 1024,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (num_ports > MAX_PORTS)
return -1;
@@ -1227,7 +1226,6 @@ port_reconfig_credits(struct test *t)
.new_event_threshold = 128,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
printf("%d Error setting up port\n", __LINE__);
@@ -1317,7 +1315,6 @@ port_single_lb_reconfig(struct test *t)
.new_event_threshold = 128,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
printf("%d Error setting up port\n", __LINE__);
@@ -3079,7 +3076,8 @@ worker_loopback(struct test *t, uint8_t disable_implicit_release)
* only be initialized once - and this needs to be set for multiple runs
*/
conf.new_event_threshold = 512;
- conf.disable_implicit_release = disable_implicit_release;
+ conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (rte_event_port_setup(evdev, 0, &conf) < 0) {
printf("Error setting up RX port\n");
diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c b/examples/eventdev_pipeline/pipeline_worker_generic.c
index 42ff4ee..f70ab0c 100644
--- a/examples/eventdev_pipeline/pipeline_worker_generic.c
+++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
@@ -129,6 +129,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 1,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
@@ -143,7 +144,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
.schedule_type = cdata.queue_type,
.priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
.nb_atomic_flows = 1024,
- .nb_atomic_order_sequences = 1024,
+ .nb_atomic_order_sequences = 1024,
};
struct rte_event_queue_conf tx_q_conf = {
.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST,
@@ -167,7 +168,8 @@ setup_eventdev_generic(struct worker_data *worker_data)
disable_implicit_release = (dev_info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
- wkr_p_conf.disable_implicit_release = disable_implicit_release;
+ wkr_p_conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (dev_info.max_num_events < config.nb_events_limit)
config.nb_events_limit = dev_info.max_num_events;
diff --git a/examples/eventdev_pipeline/pipeline_worker_tx.c b/examples/eventdev_pipeline/pipeline_worker_tx.c
index 55bb2f7..ca6cd20 100644
--- a/examples/eventdev_pipeline/pipeline_worker_tx.c
+++ b/examples/eventdev_pipeline/pipeline_worker_tx.c
@@ -436,6 +436,7 @@ setup_eventdev_worker_tx_enq(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c b/examples/l2fwd-event/l2fwd_event_generic.c
index 2dc95e5..9a3167c 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -126,8 +126,11 @@ l2fwd_event_port_setup_generic(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c b/examples/l2fwd-event/l2fwd_event_internal_port.c
index 63d57b4..203a14c 100644
--- a/examples/l2fwd-event/l2fwd_event_internal_port.c
+++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
@@ -123,8 +123,10 @@ l2fwd_event_port_setup_internal_port(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
diff --git a/examples/l3fwd/l3fwd_event_generic.c b/examples/l3fwd/l3fwd_event_generic.c
index f8c9843..c80573f 100644
--- a/examples/l3fwd/l3fwd_event_generic.c
+++ b/examples/l3fwd/l3fwd_event_generic.c
@@ -115,8 +115,11 @@ l3fwd_event_port_setup_generic(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l3fwd/l3fwd_event_internal_port.c b/examples/l3fwd/l3fwd_event_internal_port.c
index 03ac581..9916a7f 100644
--- a/examples/l3fwd/l3fwd_event_internal_port.c
+++ b/examples/l3fwd/l3fwd_event_internal_port.c
@@ -113,8 +113,10 @@ l3fwd_event_port_setup_internal_port(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.c b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
index 86287b4..cc27bbc 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
@@ -286,7 +286,7 @@ txa_service_conf_cb(uint8_t __rte_unused id, uint8_t dev_id,
return ret;
}
- pc->disable_implicit_release = 0;
+ pc->event_port_cfg = 0;
ret = rte_event_port_setup(dev_id, port_id, pc);
if (ret) {
RTE_EDEV_LOG_ERR("failed to setup event port %u\n",
diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
index 557198f..322453c 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -438,9 +438,29 @@ rte_event_dev_configure(uint8_t dev_id,
dev_id);
return -EINVAL;
}
- if (dev_conf->nb_event_queues > info.max_event_queues) {
- RTE_EDEV_LOG_ERR("%d nb_event_queues=%d > max_event_queues=%d",
- dev_id, dev_conf->nb_event_queues, info.max_event_queues);
+ if (dev_conf->nb_event_queues > info.max_event_queues +
+ info.max_single_link_event_port_queue_pairs) {
+ RTE_EDEV_LOG_ERR("%d nb_event_queues=%d > max_event_queues=%d + max_single_link_event_port_queue_pairs=%d",
+ dev_id, dev_conf->nb_event_queues,
+ info.max_event_queues,
+ info.max_single_link_event_port_queue_pairs);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_event_queues -
+ dev_conf->nb_single_link_event_port_queues >
+ info.max_event_queues) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_queues=%d - nb_single_link_event_port_queues=%d > max_event_queues=%d",
+ dev_id, dev_conf->nb_event_queues,
+ dev_conf->nb_single_link_event_port_queues,
+ info.max_event_queues);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_single_link_event_port_queues >
+ dev_conf->nb_event_queues) {
+ RTE_EDEV_LOG_ERR("dev%d nb_single_link_event_port_queues=%d > nb_event_queues=%d",
+ dev_id,
+ dev_conf->nb_single_link_event_port_queues,
+ dev_conf->nb_event_queues);
return -EINVAL;
}
@@ -449,9 +469,31 @@ rte_event_dev_configure(uint8_t dev_id,
RTE_EDEV_LOG_ERR("dev%d nb_event_ports cannot be zero", dev_id);
return -EINVAL;
}
- if (dev_conf->nb_event_ports > info.max_event_ports) {
- RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d > max_event_ports= %d",
- dev_id, dev_conf->nb_event_ports, info.max_event_ports);
+ if (dev_conf->nb_event_ports > info.max_event_ports +
+ info.max_single_link_event_port_queue_pairs) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d > max_event_ports=%d + max_single_link_event_port_queue_pairs=%d",
+ dev_id, dev_conf->nb_event_ports,
+ info.max_event_ports,
+ info.max_single_link_event_port_queue_pairs);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_event_ports -
+ dev_conf->nb_single_link_event_port_queues
+ > info.max_event_ports) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d - nb_single_link_event_port_queues=%d > max_event_ports=%d",
+ dev_id, dev_conf->nb_event_ports,
+ dev_conf->nb_single_link_event_port_queues,
+ info.max_event_ports);
+ return -EINVAL;
+ }
+
+ if (dev_conf->nb_single_link_event_port_queues >
+ dev_conf->nb_event_ports) {
+ RTE_EDEV_LOG_ERR(
+ "dev%d nb_single_link_event_port_queues=%d > nb_event_ports=%d",
+ dev_id,
+ dev_conf->nb_single_link_event_port_queues,
+ dev_conf->nb_event_ports);
return -EINVAL;
}
@@ -738,7 +780,8 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
return -EINVAL;
}
- if (port_conf && port_conf->disable_implicit_release &&
+ if (port_conf &&
+ (port_conf->event_port_cfg & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL) &&
!(dev->data->event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
RTE_EDEV_LOG_ERR(
@@ -831,6 +874,14 @@ rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, uint32_t attr_id,
case RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD:
*attr_value = dev->data->ports_cfg[port_id].new_event_threshold;
break;
+ case RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE:
+ {
+ uint32_t config;
+
+ config = dev->data->ports_cfg[port_id].event_port_cfg;
+ *attr_value = !!(config & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
+ break;
+ }
default:
return -EINVAL;
};
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 7dc8323..ce1fc2c 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -291,6 +291,12 @@ struct rte_event;
* single queue to each port or map a single queue to many port.
*/
+#define RTE_EVENT_DEV_CAP_CARRY_FLOW_ID (1ULL << 9)
+/**< Event device preserves the flow ID from the enqueued
+ * event to the dequeued event if the flag is set. Otherwise,
+ * the content of this field is implementation dependent.
+ */
+
/* Event device priority levels */
#define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
/**< Highest priority expressed across eventdev subsystem
@@ -380,6 +386,10 @@ struct rte_event_dev_info {
* event port by this device.
* A device that does not support bulk enqueue will set this as 1.
*/
+ uint8_t max_event_port_links;
+ /**< Maximum number of queues that can be linked to a single event
+ * port by this device.
+ */
int32_t max_num_events;
/**< A *closed system* event dev has a limit on the number of events it
* can manage at a time. An *open system* event dev does not have a
@@ -387,6 +397,12 @@ struct rte_event_dev_info {
*/
uint32_t event_dev_cap;
/**< Event device capabilities(RTE_EVENT_DEV_CAP_)*/
+ uint8_t max_single_link_event_port_queue_pairs;
+ /**< Maximum number of event ports and queues that are optimized for
+ * (and only capable of) single-link configurations supported by this
+ * device. These ports and queues are not accounted for in
+ * max_event_ports or max_event_queues.
+ */
};
/**
@@ -494,6 +510,14 @@ struct rte_event_dev_config {
*/
uint32_t event_dev_cfg;
/**< Event device config flags(RTE_EVENT_DEV_CFG_)*/
+ uint8_t nb_single_link_event_port_queues;
+ /**< Number of event ports and queues that will be singly-linked to
+ * each other. These are a subset of the overall event ports and
+ * queues; this value cannot exceed *nb_event_ports* or
+ * *nb_event_queues*. If the device has ports and queues that are
+ * optimized for single-link usage, this field is a hint for how many
+ * to allocate; otherwise, regular event ports and queues can be used.
+ */
};
/**
@@ -519,7 +543,6 @@ int
rte_event_dev_configure(uint8_t dev_id,
const struct rte_event_dev_config *dev_conf);
-
/* Event queue specific APIs */
/* Event queue configuration bitmap flags */
@@ -671,6 +694,20 @@ rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
/* Event port specific APIs */
+/* Event port configuration bitmap flags */
+#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL (1ULL << 0)
+/**< Configure the port not to release outstanding events in
+ * rte_event_dev_dequeue_burst(). If set, all events received through
+ * the port must be explicitly released with RTE_EVENT_OP_RELEASE or
+ * RTE_EVENT_OP_FORWARD. Must be unset if the device is not
+ * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
+ */
+#define RTE_EVENT_PORT_CFG_SINGLE_LINK (1ULL << 1)
+/**< This event port links only to a single event queue.
+ *
+ * @see rte_event_port_setup(), rte_event_port_link()
+ */
+
/** Event port configuration structure */
struct rte_event_port_conf {
int32_t new_event_threshold;
@@ -698,13 +735,7 @@ struct rte_event_port_conf {
* which previously supplied to rte_event_dev_configure().
* Ignored when device is not RTE_EVENT_DEV_CAP_BURST_MODE capable.
*/
- uint8_t disable_implicit_release;
- /**< Configure the port not to release outstanding events in
- * rte_event_dev_dequeue_burst(). If true, all events received through
- * the port must be explicitly released with RTE_EVENT_OP_RELEASE or
- * RTE_EVENT_OP_FORWARD. Must be false when the device is not
- * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
- */
+ uint32_t event_port_cfg; /**< Port cfg flags(EVENT_PORT_CFG_) */
};
/**
@@ -769,6 +800,10 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
* The new event threshold of the port
*/
#define RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD 2
+/**
+ * The implicit release disable attribute of the port
+ */
+#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
/**
* Get an attribute from a port.
diff --git a/lib/librte_eventdev/rte_eventdev_pmd_pci.h b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
index 443cd38..a3f9244 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
@@ -88,7 +88,6 @@ rte_event_pmd_pci_probe(struct rte_pci_driver *pci_drv,
return -ENXIO;
}
-
/**
* @internal
* Wrapper for use by pci drivers as a .remove function to detach a event
diff --git a/lib/librte_eventdev/rte_eventdev_trace.h b/lib/librte_eventdev/rte_eventdev_trace.h
index 4de6341..5ec43d8 100644
--- a/lib/librte_eventdev/rte_eventdev_trace.h
+++ b/lib/librte_eventdev/rte_eventdev_trace.h
@@ -34,6 +34,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_u32(dev_conf->nb_event_port_dequeue_depth);
rte_trace_point_emit_u32(dev_conf->nb_event_port_enqueue_depth);
rte_trace_point_emit_u32(dev_conf->event_dev_cfg);
+ rte_trace_point_emit_u8(dev_conf->nb_single_link_event_port_queues);
rte_trace_point_emit_int(rc);
)
@@ -59,7 +60,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
rte_trace_point_emit_int(rc);
)
@@ -165,7 +166,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
rte_trace_point_emit_ptr(conf_cb);
rte_trace_point_emit_int(rc);
)
@@ -257,7 +258,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
)
RTE_TRACE_POINT(
diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
index 3d9d0ca..2846d04 100644
--- a/lib/librte_eventdev/rte_eventdev_version.map
+++ b/lib/librte_eventdev/rte_eventdev_version.map
@@ -100,7 +100,6 @@ EXPERIMENTAL {
# added in 20.05
__rte_eventdev_trace_configure;
__rte_eventdev_trace_queue_setup;
- __rte_eventdev_trace_port_setup;
__rte_eventdev_trace_port_link;
__rte_eventdev_trace_port_unlink;
__rte_eventdev_trace_start;
@@ -134,4 +133,7 @@ EXPERIMENTAL {
__rte_eventdev_trace_crypto_adapter_queue_pair_del;
__rte_eventdev_trace_crypto_adapter_start;
__rte_eventdev_trace_crypto_adapter_stop;
+
+ # changed in 20.11
+ __rte_eventdev_trace_port_setup;
};
--
2.6.4
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2
2020-10-14 21:36 9% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-15 17:31 9% ` [dpdk-dev] [PATCH 0/3] " Timothy McDaniel
@ 2020-10-15 18:07 9% ` Timothy McDaniel
2020-10-15 18:07 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 18:07 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
This series implements the eventdev ABI changes required by
the DLB and DLB2 PMDs. This ABI change was announced in the
20.08 release notes [1]. This patch was initially part of
the V1 DLB PMD patchset.
The DLB hardware does not conform exactly to the eventdev interface.
1) It has a limit on the number of queues that may be linked to a port.
2) Some ports are further restricted to a maximum of 1 linked queue.
3) It does not (currently) have the ability to carry the flow_id as part
of the event (QE) payload.
Due to the above, we would like to propose the following enhancements.
1) Add new fields to the rte_event_dev_info struct. These fields allow
the device to advertize its capabilities so that applications can take
the appropriate actions based on those capabilities.
2) Add a new field to the rte_event_dev_config struct. This field allows
the application to specify how many of its ports are limited to a single
link, or will be used in single link mode.
3) Replace the dedicated implicit_release_disabled field with a bit field
of explicit port capabilities. The implicit_release_disable functionality
is assigned to one bit, and a port-is-single-link-only attribute is
assigned to another, with the remaining bits available for future
assignment.
Major changes since V1:
Reworded commit message, as requested
Fixed errors reported by clang
Added blub to relnotes announcing the changes contained in this patch
Removed ABI deprecation announcement
Resolved patch apply issues when applying to eventdev-next
Combined ABI patch and app/examples patch to remove dependencies
Testing showed no performance impact due to the flow_id template code
added to test app.
[1] http://mails.dpdk.org/archives/dev/2020-August/177261.html
Timothy McDaniel (3):
eventdev: eventdev: express DLB/DLB2 PMD constraints
doc: remove eventdev ABI change announcement
doc: announce new eventdev ABI changes
app/test-eventdev/evt_common.h | 11 ++++
app/test-eventdev/test_order_atq.c | 28 +++++++---
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 +++++++---
app/test/test_eventdev.c | 4 +-
doc/guides/rel_notes/deprecation.rst | 13 -----
doc/guides/rel_notes/release_20_11.rst | 8 +++
drivers/event/dpaa/dpaa_eventdev.c | 3 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
drivers/event/dsw/dsw_evdev.c | 3 +-
drivers/event/octeontx/ssovf_evdev.c | 5 +-
drivers/event/octeontx2/otx2_evdev.c | 3 +-
drivers/event/opdl/opdl_evdev.c | 3 +-
drivers/event/skeleton/skeleton_eventdev.c | 5 +-
drivers/event/sw/sw_evdev.c | 8 ++-
drivers/event/sw/sw_evdev_selftest.c | 6 +-
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +-
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++-
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +-
examples/l3fwd/l3fwd_event_generic.c | 7 ++-
examples/l3fwd/l3fwd_event_internal_port.c | 6 +-
lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/librte_eventdev/rte_eventdev.c | 65 +++++++++++++++++++---
lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++---
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
lib/librte_eventdev/rte_eventdev_trace.h | 7 ++-
lib/librte_eventdev/rte_eventdev_version.map | 4 +-
28 files changed, 221 insertions(+), 77 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes
2020-10-15 17:31 9% ` [dpdk-dev] [PATCH 0/3] " Timothy McDaniel
2020-10-15 17:31 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-15 17:31 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
@ 2020-10-15 17:31 13% ` Timothy McDaniel
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 17:31 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
The eventdev ABI changes announced in 20.08 have been implemented
in 20.11. This commit announces the implementation of those changes, and
lists the data structures that were modified.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
---
doc/guides/rel_notes/release_20_11.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 7878e8e..0f8ee2a 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -352,6 +352,14 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+* ``eventdev`` changes
+
+ * Following structures are modified to support DLB/DLB2 PMDs
+ and future extensions:
+
+ * ``rte_event_dev_info``
+ * ``rte_event_dev_config``
+ * ``rte_event_port_conf``
Known Issues
------------
--
2.6.4
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints
2020-10-15 17:31 9% ` [dpdk-dev] [PATCH 0/3] " Timothy McDaniel
@ 2020-10-15 17:31 1% ` Timothy McDaniel
2020-10-15 17:31 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
2020-10-15 17:31 13% ` [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes Timothy McDaniel
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 17:31 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
This commit implements the eventdev ABI changes required by
the DLB/DLB2 PMDs. Several data structures and constants are modified
or added in this patch, thereby requiring modifications to the
dependent apps and examples.
The DLB/DLB2 hardware does not conform exactly to the eventdev interface.
1) It has a limit on the number of queues that may be linked to a port.
2) Some ports a further restricted to a maximum of 1 linked queue.
3) DLB does not have the ability to carry the flow_id as part
of the event (QE) payload. Note that the DLB2 hardware is capable of
carrying the flow_id.
Following is a detailed description of the changes that have been made.
1) Add new fields to the rte_event_dev_info struct. These fields allow
the device to advertize its capabilities so that applications can take
the appropriate actions based on those capabilities.
struct rte_event_dev_info {
uint32_t max_event_port_links;
/**< Maximum number of queues that can be linked to a single event
* port by this device.
*/
uint8_t max_single_link_event_port_queue_pairs;
/**< Maximum number of event ports and queues that are optimized for
* (and only capable of) single-link configurations supported by this
* device. These ports and queues are not accounted for in
* max_event_ports or max_event_queues.
*/
}
2) Add a new field to the rte_event_dev_config struct. This field allows the
application to specify how many of its ports are limited to a single link,
or will be used in single link mode.
/** Event device configuration structure */
struct rte_event_dev_config {
uint8_t nb_single_link_event_port_queues;
/**< Number of event ports and queues that will be singly-linked to
* each other. These are a subset of the overall event ports and
* queues; this value cannot exceed *nb_event_ports* or
* *nb_event_queues*. If the device has ports and queues that are
* optimized for single-link usage, this field is a hint for how many
* to allocate; otherwise, regular event ports and queues can be used.
*/
}
3) Replace the dedicated implicit_release_disabled field with a bit field
of explicit port capabilities. The implicit_release_disable functionality
is assiged to one bit, and a port-is-single-link-only attribute is
assigned to other, with the remaining bits available for future assignment.
* Event port configuration bitmap flags */
#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL (1ULL << 0)
/**< Configure the port not to release outstanding events in
* rte_event_dev_dequeue_burst(). If set, all events received through
* the port must be explicitly released with RTE_EVENT_OP_RELEASE or
* RTE_EVENT_OP_FORWARD. Must be unset if the device is not
* RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
*/
#define RTE_EVENT_PORT_CFG_SINGLE_LINK (1ULL << 1)
/**< This event port links only to a single event queue.
*
* @see rte_event_port_setup(), rte_event_port_link()
*/
#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
/**
* The implicit release disable attribute of the port
*/
struct rte_event_port_conf {
uint32_t event_port_cfg; /**< Port cfg flags(EVENT_PORT_CFG_) */
}
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
app/test-eventdev/evt_common.h | 11 ++++
app/test-eventdev/test_order_atq.c | 28 +++++++---
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 +++++++---
app/test/test_eventdev.c | 4 +-
drivers/event/dpaa/dpaa_eventdev.c | 3 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
drivers/event/dsw/dsw_evdev.c | 3 +-
drivers/event/octeontx/ssovf_evdev.c | 5 +-
drivers/event/octeontx2/otx2_evdev.c | 3 +-
drivers/event/opdl/opdl_evdev.c | 3 +-
drivers/event/skeleton/skeleton_eventdev.c | 5 +-
drivers/event/sw/sw_evdev.c | 8 ++-
drivers/event/sw/sw_evdev_selftest.c | 6 +-
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +-
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++-
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +-
examples/l3fwd/l3fwd_event_generic.c | 7 ++-
examples/l3fwd/l3fwd_event_internal_port.c | 6 +-
lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/librte_eventdev/rte_eventdev.c | 65 +++++++++++++++++++---
lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++---
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
lib/librte_eventdev/rte_eventdev_trace.h | 7 ++-
lib/librte_eventdev/rte_eventdev_version.map | 4 +-
26 files changed, 213 insertions(+), 64 deletions(-)
diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
index f9d7378..a1da1cf 100644
--- a/app/test-eventdev/evt_common.h
+++ b/app/test-eventdev/evt_common.h
@@ -104,6 +104,16 @@ evt_has_all_types_queue(uint8_t dev_id)
true : false;
}
+static inline bool
+evt_has_flow_id(uint8_t dev_id)
+{
+ struct rte_event_dev_info dev_info;
+
+ rte_event_dev_info_get(dev_id, &dev_info);
+ return (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_CARRY_FLOW_ID) ?
+ true : false;
+}
+
static inline int
evt_service_setup(uint32_t service_id)
{
@@ -169,6 +179,7 @@ evt_configure_eventdev(struct evt_options *opt, uint8_t nb_queues,
.dequeue_timeout_ns = opt->deq_tmo_nsec,
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = info.max_num_events,
.nb_event_queue_flows = opt->nb_flows,
.nb_event_port_dequeue_depth =
diff --git a/app/test-eventdev/test_order_atq.c b/app/test-eventdev/test_order_atq.c
index 3366cfc..cfcb1dc 100644
--- a/app/test-eventdev/test_order_atq.c
+++ b/app/test-eventdev/test_order_atq.c
@@ -19,7 +19,7 @@ order_atq_process_stage_0(struct rte_event *const ev)
}
static int
-order_atq_worker(void *arg)
+order_atq_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_atq_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.sub_event_type == 0) { /* stage 0 from producer */
order_atq_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_atq_worker(void *arg)
}
static int
-order_atq_worker_burst(void *arg)
+order_atq_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,9 @@ order_atq_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].sub_event_type == 0) { /*stage 0 */
order_atq_process_stage_0(&ev[i]);
} else if (ev[i].sub_event_type == 1) { /* stage 1 */
@@ -95,11 +101,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_atq_worker_burst(arg);
- else
- return order_atq_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_atq_worker_burst(arg, true);
+ else
+ return order_atq_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_atq_worker(arg, true);
+ else
+ return order_atq_worker(arg, false);
+ }
}
static int
diff --git a/app/test-eventdev/test_order_common.c b/app/test-eventdev/test_order_common.c
index 4190f9a..7942390 100644
--- a/app/test-eventdev/test_order_common.c
+++ b/app/test-eventdev/test_order_common.c
@@ -49,6 +49,7 @@ order_producer(void *arg)
const uint32_t flow = (uintptr_t)m % nb_flows;
/* Maintain seq number per flow */
m->seqn = producer_flow_seq[flow]++;
+ m->udata64 = flow;
ev.flow_id = flow;
ev.mbuf = m;
diff --git a/app/test-eventdev/test_order_queue.c b/app/test-eventdev/test_order_queue.c
index 495efd9..1511c00 100644
--- a/app/test-eventdev/test_order_queue.c
+++ b/app/test-eventdev/test_order_queue.c
@@ -19,7 +19,7 @@ order_queue_process_stage_0(struct rte_event *const ev)
}
static int
-order_queue_worker(void *arg)
+order_queue_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_queue_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_queue_worker(void *arg)
}
static int
-order_queue_worker_burst(void *arg)
+order_queue_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,10 @@ order_queue_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev[i]);
} else if (ev[i].queue_id == 1) {/* from atomic queue */
@@ -95,11 +102,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_queue_worker_burst(arg);
- else
- return order_queue_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_queue_worker_burst(arg, true);
+ else
+ return order_queue_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_queue_worker(arg, true);
+ else
+ return order_queue_worker(arg, false);
+ }
}
static int
diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index 43ccb1c..62019c1 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -559,10 +559,10 @@ test_eventdev_port_setup(void)
if (!(info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
pconf.enqueue_depth = info.max_event_port_enqueue_depth;
- pconf.disable_implicit_release = 1;
+ pconf.event_port_cfg = RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
ret = rte_event_port_setup(TEST_DEV_ID, 0, &pconf);
TEST_ASSERT(ret == -EINVAL, "Expected -EINVAL, %d", ret);
- pconf.disable_implicit_release = 0;
+ pconf.event_port_cfg = 0;
}
ret = rte_event_port_setup(TEST_DEV_ID, info.max_event_ports,
diff --git a/drivers/event/dpaa/dpaa_eventdev.c b/drivers/event/dpaa/dpaa_eventdev.c
index b5ae87a..07cd079 100644
--- a/drivers/event/dpaa/dpaa_eventdev.c
+++ b/drivers/event/dpaa/dpaa_eventdev.c
@@ -355,7 +355,8 @@ dpaa_event_dev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED |
RTE_EVENT_DEV_CAP_BURST_MODE |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static int
diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c b/drivers/event/dpaa2/dpaa2_eventdev.c
index f7383ca..95f03c8 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev.c
+++ b/drivers/event/dpaa2/dpaa2_eventdev.c
@@ -406,7 +406,8 @@ dpaa2_eventdev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
RTE_EVENT_DEV_CAP_NONSEQ_MODE |
- RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES;
+ RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
@@ -536,7 +537,7 @@ dpaa2_eventdev_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
DPAA2_EVENT_MAX_PORT_DEQUEUE_DEPTH;
port_conf->enqueue_depth =
DPAA2_EVENT_MAX_PORT_ENQUEUE_DEPTH;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static int
diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
index e796975..933a5a5 100644
--- a/drivers/event/dsw/dsw_evdev.c
+++ b/drivers/event/dsw/dsw_evdev.c
@@ -224,7 +224,8 @@ dsw_info_get(struct rte_eventdev *dev __rte_unused,
.event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE|
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED|
RTE_EVENT_DEV_CAP_NONSEQ_MODE|
- RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT
+ RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT|
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID
};
}
diff --git a/drivers/event/octeontx/ssovf_evdev.c b/drivers/event/octeontx/ssovf_evdev.c
index 33cb502..6f242aa 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -152,7 +152,8 @@ ssovf_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *dev_info)
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
@@ -218,7 +219,7 @@ ssovf_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = edev->max_num_events;
port_conf->dequeue_depth = 1;
port_conf->enqueue_depth = 1;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static void
diff --git a/drivers/event/octeontx2/otx2_evdev.c b/drivers/event/octeontx2/otx2_evdev.c
index 256b6a5..b31c26e 100644
--- a/drivers/event/octeontx2/otx2_evdev.c
+++ b/drivers/event/octeontx2/otx2_evdev.c
@@ -501,7 +501,8 @@ otx2_sso_info_get(struct rte_eventdev *event_dev,
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static void
diff --git a/drivers/event/opdl/opdl_evdev.c b/drivers/event/opdl/opdl_evdev.c
index 9b2f75f..3050578 100644
--- a/drivers/event/opdl/opdl_evdev.c
+++ b/drivers/event/opdl/opdl_evdev.c
@@ -374,7 +374,8 @@ opdl_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
.max_event_port_dequeue_depth = MAX_OPDL_CONS_Q_DEPTH,
.max_event_port_enqueue_depth = MAX_OPDL_CONS_Q_DEPTH,
.max_num_events = OPDL_INFLIGHT_EVENTS_TOTAL,
- .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE,
+ .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID,
};
*info = evdev_opdl_info;
diff --git a/drivers/event/skeleton/skeleton_eventdev.c b/drivers/event/skeleton/skeleton_eventdev.c
index c889220..6fd1102 100644
--- a/drivers/event/skeleton/skeleton_eventdev.c
+++ b/drivers/event/skeleton/skeleton_eventdev.c
@@ -101,7 +101,8 @@ skeleton_eventdev_info_get(struct rte_eventdev *dev,
dev_info->max_num_events = (1ULL << 20);
dev_info->event_dev_cap = RTE_EVENT_DEV_CAP_QUEUE_QOS |
RTE_EVENT_DEV_CAP_BURST_MODE |
- RTE_EVENT_DEV_CAP_EVENT_QOS;
+ RTE_EVENT_DEV_CAP_EVENT_QOS |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static int
@@ -209,7 +210,7 @@ skeleton_eventdev_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = 32 * 1024;
port_conf->dequeue_depth = 16;
port_conf->enqueue_depth = 16;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static void
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index e310c8c..0d8013a 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -179,7 +179,8 @@ sw_port_setup(struct rte_eventdev *dev, uint8_t port_id,
}
p->inflight_max = conf->new_event_threshold;
- p->implicit_release = !conf->disable_implicit_release;
+ p->implicit_release = !(conf->event_port_cfg &
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
/* check if ring exists, same as rx_worker above */
snprintf(buf, sizeof(buf), "sw%d_p%u, %s", dev->data->dev_id,
@@ -501,7 +502,7 @@ sw_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = 1024;
port_conf->dequeue_depth = 16;
port_conf->enqueue_depth = 16;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static int
@@ -608,7 +609,8 @@ sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE),
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID),
};
*info = evdev_sw_info;
diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
index 38c21fa..4a7d823 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -172,7 +172,6 @@ create_ports(struct test *t, int num_ports)
.new_event_threshold = 1024,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (num_ports > MAX_PORTS)
return -1;
@@ -1227,7 +1226,6 @@ port_reconfig_credits(struct test *t)
.new_event_threshold = 128,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
printf("%d Error setting up port\n", __LINE__);
@@ -1317,7 +1315,6 @@ port_single_lb_reconfig(struct test *t)
.new_event_threshold = 128,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
printf("%d Error setting up port\n", __LINE__);
@@ -3079,7 +3076,8 @@ worker_loopback(struct test *t, uint8_t disable_implicit_release)
* only be initialized once - and this needs to be set for multiple runs
*/
conf.new_event_threshold = 512;
- conf.disable_implicit_release = disable_implicit_release;
+ conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (rte_event_port_setup(evdev, 0, &conf) < 0) {
printf("Error setting up RX port\n");
diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c b/examples/eventdev_pipeline/pipeline_worker_generic.c
index 42ff4ee..f70ab0c 100644
--- a/examples/eventdev_pipeline/pipeline_worker_generic.c
+++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
@@ -129,6 +129,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 1,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
@@ -143,7 +144,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
.schedule_type = cdata.queue_type,
.priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
.nb_atomic_flows = 1024,
- .nb_atomic_order_sequences = 1024,
+ .nb_atomic_order_sequences = 1024,
};
struct rte_event_queue_conf tx_q_conf = {
.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST,
@@ -167,7 +168,8 @@ setup_eventdev_generic(struct worker_data *worker_data)
disable_implicit_release = (dev_info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
- wkr_p_conf.disable_implicit_release = disable_implicit_release;
+ wkr_p_conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (dev_info.max_num_events < config.nb_events_limit)
config.nb_events_limit = dev_info.max_num_events;
diff --git a/examples/eventdev_pipeline/pipeline_worker_tx.c b/examples/eventdev_pipeline/pipeline_worker_tx.c
index 55bb2f7..ca6cd20 100644
--- a/examples/eventdev_pipeline/pipeline_worker_tx.c
+++ b/examples/eventdev_pipeline/pipeline_worker_tx.c
@@ -436,6 +436,7 @@ setup_eventdev_worker_tx_enq(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c b/examples/l2fwd-event/l2fwd_event_generic.c
index 2dc95e5..9a3167c 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -126,8 +126,11 @@ l2fwd_event_port_setup_generic(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c b/examples/l2fwd-event/l2fwd_event_internal_port.c
index 63d57b4..203a14c 100644
--- a/examples/l2fwd-event/l2fwd_event_internal_port.c
+++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
@@ -123,8 +123,10 @@ l2fwd_event_port_setup_internal_port(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
diff --git a/examples/l3fwd/l3fwd_event_generic.c b/examples/l3fwd/l3fwd_event_generic.c
index f8c9843..c80573f 100644
--- a/examples/l3fwd/l3fwd_event_generic.c
+++ b/examples/l3fwd/l3fwd_event_generic.c
@@ -115,8 +115,11 @@ l3fwd_event_port_setup_generic(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l3fwd/l3fwd_event_internal_port.c b/examples/l3fwd/l3fwd_event_internal_port.c
index 03ac581..9916a7f 100644
--- a/examples/l3fwd/l3fwd_event_internal_port.c
+++ b/examples/l3fwd/l3fwd_event_internal_port.c
@@ -113,8 +113,10 @@ l3fwd_event_port_setup_internal_port(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.c b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
index 86287b4..cc27bbc 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
@@ -286,7 +286,7 @@ txa_service_conf_cb(uint8_t __rte_unused id, uint8_t dev_id,
return ret;
}
- pc->disable_implicit_release = 0;
+ pc->event_port_cfg = 0;
ret = rte_event_port_setup(dev_id, port_id, pc);
if (ret) {
RTE_EDEV_LOG_ERR("failed to setup event port %u\n",
diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
index 557198f..322453c 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -438,9 +438,29 @@ rte_event_dev_configure(uint8_t dev_id,
dev_id);
return -EINVAL;
}
- if (dev_conf->nb_event_queues > info.max_event_queues) {
- RTE_EDEV_LOG_ERR("%d nb_event_queues=%d > max_event_queues=%d",
- dev_id, dev_conf->nb_event_queues, info.max_event_queues);
+ if (dev_conf->nb_event_queues > info.max_event_queues +
+ info.max_single_link_event_port_queue_pairs) {
+ RTE_EDEV_LOG_ERR("%d nb_event_queues=%d > max_event_queues=%d + max_single_link_event_port_queue_pairs=%d",
+ dev_id, dev_conf->nb_event_queues,
+ info.max_event_queues,
+ info.max_single_link_event_port_queue_pairs);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_event_queues -
+ dev_conf->nb_single_link_event_port_queues >
+ info.max_event_queues) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_queues=%d - nb_single_link_event_port_queues=%d > max_event_queues=%d",
+ dev_id, dev_conf->nb_event_queues,
+ dev_conf->nb_single_link_event_port_queues,
+ info.max_event_queues);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_single_link_event_port_queues >
+ dev_conf->nb_event_queues) {
+ RTE_EDEV_LOG_ERR("dev%d nb_single_link_event_port_queues=%d > nb_event_queues=%d",
+ dev_id,
+ dev_conf->nb_single_link_event_port_queues,
+ dev_conf->nb_event_queues);
return -EINVAL;
}
@@ -449,9 +469,31 @@ rte_event_dev_configure(uint8_t dev_id,
RTE_EDEV_LOG_ERR("dev%d nb_event_ports cannot be zero", dev_id);
return -EINVAL;
}
- if (dev_conf->nb_event_ports > info.max_event_ports) {
- RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d > max_event_ports= %d",
- dev_id, dev_conf->nb_event_ports, info.max_event_ports);
+ if (dev_conf->nb_event_ports > info.max_event_ports +
+ info.max_single_link_event_port_queue_pairs) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d > max_event_ports=%d + max_single_link_event_port_queue_pairs=%d",
+ dev_id, dev_conf->nb_event_ports,
+ info.max_event_ports,
+ info.max_single_link_event_port_queue_pairs);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_event_ports -
+ dev_conf->nb_single_link_event_port_queues
+ > info.max_event_ports) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d - nb_single_link_event_port_queues=%d > max_event_ports=%d",
+ dev_id, dev_conf->nb_event_ports,
+ dev_conf->nb_single_link_event_port_queues,
+ info.max_event_ports);
+ return -EINVAL;
+ }
+
+ if (dev_conf->nb_single_link_event_port_queues >
+ dev_conf->nb_event_ports) {
+ RTE_EDEV_LOG_ERR(
+ "dev%d nb_single_link_event_port_queues=%d > nb_event_ports=%d",
+ dev_id,
+ dev_conf->nb_single_link_event_port_queues,
+ dev_conf->nb_event_ports);
return -EINVAL;
}
@@ -738,7 +780,8 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
return -EINVAL;
}
- if (port_conf && port_conf->disable_implicit_release &&
+ if (port_conf &&
+ (port_conf->event_port_cfg & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL) &&
!(dev->data->event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
RTE_EDEV_LOG_ERR(
@@ -831,6 +874,14 @@ rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, uint32_t attr_id,
case RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD:
*attr_value = dev->data->ports_cfg[port_id].new_event_threshold;
break;
+ case RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE:
+ {
+ uint32_t config;
+
+ config = dev->data->ports_cfg[port_id].event_port_cfg;
+ *attr_value = !!(config & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
+ break;
+ }
default:
return -EINVAL;
};
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 7dc8323..ce1fc2c 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -291,6 +291,12 @@ struct rte_event;
* single queue to each port or map a single queue to many port.
*/
+#define RTE_EVENT_DEV_CAP_CARRY_FLOW_ID (1ULL << 9)
+/**< Event device preserves the flow ID from the enqueued
+ * event to the dequeued event if the flag is set. Otherwise,
+ * the content of this field is implementation dependent.
+ */
+
/* Event device priority levels */
#define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
/**< Highest priority expressed across eventdev subsystem
@@ -380,6 +386,10 @@ struct rte_event_dev_info {
* event port by this device.
* A device that does not support bulk enqueue will set this as 1.
*/
+ uint8_t max_event_port_links;
+ /**< Maximum number of queues that can be linked to a single event
+ * port by this device.
+ */
int32_t max_num_events;
/**< A *closed system* event dev has a limit on the number of events it
* can manage at a time. An *open system* event dev does not have a
@@ -387,6 +397,12 @@ struct rte_event_dev_info {
*/
uint32_t event_dev_cap;
/**< Event device capabilities(RTE_EVENT_DEV_CAP_)*/
+ uint8_t max_single_link_event_port_queue_pairs;
+ /**< Maximum number of event ports and queues that are optimized for
+ * (and only capable of) single-link configurations supported by this
+ * device. These ports and queues are not accounted for in
+ * max_event_ports or max_event_queues.
+ */
};
/**
@@ -494,6 +510,14 @@ struct rte_event_dev_config {
*/
uint32_t event_dev_cfg;
/**< Event device config flags(RTE_EVENT_DEV_CFG_)*/
+ uint8_t nb_single_link_event_port_queues;
+ /**< Number of event ports and queues that will be singly-linked to
+ * each other. These are a subset of the overall event ports and
+ * queues; this value cannot exceed *nb_event_ports* or
+ * *nb_event_queues*. If the device has ports and queues that are
+ * optimized for single-link usage, this field is a hint for how many
+ * to allocate; otherwise, regular event ports and queues can be used.
+ */
};
/**
@@ -519,7 +543,6 @@ int
rte_event_dev_configure(uint8_t dev_id,
const struct rte_event_dev_config *dev_conf);
-
/* Event queue specific APIs */
/* Event queue configuration bitmap flags */
@@ -671,6 +694,20 @@ rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
/* Event port specific APIs */
+/* Event port configuration bitmap flags */
+#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL (1ULL << 0)
+/**< Configure the port not to release outstanding events in
+ * rte_event_dev_dequeue_burst(). If set, all events received through
+ * the port must be explicitly released with RTE_EVENT_OP_RELEASE or
+ * RTE_EVENT_OP_FORWARD. Must be unset if the device is not
+ * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
+ */
+#define RTE_EVENT_PORT_CFG_SINGLE_LINK (1ULL << 1)
+/**< This event port links only to a single event queue.
+ *
+ * @see rte_event_port_setup(), rte_event_port_link()
+ */
+
/** Event port configuration structure */
struct rte_event_port_conf {
int32_t new_event_threshold;
@@ -698,13 +735,7 @@ struct rte_event_port_conf {
* which previously supplied to rte_event_dev_configure().
* Ignored when device is not RTE_EVENT_DEV_CAP_BURST_MODE capable.
*/
- uint8_t disable_implicit_release;
- /**< Configure the port not to release outstanding events in
- * rte_event_dev_dequeue_burst(). If true, all events received through
- * the port must be explicitly released with RTE_EVENT_OP_RELEASE or
- * RTE_EVENT_OP_FORWARD. Must be false when the device is not
- * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
- */
+ uint32_t event_port_cfg; /**< Port cfg flags(EVENT_PORT_CFG_) */
};
/**
@@ -769,6 +800,10 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
* The new event threshold of the port
*/
#define RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD 2
+/**
+ * The implicit release disable attribute of the port
+ */
+#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
/**
* Get an attribute from a port.
diff --git a/lib/librte_eventdev/rte_eventdev_pmd_pci.h b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
index 443cd38..a3f9244 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
@@ -88,7 +88,6 @@ rte_event_pmd_pci_probe(struct rte_pci_driver *pci_drv,
return -ENXIO;
}
-
/**
* @internal
* Wrapper for use by pci drivers as a .remove function to detach a event
diff --git a/lib/librte_eventdev/rte_eventdev_trace.h b/lib/librte_eventdev/rte_eventdev_trace.h
index 4de6341..5ec43d8 100644
--- a/lib/librte_eventdev/rte_eventdev_trace.h
+++ b/lib/librte_eventdev/rte_eventdev_trace.h
@@ -34,6 +34,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_u32(dev_conf->nb_event_port_dequeue_depth);
rte_trace_point_emit_u32(dev_conf->nb_event_port_enqueue_depth);
rte_trace_point_emit_u32(dev_conf->event_dev_cfg);
+ rte_trace_point_emit_u8(dev_conf->nb_single_link_event_port_queues);
rte_trace_point_emit_int(rc);
)
@@ -59,7 +60,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
rte_trace_point_emit_int(rc);
)
@@ -165,7 +166,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
rte_trace_point_emit_ptr(conf_cb);
rte_trace_point_emit_int(rc);
)
@@ -257,7 +258,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
)
RTE_TRACE_POINT(
diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
index 3d9d0ca..2846d04 100644
--- a/lib/librte_eventdev/rte_eventdev_version.map
+++ b/lib/librte_eventdev/rte_eventdev_version.map
@@ -100,7 +100,6 @@ EXPERIMENTAL {
# added in 20.05
__rte_eventdev_trace_configure;
__rte_eventdev_trace_queue_setup;
- __rte_eventdev_trace_port_setup;
__rte_eventdev_trace_port_link;
__rte_eventdev_trace_port_unlink;
__rte_eventdev_trace_start;
@@ -134,4 +133,7 @@ EXPERIMENTAL {
__rte_eventdev_trace_crypto_adapter_queue_pair_del;
__rte_eventdev_trace_crypto_adapter_start;
__rte_eventdev_trace_crypto_adapter_stop;
+
+ # changed in 20.11
+ __rte_eventdev_trace_port_setup;
};
--
2.6.4
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement
2020-10-15 17:31 9% ` [dpdk-dev] [PATCH 0/3] " Timothy McDaniel
2020-10-15 17:31 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
@ 2020-10-15 17:31 4% ` Timothy McDaniel
2020-10-15 17:31 13% ` [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes Timothy McDaniel
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 17:31 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
The announcement made in 20.08 is no longer required.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index efd7710..08f1c04 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -189,19 +189,6 @@ Deprecation Notices
``rte_cryptodev_scheduler_worker_detach`` and
``rte_cryptodev_scheduler_workers_get`` accordingly.
-* eventdev: Following structures will be modified to support DLB PMD
- and future extensions:
-
- - ``rte_event_dev_info``
- - ``rte_event_dev_config``
- - ``rte_event_port_conf``
-
- Patches containing justification, documentation, and proposed modifications
- can be found at:
-
- - https://patches.dpdk.org/patch/71457/
- - https://patches.dpdk.org/patch/71456/
-
* sched: To allow more traffic classes, flexible mapping of pipe queues to
traffic classes, and subport level configuration of pipes and queues
changes will be made to macros, data structures and API functions defined
--
2.6.4
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2
2020-10-14 21:36 9% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
@ 2020-10-15 17:31 9% ` Timothy McDaniel
2020-10-15 17:31 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
` (2 more replies)
2020-10-15 18:07 9% ` [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2 siblings, 3 replies; 200+ results
From: Timothy McDaniel @ 2020-10-15 17:31 UTC (permalink / raw)
Cc: jerinj, mattias.ronnblom, liang.j.ma, peter.mccarthy,
nipun.gupta, pbhagavatula, dev, erik.g.carrillo, gage.eads,
harry.van.haaren, hemant.agrawal, bruce.richardson
This series implements the eventdev ABI changes required by
the DLB and DLB2 PMDs. This ABI change was announced in the
20.08 release notes [1]. This patch was initially part of
the V1 DLB PMD patchset.
The DLB hardware does not conform exactly to the eventdev interface.
1) It has a limit on the number of queues that may be linked to a port.
2) Some ports are further restricted to a maximum of 1 linked queue.
3) It does not (currently) have the ability to carry the flow_id as part
of the event (QE) payload.
Due to the above, we would like to propose the following enhancements.
1) Add new fields to the rte_event_dev_info struct. These fields allow
the device to advertise its capabilities so that applications can take
the appropriate actions based on those capabilities.
2) Add a new field to the rte_event_dev_config struct. This field allows
the application to specify how many of its ports are limited to a single
link, or will be used in single link mode.
3) Replace the dedicated implicit_release_disabled field with a bit field
of explicit port capabilities. The implicit_release_disable functionality
is assigned to one bit, and a port-is-single-link-only attribute is
assigned to another, with the remaining bits available for future
assignment.
Major changes since V1:
Reworded commit message, as requested
Fixed errors reported by clang
Added blub to relnotes announcing the changes contained in this patch
Removed ABI deprecation announcement
Resolved patch apply issues when applying to eventdev-next
Combined ABI patch and app/examples patch to remove bi-directional dependency
Testing showed no performance impact due to the flow_id template code
added to test app.
[1] http://mails.dpdk.org/archives/dev/2020-August/177261.html
Timothy McDaniel (3):
eventdev: eventdev: express DLB/DLB2 PMD constraints
doc: remove eventdev ABI change announcement
doc: announce new eventdev ABI changes
app/test-eventdev/evt_common.h | 11 ++++
app/test-eventdev/test_order_atq.c | 28 +++++++---
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 +++++++---
app/test/test_eventdev.c | 4 +-
doc/guides/rel_notes/deprecation.rst | 13 -----
doc/guides/rel_notes/release_20_11.rst | 8 +++
drivers/event/dpaa/dpaa_eventdev.c | 3 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
drivers/event/dsw/dsw_evdev.c | 3 +-
drivers/event/octeontx/ssovf_evdev.c | 5 +-
drivers/event/octeontx2/otx2_evdev.c | 3 +-
drivers/event/opdl/opdl_evdev.c | 3 +-
drivers/event/skeleton/skeleton_eventdev.c | 5 +-
drivers/event/sw/sw_evdev.c | 8 ++-
drivers/event/sw/sw_evdev_selftest.c | 6 +-
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +-
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++-
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +-
examples/l3fwd/l3fwd_event_generic.c | 7 ++-
examples/l3fwd/l3fwd_event_internal_port.c | 6 +-
lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/librte_eventdev/rte_eventdev.c | 65 +++++++++++++++++++---
lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++---
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
lib/librte_eventdev/rte_eventdev_trace.h | 7 ++-
lib/librte_eventdev/rte_eventdev_version.map | 4 +-
28 files changed, 221 insertions(+), 77 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v3 6/7] build: standardize component names and defines
2020-10-15 15:32 0% ` Luca Boccassi
@ 2020-10-15 15:34 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2020-10-15 15:34 UTC (permalink / raw)
To: Luca Boccassi; +Cc: dev, david.marchand, arybchenko, ferruh.yigit, thomas
On Thu, Oct 15, 2020 at 04:32:35PM +0100, Luca Boccassi wrote:
> On Thu, 2020-10-15 at 15:03 +0100, Bruce Richardson wrote:
> > On Thu, Oct 15, 2020 at 02:05:37PM +0100, Luca Boccassi wrote:
> > > On Thu, 2020-10-15 at 12:18 +0100, Bruce Richardson wrote:
> > > > On Thu, Oct 15, 2020 at 11:30:29AM +0100, Luca Boccassi wrote:
> > > > > On Wed, 2020-10-14 at 15:13 +0100, Bruce Richardson wrote:
> > > > > > As discussed on the dpdk-dev mailing list[1], we can make some easy
> > > > > > improvements in standardizing the naming of the various components in DPDK,
> > > > > > and their associated feature-enabled macros.
> > > > > >
> > > > > > Following this patch, each library will have the name in format,
> > > > > > 'librte_<name>.so', and the macro indicating that library is enabled in the
> > > > > > build will have the form 'RTE_LIB_<NAME>'.
> > > > > >
> > > > > > Similarly, for libraries, the equivalent name formats and macros are:
> > > > > > 'librte_<class>_<name>.so' and 'RTE_<CLASS>_<NAME>', where class is the
> > > > > > device type taken from the relevant driver subdirectory name, i.e. 'net',
> > > > > > 'crypto' etc.
> > > > > >
> > > > > > To avoid too many changes at once for end applications, the old macro names
> > > > > > will still be provided in the build in this release, but will be removed
> > > > > > subsequently.
> > > > > >
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > >
> > > > > > [1] http://inbox.dpdk.org/dev/ef7c1a87-79ab-e405-4202-39b7ad6b0c71@solarflare.com/t/#u
> > > > > > ---
> > > > > > app/test-bbdev/meson.build | 4 ++--
> > > > > > app/test-crypto-perf/meson.build | 2 +-
> > > > > > app/test-pmd/meson.build | 12 ++++++------
> > > > > > app/test/meson.build | 8 ++++----
> > > > > > doc/guides/rel_notes/deprecation.rst | 8 ++++++++
> > > > > > drivers/baseband/meson.build | 1 -
> > > > > > drivers/bus/meson.build | 1 -
> > > > > > drivers/common/meson.build | 1 -
> > > > > > drivers/common/mlx5/meson.build | 1 -
> > > > > > drivers/common/qat/meson.build | 1 -
> > > > > > drivers/compress/meson.build | 1 -
> > > > > > drivers/compress/octeontx/meson.build | 2 +-
> > > > > > drivers/crypto/meson.build | 1 -
> > > > > > drivers/crypto/null/meson.build | 2 +-
> > > > > > drivers/crypto/octeontx/meson.build | 2 +-
> > > > > > drivers/crypto/octeontx2/meson.build | 2 +-
> > > > > > drivers/crypto/scheduler/meson.build | 2 +-
> > > > > > drivers/crypto/virtio/meson.build | 2 +-
> > > > > > drivers/event/dpaa/meson.build | 2 +-
> > > > > > drivers/event/dpaa2/meson.build | 2 +-
> > > > > > drivers/event/meson.build | 1 -
> > > > > > drivers/event/octeontx/meson.build | 2 +-
> > > > > > drivers/event/octeontx2/meson.build | 2 +-
> > > > > > drivers/mempool/meson.build | 1 -
> > > > > > drivers/meson.build | 9 ++++-----
> > > > > > drivers/net/meson.build | 1 -
> > > > > > drivers/net/mlx4/meson.build | 2 +-
> > > > > > drivers/raw/ifpga/meson.build | 2 +-
> > > > > > drivers/raw/meson.build | 1 -
> > > > > > drivers/regex/meson.build | 1 -
> > > > > > drivers/vdpa/meson.build | 1 -
> > > > > > examples/bond/meson.build | 2 +-
> > > > > > examples/ethtool/meson.build | 2 +-
> > > > > > examples/ioat/meson.build | 2 +-
> > > > > > examples/l2fwd-crypto/meson.build | 2 +-
> > > > > > examples/ntb/meson.build | 2 +-
> > > > > > examples/vm_power_manager/meson.build | 6 +++---
> > > > > > lib/librte_ethdev/meson.build | 1 -
> > > > > > lib/librte_graph/meson.build | 2 --
> > > > > > lib/meson.build | 3 ++-
> > > > > > 40 files changed, 47 insertions(+), 55 deletions(-)
> > > > >
> > > > > Does this change the share object file names too, or only the macros?
> > > > >
> > > >
> > > > It does indeed change the object name files, which is a little bit
> > > > concerning. However, the consensus based on the RFC seemed to be that the
> > > > benefit is likely worth the change. If we want, we can look to use symlinks
> > > > to the old names on install, but I think that just delays the pain since I
> > > > would expect few to actually change their build to the new names until the
> > > > old ones and the symlinks completely go away.
> > > >
> > > > /Bruce
> > >
> > > It is a backward incompatible change, so we need to provide symlinks,
> > > right? On upgrade, programs linked to librte_old.so will fail to start.
> > > Or was this targeted at 20.11 thus piggy-backing on the ABI change
> > > which forces a re-link?
> > >
> > More of the latter, and the fact that changing the build system involved a
> > few library renames anyway for those using make. Since the ABI is changing
> > this release, and all the libs have a new major version number there is no
> > requirement for libs linked against an older version to work, and since
> > pkg-config should now be used for linking the actual names should not be
> > a concern.
> >
> > That's the thinking anyway. :-)
> >
> > /Bruce
>
> Ok that makes sense, I wasn't sure if this series was targeted for
> 20.11 or for later. In that case,
>
> Acked-by: Luca Boccassi <bluca@debian.org>
>
Yes, if it doesn't make 20.11 we'll have to re-evaluate and be stricter
with the compatibility constraints. It might not be worth doing post-20.11.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 6/7] build: standardize component names and defines
2020-10-15 14:03 3% ` Bruce Richardson
@ 2020-10-15 15:32 0% ` Luca Boccassi
2020-10-15 15:34 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2020-10-15 15:32 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, david.marchand, arybchenko, ferruh.yigit, thomas
On Thu, 2020-10-15 at 15:03 +0100, Bruce Richardson wrote:
> On Thu, Oct 15, 2020 at 02:05:37PM +0100, Luca Boccassi wrote:
> > On Thu, 2020-10-15 at 12:18 +0100, Bruce Richardson wrote:
> > > On Thu, Oct 15, 2020 at 11:30:29AM +0100, Luca Boccassi wrote:
> > > > On Wed, 2020-10-14 at 15:13 +0100, Bruce Richardson wrote:
> > > > > As discussed on the dpdk-dev mailing list[1], we can make some easy
> > > > > improvements in standardizing the naming of the various components in DPDK,
> > > > > and their associated feature-enabled macros.
> > > > >
> > > > > Following this patch, each library will have the name in format,
> > > > > 'librte_<name>.so', and the macro indicating that library is enabled in the
> > > > > build will have the form 'RTE_LIB_<NAME>'.
> > > > >
> > > > > Similarly, for libraries, the equivalent name formats and macros are:
> > > > > 'librte_<class>_<name>.so' and 'RTE_<CLASS>_<NAME>', where class is the
> > > > > device type taken from the relevant driver subdirectory name, i.e. 'net',
> > > > > 'crypto' etc.
> > > > >
> > > > > To avoid too many changes at once for end applications, the old macro names
> > > > > will still be provided in the build in this release, but will be removed
> > > > > subsequently.
> > > > >
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > >
> > > > > [1] http://inbox.dpdk.org/dev/ef7c1a87-79ab-e405-4202-39b7ad6b0c71@solarflare.com/t/#u
> > > > > ---
> > > > > app/test-bbdev/meson.build | 4 ++--
> > > > > app/test-crypto-perf/meson.build | 2 +-
> > > > > app/test-pmd/meson.build | 12 ++++++------
> > > > > app/test/meson.build | 8 ++++----
> > > > > doc/guides/rel_notes/deprecation.rst | 8 ++++++++
> > > > > drivers/baseband/meson.build | 1 -
> > > > > drivers/bus/meson.build | 1 -
> > > > > drivers/common/meson.build | 1 -
> > > > > drivers/common/mlx5/meson.build | 1 -
> > > > > drivers/common/qat/meson.build | 1 -
> > > > > drivers/compress/meson.build | 1 -
> > > > > drivers/compress/octeontx/meson.build | 2 +-
> > > > > drivers/crypto/meson.build | 1 -
> > > > > drivers/crypto/null/meson.build | 2 +-
> > > > > drivers/crypto/octeontx/meson.build | 2 +-
> > > > > drivers/crypto/octeontx2/meson.build | 2 +-
> > > > > drivers/crypto/scheduler/meson.build | 2 +-
> > > > > drivers/crypto/virtio/meson.build | 2 +-
> > > > > drivers/event/dpaa/meson.build | 2 +-
> > > > > drivers/event/dpaa2/meson.build | 2 +-
> > > > > drivers/event/meson.build | 1 -
> > > > > drivers/event/octeontx/meson.build | 2 +-
> > > > > drivers/event/octeontx2/meson.build | 2 +-
> > > > > drivers/mempool/meson.build | 1 -
> > > > > drivers/meson.build | 9 ++++-----
> > > > > drivers/net/meson.build | 1 -
> > > > > drivers/net/mlx4/meson.build | 2 +-
> > > > > drivers/raw/ifpga/meson.build | 2 +-
> > > > > drivers/raw/meson.build | 1 -
> > > > > drivers/regex/meson.build | 1 -
> > > > > drivers/vdpa/meson.build | 1 -
> > > > > examples/bond/meson.build | 2 +-
> > > > > examples/ethtool/meson.build | 2 +-
> > > > > examples/ioat/meson.build | 2 +-
> > > > > examples/l2fwd-crypto/meson.build | 2 +-
> > > > > examples/ntb/meson.build | 2 +-
> > > > > examples/vm_power_manager/meson.build | 6 +++---
> > > > > lib/librte_ethdev/meson.build | 1 -
> > > > > lib/librte_graph/meson.build | 2 --
> > > > > lib/meson.build | 3 ++-
> > > > > 40 files changed, 47 insertions(+), 55 deletions(-)
> > > >
> > > > Does this change the share object file names too, or only the macros?
> > > >
> > >
> > > It does indeed change the object name files, which is a little bit
> > > concerning. However, the consensus based on the RFC seemed to be that the
> > > benefit is likely worth the change. If we want, we can look to use symlinks
> > > to the old names on install, but I think that just delays the pain since I
> > > would expect few to actually change their build to the new names until the
> > > old ones and the symlinks completely go away.
> > >
> > > /Bruce
> >
> > It is a backward incompatible change, so we need to provide symlinks,
> > right? On upgrade, programs linked to librte_old.so will fail to start.
> > Or was this targeted at 20.11 thus piggy-backing on the ABI change
> > which forces a re-link?
> >
> More of the latter, and the fact that changing the build system involved a
> few library renames anyway for those using make. Since the ABI is changing
> this release, and all the libs have a new major version number there is no
> requirement for libs linked against an older version to work, and since
> pkg-config should now be used for linking the actual names should not be
> a concern.
>
> That's the thinking anyway. :-)
>
> /Bruce
Ok that makes sense, I wasn't sure if this series was targeted for
20.11 or for later. In that case,
Acked-by: Luca Boccassi <bluca@debian.org>
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 11:09 0% ` Andrew Rybchenko
@ 2020-10-15 14:39 0% ` Slava Ovsiienko
0 siblings, 0 replies; 200+ results
From: Slava Ovsiienko @ 2020-10-15 14:39 UTC (permalink / raw)
To: Andrew Rybchenko, Jerin Jacob
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
Hi, Andrew
> >> At least there are few simple limitations which are easy to
> >> express:
> >> 1. Maximum number of segments
> > We have scatter capability and we do not report the maximal number of
> > segments, it is on PMD own. We could add the field to the
> > rte_eth_dev_info, but not sure whether we have something special to report
> there even for mlx5 case.
>
> There is always a limitation in programming and HW. Nothing is unlimited.
> Limits could be high, but still exist.
> Number of descriptors? Width of field in HW interface?
> Maximum length of the config message to HW?
> All above could limit it directly or indirectly.
None of above is applicable to mlx5 buffer split feature - it just adjusts the Rx buffer pointers
and segment sizes, no anything beyond generic limitation - the queue descriptor numbers
and mbuf buffer size. Suppose the most of HW by other vendors is capable to support
buffer split feature with similar generic limitations.
>
> >> 2. Possibility to use the last segment many times if required
> >> (I was suggesting to use scatter for it, but you rejected
> >> the idea - may be time to reconsider :) )
> >
> > Mmm, sorry I do not follow, it might be I did not understand/missed your
> idea.
> > Some of the last segment attributes are used multiple times to scatter
> > the rest of the data in fashion very close to the existing scattering
> > approach - at least, pool and buffer size from this pool are used. The
> > beginning of the packet scattered according to the new descriptions,
> > the rest of the packet - according to the existing regular scattering
> > with pool settings from the last segment description.
>
> I believe that the possibility to split into a fixed segments
> (BUFFER_SPLIT) and possibility to use a mempool (just mp or last segment)
> many times if a packet does not fit (SCATTER) it is *different* features.
Sorry, what do you mean "use mempool many times"? Allocate multiple
mbufs from the same mempool and build the chain of them?
We have SCATTER offload and many PMDs advertise that.
Scattering is actually the split, the split happens on some well-defined points
to the mbufs from the same pool. BUFFER_SPLIT just extends SCATTER
capabilities by providing the split point arbitrary settings and multiple
pools.
> I can easily imagine HW which could do BUFFER_SPLIT to fixed segments, but
> cannot use the last segment many times (i.e. no classical SCATTER).
Sorry, what do you mean "BUFFER_SPLIT to fixed segments" ?
This new offload BUFFER_SPLIT is intended to push data to flexible segments,
potentially allocated from the different pools. The HW can be constrained
with pool number (say it supports some pool alloc/free hardware accelerator
for single pool only), in this case it will not be able to support BUFFER_SPLIT
in multiple pool config, but using the single pool does not arise the problem.
It seems I missed something, could you, please, provide an example,
how would you like to see the usage last segment many times for BUFFER_SPLIT?
How the packet should be split, in mbufs with what (last segment inherited) attributes?
>
> >
> > 3. Maximum offset
> >> Frankly speaking I'm not sure why it cannot be handled on
> >> PMD level (i.e. provide descriptors with offset taken into
> >> account or guarantee that HW mempool objects initialized
> >> correctly with required headroom). May be in some corner
> >> cases when the same HW mempool is shared by various
> >> segments with different offset requirements.
> >
> > HW offsets are beyond the feature scope, the offsets in the segment
> > description is supposed to be added to the native pool offsets (if any).
>
> Are you saying that offsets are not passed to HW and just handled by PMD to
> provide correct IOVA addresses to put data to? If so, it is an implementation
> detail which is specific to mlx5. If so, no specific limitations except data room,
> size and offset consistency.
> But it could be passed to a HW and it could be, for example, just 8 bits for the
> value.
Yes, it could. But there should be other vendors be involved, not known for now
who is going to support BUFFER_SPLIT and in which way. We should not invent
some theoretical limitations and merge the dead code. And, please note -
Tx segmentation has been living for 10 years successfully without any limitations,
no one cares about, there is no any request to report. Likewise is expected for Rx.
>
> >
> >> 4. Offset alignment
> >> 5. Maximum/minimum length of a segment 6. Length alignment
> > In which form? Mask of lsbs ? 0 means no limitations ?
>
> log2, i.e. 0 => 1 (no limitations) 1 => 2 (even only),
> 6 => 64 (64-byte cache line aligned) etc.
>
Yes, possible option.
> >
> >>
> >> I realize that 3, 4 and 5 could be per segment number.
> >> If it is really that complex, report common denominator which is
> >> guaranteed to work. If we have no checks on ethdev layer, application
> >> can ignore it if it knows better
> >
> > Currently it is not clear at all what kind of limitations should be
> > reported, we could include all of mentioned/proposed ones, and no one
> > will report there -
> > mlx5 has no any reasonable limitations to report for now.
> >
> > Should we reserve some pointer field in the rte_eth_dev_info to report
> > the limitations? (Limitation description should contain variable size
> > array, depending on the number of segments, so pointer seems to be
> appropriate).
> > It would allow us to avoid ABI break, and present the limitation structure
> once it is defined.
>
> I will let other ethdev maintainers to make a decision here.
> My vote would be to report limitations mentioned above.
> It looks like Jerin is also interested in limitations reporting. Not sure if my form
> looks OK or no.
For now I tend to think we could reserve some pointer for BUFFER_SPLIT limitations and that's it.
Reporting some silly generic limitations from mlx5 means introducing the dead code in my opinion.
If we'll see the actual request from applications to check and handle limitations (actually applications
are very limited in this matter - they expect the split point to be set at very strong defined place
of the packet format).
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2
2020-10-15 14:26 7% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Jerin Jacob
@ 2020-10-15 14:38 4% ` McDaniel, Timothy
0 siblings, 0 replies; 200+ results
From: McDaniel, Timothy @ 2020-10-15 14:38 UTC (permalink / raw)
To: Jerin Jacob
Cc: dpdk-dev, Carrillo, Erik G, Eads, Gage, Van Haaren, Harry,
Hemant Agrawal
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, October 15, 2020 9:26 AM
> To: McDaniel, Timothy <timothy.mcdaniel@intel.com>
> Cc: dpdk-dev <dev@dpdk.org>; Carrillo, Erik G <erik.g.carrillo@intel.com>; Eads,
> Gage <gage.eads@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; Hemant Agrawal <hemant.agrawal@nxp.com>
> Subject: Re: [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2
>
> On Thu, Oct 15, 2020 at 3:04 AM Timothy McDaniel
> <timothy.mcdaniel@intel.com> wrote:
> >
> > This series implements the eventdev ABI changes required by
> > the DLB and DLB2 PMDs. This ABI change was announced in the
> > 20.08 release notes [1]. This patch was initially part of
> > the V1 DLB PMD patchset.
>
> Hi @McDaniel, Timothy ,
>
> Following things missing in this patch set before it needs to merge:
> - Update doc/guides/rel_notes/release_20_11.rst for "API Changes"
> and/or "ABI Changes" section
> - Update doc/guides/rel_notes/deprecation.rst to remove the this patch
> specific depreciation note
> - Merge patch 1 and 2 to a single patch it has a compilation error if
> we build patch1 alone
> - Update the git commit to give more data on the combined patch.
> - rebase the patch to http://browse.dpdk.org/next/dpdk-next-eventdev/,
> it still git-am apply issues.
>
> After fixing the above, I will merge this RC1. Please send ASAP.
>
I will get on this straight away. Thanks.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2
2020-10-14 21:36 9% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-14 21:36 2% ` [dpdk-dev] [PATCH 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-14 21:36 6% ` [dpdk-dev] [PATCH 2/2] eventdev: update app and examples for new eventdev ABI Timothy McDaniel
@ 2020-10-15 14:26 7% ` Jerin Jacob
2020-10-15 14:38 4% ` McDaniel, Timothy
2 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2020-10-15 14:26 UTC (permalink / raw)
To: Timothy McDaniel
Cc: dpdk-dev, Erik Gabriel Carrillo, Gage Eads, Van Haaren, Harry,
Hemant Agrawal
On Thu, Oct 15, 2020 at 3:04 AM Timothy McDaniel
<timothy.mcdaniel@intel.com> wrote:
>
> This series implements the eventdev ABI changes required by
> the DLB and DLB2 PMDs. This ABI change was announced in the
> 20.08 release notes [1]. This patch was initially part of
> the V1 DLB PMD patchset.
Hi @McDaniel, Timothy ,
Following things missing in this patch set before it needs to merge:
- Update doc/guides/rel_notes/release_20_11.rst for "API Changes"
and/or "ABI Changes" section
- Update doc/guides/rel_notes/deprecation.rst to remove the this patch
specific depreciation note
- Merge patch 1 and 2 to a single patch it has a compilation error if
we build patch1 alone
- Update the git commit to give more data on the combined patch.
- rebase the patch to http://browse.dpdk.org/next/dpdk-next-eventdev/,
it still git-am apply issues.
After fixing the above, I will merge this RC1. Please send ASAP.
>
> The DLB hardware does not conform exactly to the eventdev interface.
> 1) It has a limit on the number of queues that may be linked to a port.
> 2) Some ports are further restricted to a maximum of 1 linked queue.
> 3) It does not (currently) have the ability to carry the flow_id as part
> of the event (QE) payload.
>
> Due to the above, we would like to propose the following enhancements.
>
> 1) Add new fields to the rte_event_dev_info struct. These fields allow
> the device to advertise its capabilities so that applications can take
> the appropriate actions based on those capabilities.
>
> 2) Add a new field to the rte_event_dev_config struct. This field allows
> the application to specify how many of its ports are limited to a single
> link, or will be used in single link mode.
>
> 3) Replace the dedicated implicit_release_disabled field with a bit field
> of explicit port capabilities. The implicit_release_disable functionality
> is assigned to one bit, and a port-is-single-link-only attribute is
> assigned to another, with the remaining bits available for future
> assignment.
>
> Note that it was requested that we split this app/test
> changes out from the eventdev ABI patch. As a result,
> neither of these patches will build without the other
> also being applied.
>
> Major changes since V1:
> Reworded commit message, as requested
> Fixed errors reported by clang
>
> Testing showed no performance impact due to the flow_id template code
> added to test app.
>
> [1] http://mails.dpdk.org/archives/dev/2020-August/177261.html
>
>
> Timothy McDaniel (2):
> eventdev: eventdev: express DLB/DLB2 PMD constraints
> eventdev: update app and examples for new eventdev ABI
>
>
>
> Timothy McDaniel (2):
> eventdev: eventdev: express DLB/DLB2 PMD constraints
> eventdev: update app and examples for new eventdev ABI
>
> app/test-eventdev/evt_common.h | 11 ++++
> app/test-eventdev/test_order_atq.c | 28 ++++++---
> app/test-eventdev/test_order_common.c | 1 +
> app/test-eventdev/test_order_queue.c | 29 +++++++---
> app/test/test_eventdev.c | 4 +-
> drivers/event/dpaa/dpaa_eventdev.c | 3 +-
> drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
> drivers/event/dsw/dsw_evdev.c | 3 +-
> drivers/event/octeontx/ssovf_evdev.c | 5 +-
> drivers/event/octeontx2/otx2_evdev.c | 3 +-
> drivers/event/opdl/opdl_evdev.c | 3 +-
> drivers/event/skeleton/skeleton_eventdev.c | 5 +-
> drivers/event/sw/sw_evdev.c | 8 ++-
> drivers/event/sw/sw_evdev_selftest.c | 6 +-
> .../eventdev_pipeline/pipeline_worker_generic.c | 6 +-
> examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
> examples/l2fwd-event/l2fwd_event_generic.c | 7 ++-
> examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +-
> examples/l3fwd/l3fwd_event_generic.c | 7 ++-
> examples/l3fwd/l3fwd_event_internal_port.c | 6 +-
> lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
> lib/librte_eventdev/rte_eventdev.c | 66 +++++++++++++++++++---
> lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++---
> lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
> lib/librte_eventdev/rte_eventdev_trace.h | 7 ++-
> lib/librte_eventdev/rte_eventdev_version.map | 4 +-
> 26 files changed, 214 insertions(+), 64 deletions(-)
>
> --
> 2.6.4
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v3 6/7] build: standardize component names and defines
2020-10-15 13:05 3% ` Luca Boccassi
@ 2020-10-15 14:03 3% ` Bruce Richardson
2020-10-15 15:32 0% ` Luca Boccassi
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2020-10-15 14:03 UTC (permalink / raw)
To: Luca Boccassi; +Cc: dev, david.marchand, arybchenko, ferruh.yigit, thomas
On Thu, Oct 15, 2020 at 02:05:37PM +0100, Luca Boccassi wrote:
> On Thu, 2020-10-15 at 12:18 +0100, Bruce Richardson wrote:
> > On Thu, Oct 15, 2020 at 11:30:29AM +0100, Luca Boccassi wrote:
> > > On Wed, 2020-10-14 at 15:13 +0100, Bruce Richardson wrote:
> > > > As discussed on the dpdk-dev mailing list[1], we can make some easy
> > > > improvements in standardizing the naming of the various components in DPDK,
> > > > and their associated feature-enabled macros.
> > > >
> > > > Following this patch, each library will have the name in format,
> > > > 'librte_<name>.so', and the macro indicating that library is enabled in the
> > > > build will have the form 'RTE_LIB_<NAME>'.
> > > >
> > > > Similarly, for libraries, the equivalent name formats and macros are:
> > > > 'librte_<class>_<name>.so' and 'RTE_<CLASS>_<NAME>', where class is the
> > > > device type taken from the relevant driver subdirectory name, i.e. 'net',
> > > > 'crypto' etc.
> > > >
> > > > To avoid too many changes at once for end applications, the old macro names
> > > > will still be provided in the build in this release, but will be removed
> > > > subsequently.
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > >
> > > > [1] http://inbox.dpdk.org/dev/ef7c1a87-79ab-e405-4202-39b7ad6b0c71@solarflare.com/t/#u
> > > > ---
> > > > app/test-bbdev/meson.build | 4 ++--
> > > > app/test-crypto-perf/meson.build | 2 +-
> > > > app/test-pmd/meson.build | 12 ++++++------
> > > > app/test/meson.build | 8 ++++----
> > > > doc/guides/rel_notes/deprecation.rst | 8 ++++++++
> > > > drivers/baseband/meson.build | 1 -
> > > > drivers/bus/meson.build | 1 -
> > > > drivers/common/meson.build | 1 -
> > > > drivers/common/mlx5/meson.build | 1 -
> > > > drivers/common/qat/meson.build | 1 -
> > > > drivers/compress/meson.build | 1 -
> > > > drivers/compress/octeontx/meson.build | 2 +-
> > > > drivers/crypto/meson.build | 1 -
> > > > drivers/crypto/null/meson.build | 2 +-
> > > > drivers/crypto/octeontx/meson.build | 2 +-
> > > > drivers/crypto/octeontx2/meson.build | 2 +-
> > > > drivers/crypto/scheduler/meson.build | 2 +-
> > > > drivers/crypto/virtio/meson.build | 2 +-
> > > > drivers/event/dpaa/meson.build | 2 +-
> > > > drivers/event/dpaa2/meson.build | 2 +-
> > > > drivers/event/meson.build | 1 -
> > > > drivers/event/octeontx/meson.build | 2 +-
> > > > drivers/event/octeontx2/meson.build | 2 +-
> > > > drivers/mempool/meson.build | 1 -
> > > > drivers/meson.build | 9 ++++-----
> > > > drivers/net/meson.build | 1 -
> > > > drivers/net/mlx4/meson.build | 2 +-
> > > > drivers/raw/ifpga/meson.build | 2 +-
> > > > drivers/raw/meson.build | 1 -
> > > > drivers/regex/meson.build | 1 -
> > > > drivers/vdpa/meson.build | 1 -
> > > > examples/bond/meson.build | 2 +-
> > > > examples/ethtool/meson.build | 2 +-
> > > > examples/ioat/meson.build | 2 +-
> > > > examples/l2fwd-crypto/meson.build | 2 +-
> > > > examples/ntb/meson.build | 2 +-
> > > > examples/vm_power_manager/meson.build | 6 +++---
> > > > lib/librte_ethdev/meson.build | 1 -
> > > > lib/librte_graph/meson.build | 2 --
> > > > lib/meson.build | 3 ++-
> > > > 40 files changed, 47 insertions(+), 55 deletions(-)
> > >
> > > Does this change the share object file names too, or only the macros?
> > >
> >
> > It does indeed change the object name files, which is a little bit
> > concerning. However, the consensus based on the RFC seemed to be that the
> > benefit is likely worth the change. If we want, we can look to use symlinks
> > to the old names on install, but I think that just delays the pain since I
> > would expect few to actually change their build to the new names until the
> > old ones and the symlinks completely go away.
> >
> > /Bruce
>
> It is a backward incompatible change, so we need to provide symlinks,
> right? On upgrade, programs linked to librte_old.so will fail to start.
> Or was this targeted at 20.11 thus piggy-backing on the ABI change
> which forces a re-link?
>
More of the latter, and the fact that changing the build system involved a
few library renames anyway for those using make. Since the ABI is changing
this release, and all the libs have a new major version number there is no
requirement for libs linked against an older version to work, and since
pkg-config should now be used for linking the actual names should not be
a concern.
That's the thinking anyway. :-)
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 13:07 0% ` Andrew Rybchenko
@ 2020-10-15 13:57 0% ` Slava Ovsiienko
2020-10-15 20:22 0% ` Slava Ovsiienko
1 sibling, 0 replies; 200+ results
From: Slava Ovsiienko @ 2020-10-15 13:57 UTC (permalink / raw)
To: Andrew Rybchenko, NBU-Contact-Thomas Monjalon, Ferruh Yigit,
Jerin Jacob, Andrew Rybchenko
Cc: dpdk-dev, Stephen Hemminger, Olivier Matz, Maxime Coquelin,
David Marchand
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Thursday, October 15, 2020 16:07
> To: NBU-Contact-Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Cc: dpdk-dev <dev@dpdk.org>; Stephen Hemminger
> <stephen@networkplumber.org>; Olivier Matz <olivier.matz@6wind.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; David Marchand
> <david.marchand@redhat.com>
> Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
>
> On 10/15/20 3:49 PM, Thomas Monjalon wrote:
> > 15/10/2020 13:49, Slava Ovsiienko:
> >> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >>> On 10/15/2020 12:26 PM, Jerin Jacob wrote:
> >>>
> >>> <...>
> >>>
> >>>>>>>> If we see some of the features of such kind or other PMDs
> >>>>>>>> adopts the split feature - we'll try to find the common root
> >>>>>>>> and consider the way how
> >>>>>> to report it.
> >>>>>>>
> >>>>>>> My only concern with that approach will be ABI break again if
> >>>>>>> something needs to exposed over rte_eth_dev_info().
> >>>>>
> >>>>> Let's reserve the pointer to struct rte_eth_rxseg_limitations in
> >>>>> the rte_eth_dev_info to avoid ABI break?
> >>>>
> >>>> Works for me. If we add an additional reserved field.
> >>>>
> >>>> Due to RC1 time constraint, I am OK to leave it as a reserved filed
> >>>> and fill meat when it is required if other ethdev maintainers are OK.
> >>>> I will be required for feature complete.
> >>>>
> >>>
> >>> Sounds good to me.
> >
> > OK for me.
>
> OK as well, but I dislike the idea with pointer in dev_info.
> It sounds like it breaks existing practice.
Moreover, if we are going to have multiple features using Rx segmentation
we should provide multiple structures with limitations - at least, one per feature.
> We should either reserve enough space or simply add dedicated API call to
> report Rx seg capabilities.
>
It seems we are trying to embrace everything in very generic way 😊
Just curious - how did we managed to survive without limitations on Tx direction?
No one told us how many segments PMD supports on Tx, what is the limitations
for offsets and alignments, it seems there is no limits for tx segment size at all.
How could it happen? Tx limitations do not exist? Just no one cared about the Tx limitations?
As for Rx limitations - there are no reasonable ones for now. We'll invent
the way to report the limitations (and it seems to be unbalanced - we should provide
the same to Tx), the next step is to provide at least one PMD using that,
and in this way to make mlx5 PMD to report silly values - "I have no reasonable
limitations beyond meaningful buffer size under pool_buf_size/UINT16_MAX)".
IMO, If some HW does not support arbitrary split (suppose, it is not common case,
most of HW is very flexible about specifying Rx buffers) the BUFFER_SPLIT feature
should not be advertised at all, because it would be not very useful - application
is intended to work over specific protocol, it knows where it wants to set split point
(defined by packet format). Hence, application is not so interested about offsets,
alignments, etc - it just checks whether PMD provides requested split points or not.
That's why just simple documenting was initially intended, there are just no
a lot of limitations expected, likewise Tx direction shows that.
Yes, generally speaking, there are no doubts it would be nice to report the limitations, but:
- not expected to have many (documenting can the few exceptions)
- no nice way is found how to report - pointer? API?
- complicated to present for various features (variable size array, multiple features)
- not known which limitations are actually needed, just some theoretical ones
So, we see the large white area, should we invent something not well-defined to cover one,
or let's wait for actual request to check limitations that can't be handled by documenting
and internal PMD checking/validation?
With best regards, Slava
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int
@ 2020-10-15 13:30 4% ` Andrew Rybchenko
2020-10-16 9:22 0% ` Ferruh Yigit
2020-10-16 11:20 3% ` Kinsella, Ray
0 siblings, 2 replies; 200+ results
From: Andrew Rybchenko @ 2020-10-15 13:30 UTC (permalink / raw)
To: Ray Kinsella, Neil Horman, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko
Cc: dev, Ivan Ilchenko
From: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
Change rte_eth_dev_stop() return value from void to int
and return negative errno values in case of error conditions.
Also update the usage of the function in ethdev according to
the new return type.
Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/deprecation.rst | 1 -
doc/guides/rel_notes/release_20_11.rst | 3 +++
lib/librte_ethdev/rte_ethdev.c | 27 +++++++++++++++++++-------
lib/librte_ethdev/rte_ethdev.h | 5 ++++-
4 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d1f5ed39db..2e04e24374 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -127,7 +127,6 @@ Deprecation Notices
negative errno values to indicate various error conditions (e.g.
invalid port ID, unsupported operation, failed operation):
- - ``rte_eth_dev_stop``
- ``rte_eth_dev_close``
* ethdev: New offload flags ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11.
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index f8686a50db..c8c30937fa 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -355,6 +355,9 @@ API Changes
* vhost: Add a new function ``rte_vhost_crypto_driver_start`` to be called
instead of ``rte_vhost_driver_start`` by crypto applications.
+* ethdev: changed ``rte_eth_dev_stop`` return value from ``void`` to
+ ``int`` to provide a way to report various error conditions.
+
ABI Changes
-----------
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index d9b82df073..b8cf04ef4d 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1661,7 +1661,7 @@ rte_eth_dev_start(uint16_t port_id)
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
int diag;
- int ret;
+ int ret, ret_stop;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
@@ -1695,7 +1695,13 @@ rte_eth_dev_start(uint16_t port_id)
RTE_ETHDEV_LOG(ERR,
"Error during restoring configuration for device (port %u): %s\n",
port_id, rte_strerror(-ret));
- rte_eth_dev_stop(port_id);
+ ret_stop = rte_eth_dev_stop(port_id);
+ if (ret_stop != 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Failed to stop device (port %u): %s\n",
+ port_id, rte_strerror(-ret_stop));
+ }
+
return ret;
}
@@ -1708,26 +1714,28 @@ rte_eth_dev_start(uint16_t port_id)
return 0;
}
-void
+int
rte_eth_dev_stop(uint16_t port_id)
{
struct rte_eth_dev *dev;
- RTE_ETH_VALID_PORTID_OR_RET(port_id);
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_stop);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_stop, -ENOTSUP);
if (dev->data->dev_started == 0) {
RTE_ETHDEV_LOG(INFO,
"Device with port_id=%"PRIu16" already stopped\n",
port_id);
- return;
+ return 0;
}
dev->data->dev_started = 0;
(*dev->dev_ops->dev_stop)(dev);
rte_ethdev_trace_stop(port_id);
+
+ return 0;
}
int
@@ -1783,7 +1791,12 @@ rte_eth_dev_reset(uint16_t port_id)
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_reset, -ENOTSUP);
- rte_eth_dev_stop(port_id);
+ ret = rte_eth_dev_stop(port_id);
+ if (ret != 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Failed to stop device (port %u) before reset: %s - ignore\n",
+ port_id, rte_strerror(-ret));
+ }
ret = dev->dev_ops->dev_reset(dev);
return eth_err(port_id, ret);
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index a61ca115a0..b85861cf2b 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -2277,8 +2277,11 @@ int rte_eth_dev_start(uint16_t port_id);
*
* @param port_id
* The port identifier of the Ethernet device.
+ * @return
+ * - 0: Success, Ethernet device stopped.
+ * - <0: Error code of the driver device stop function.
*/
-void rte_eth_dev_stop(uint16_t port_id);
+int rte_eth_dev_stop(uint16_t port_id);
/**
* Link up an Ethernet device.
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 2/5] ethdev: add new attributes to hairpin config
@ 2020-10-15 13:08 4% ` Bing Zhao
0 siblings, 0 replies; 200+ results
From: Bing Zhao @ 2020-10-15 13:08 UTC (permalink / raw)
To: thomas, orika, ferruh.yigit, arybchenko, mdr, nhorman,
bernard.iremonger, beilei.xing, wenzhuo.lu
Cc: dev
To support two ports hairpin mode and keep the backward compatibility
for the application, two new attribute members of the hairpin queue
configuration structure will be added.
`tx_explicit` means if the application itself will insert the Tx part
flow rules. If not set, PMD will insert the rules implicitly.
`manual_bind` means if the hairpin Tx queue and peer Rx queue will be
bound automatically during the device start stage.
Different Tx and Rx queue pairs could have different values, but it
is highly recommended that all paired queues between one egress and
its peer ingress ports have the same values, in order not to bring
any chaos to the system. The actual support of these attribute
parameters will be checked and decided by the PMD drivers.
In the single port hairpin, if both are zero without any setting, the
behavior will remain the same as before. It means that no bind API
needs to be called and no Tx flow rules need to be inserted manually
by the application.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
---
v6: Using unnecessary comment and using "Rx" & "Tx"
v4: squash document update and more info for the two new attributes
v2: optimize the structure and remove unused macros
---
doc/guides/prog_guide/rte_flow.rst | 3 +++
doc/guides/rel_notes/release_20_11.rst | 7 +++++++
lib/librte_ethdev/rte_ethdev.c | 8 ++++----
lib/librte_ethdev/rte_ethdev.h | 27 ++++++++++++++++++++++++++-
4 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 55497c9..3df005a 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2618,6 +2618,9 @@ set, unpredictable value will be seen depending on driver implementation. For
loopback/hairpin packet, metadata set on Rx/Tx may or may not be propagated to
the other path depending on HW capability.
+In hairpin case with Tx explicit flow mode, metadata could (not mandatory) be
+used to connect the Rx and Tx flows if it can be propagated from Rx to Tx path.
+
.. _table_rte_flow_action_set_meta:
.. table:: SET_META
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 02bf7ca..2f23e6f 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -92,6 +92,7 @@ New Features
* **Updated the ethdev library to support hairpin between two ports.**
New APIs are introduced to support binding / unbinding 2 ports hairpin.
+ Hairpin Tx part flow rules can be inserted explicitly.
* **Updated Broadcom bnxt driver.**
@@ -396,6 +397,12 @@ ABI Changes
Applications should use the new values for identification of existing
extensions in the packet header.
+ * ``struct rte_eth_hairpin_conf`` has two new members:
+
+ * ``uint32_t tx_explicit:1;``
+ * ``uint32_t manual_bind:1;``
+
+
Known Issues
------------
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 57cf4a7..bcbee30 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2003,13 +2003,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_rx_2_tx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Rx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_rx_2_tx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Rx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
@@ -2174,13 +2174,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_tx_2_rx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Tx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_tx_2_rx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Tx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 10eb626..a8e5cdc 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1045,7 +1045,32 @@ struct rte_eth_hairpin_peer {
* A structure used to configure hairpin binding.
*/
struct rte_eth_hairpin_conf {
- uint16_t peer_count; /**< The number of peers. */
+ uint32_t peer_count:16; /**< The number of peers. */
+
+ /**
+ * Explicit Tx flow rule mode.
+ * One hairpin pair of queues should have the same attribute.
+ *
+ * - When set, the user should be responsible for inserting the hairpin
+ * Tx part flows and removing them.
+ * - When clear, the PMD will try to handle the Tx part of the flows,
+ * e.g., by splitting one flow into two parts.
+ */
+ uint32_t tx_explicit:1;
+
+ /**
+ * Manually bind hairpin queues.
+ * One hairpin pair of queues should have the same attribute.
+ *
+ * - When set, to enable hairpin, the user should call the hairpin bind
+ * function after all the queues are set up properly and the ports are
+ * started. Also, the hairpin unbind function should be called
+ * accordingly before stopping a port that with hairpin configured.
+ * - When clear, the PMD will try to enable the hairpin with the queues
+ * configured automatically during port start.
+ */
+ uint32_t manual_bind:1;
+ uint32_t reserved:14; /**< Reserved bits. */
struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
};
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 12:49 0% ` Thomas Monjalon
@ 2020-10-15 13:07 0% ` Andrew Rybchenko
2020-10-15 13:57 0% ` Slava Ovsiienko
2020-10-15 20:22 0% ` Slava Ovsiienko
0 siblings, 2 replies; 200+ results
From: Andrew Rybchenko @ 2020-10-15 13:07 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit, Jerin Jacob, Slava Ovsiienko,
Andrew Rybchenko
Cc: dpdk-dev, Stephen Hemminger, Olivier Matz, Maxime Coquelin,
David Marchand
On 10/15/20 3:49 PM, Thomas Monjalon wrote:
> 15/10/2020 13:49, Slava Ovsiienko:
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>> On 10/15/2020 12:26 PM, Jerin Jacob wrote:
>>>
>>> <...>
>>>
>>>>>>>> If we see some of the features of such kind or other PMDs adopts
>>>>>>>> the split feature - we'll try to find the common root and consider
>>>>>>>> the way how
>>>>>> to report it.
>>>>>>>
>>>>>>> My only concern with that approach will be ABI break again if
>>>>>>> something needs to exposed over rte_eth_dev_info().
>>>>>
>>>>> Let's reserve the pointer to struct rte_eth_rxseg_limitations in the
>>>>> rte_eth_dev_info to avoid ABI break?
>>>>
>>>> Works for me. If we add an additional reserved field.
>>>>
>>>> Due to RC1 time constraint, I am OK to leave it as a reserved filed
>>>> and fill meat when it is required if other ethdev maintainers are OK.
>>>> I will be required for feature complete.
>>>>
>>>
>>> Sounds good to me.
>
> OK for me.
OK as well, but I dislike the idea with pointer in dev_info.
It sounds like it breaks existing practice.
We should either reserve enough space or simply add
dedicated API call to report Rx seg capabilities.
>
>> OK, let's introduce the pointer in the rte_eth_dev_info and
>> define struct rte_eth_rxseg_limitations as experimental.
>> Will it be allowed to update this one later (after 20.11)?
>> Is ABI break is allowed for the case?
>
> If it is experimental, you can change it at anytime.
>
> Ideally, we could try to have a first version of the limitations
> during 20.11-rc2.
Yes, please.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 6/7] build: standardize component names and defines
@ 2020-10-15 13:05 3% ` Luca Boccassi
2020-10-15 14:03 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2020-10-15 13:05 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, david.marchand, arybchenko, ferruh.yigit, thomas
On Thu, 2020-10-15 at 12:18 +0100, Bruce Richardson wrote:
> On Thu, Oct 15, 2020 at 11:30:29AM +0100, Luca Boccassi wrote:
> > On Wed, 2020-10-14 at 15:13 +0100, Bruce Richardson wrote:
> > > As discussed on the dpdk-dev mailing list[1], we can make some easy
> > > improvements in standardizing the naming of the various components in DPDK,
> > > and their associated feature-enabled macros.
> > >
> > > Following this patch, each library will have the name in format,
> > > 'librte_<name>.so', and the macro indicating that library is enabled in the
> > > build will have the form 'RTE_LIB_<NAME>'.
> > >
> > > Similarly, for libraries, the equivalent name formats and macros are:
> > > 'librte_<class>_<name>.so' and 'RTE_<CLASS>_<NAME>', where class is the
> > > device type taken from the relevant driver subdirectory name, i.e. 'net',
> > > 'crypto' etc.
> > >
> > > To avoid too many changes at once for end applications, the old macro names
> > > will still be provided in the build in this release, but will be removed
> > > subsequently.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > >
> > > [1] http://inbox.dpdk.org/dev/ef7c1a87-79ab-e405-4202-39b7ad6b0c71@solarflare.com/t/#u
> > > ---
> > > app/test-bbdev/meson.build | 4 ++--
> > > app/test-crypto-perf/meson.build | 2 +-
> > > app/test-pmd/meson.build | 12 ++++++------
> > > app/test/meson.build | 8 ++++----
> > > doc/guides/rel_notes/deprecation.rst | 8 ++++++++
> > > drivers/baseband/meson.build | 1 -
> > > drivers/bus/meson.build | 1 -
> > > drivers/common/meson.build | 1 -
> > > drivers/common/mlx5/meson.build | 1 -
> > > drivers/common/qat/meson.build | 1 -
> > > drivers/compress/meson.build | 1 -
> > > drivers/compress/octeontx/meson.build | 2 +-
> > > drivers/crypto/meson.build | 1 -
> > > drivers/crypto/null/meson.build | 2 +-
> > > drivers/crypto/octeontx/meson.build | 2 +-
> > > drivers/crypto/octeontx2/meson.build | 2 +-
> > > drivers/crypto/scheduler/meson.build | 2 +-
> > > drivers/crypto/virtio/meson.build | 2 +-
> > > drivers/event/dpaa/meson.build | 2 +-
> > > drivers/event/dpaa2/meson.build | 2 +-
> > > drivers/event/meson.build | 1 -
> > > drivers/event/octeontx/meson.build | 2 +-
> > > drivers/event/octeontx2/meson.build | 2 +-
> > > drivers/mempool/meson.build | 1 -
> > > drivers/meson.build | 9 ++++-----
> > > drivers/net/meson.build | 1 -
> > > drivers/net/mlx4/meson.build | 2 +-
> > > drivers/raw/ifpga/meson.build | 2 +-
> > > drivers/raw/meson.build | 1 -
> > > drivers/regex/meson.build | 1 -
> > > drivers/vdpa/meson.build | 1 -
> > > examples/bond/meson.build | 2 +-
> > > examples/ethtool/meson.build | 2 +-
> > > examples/ioat/meson.build | 2 +-
> > > examples/l2fwd-crypto/meson.build | 2 +-
> > > examples/ntb/meson.build | 2 +-
> > > examples/vm_power_manager/meson.build | 6 +++---
> > > lib/librte_ethdev/meson.build | 1 -
> > > lib/librte_graph/meson.build | 2 --
> > > lib/meson.build | 3 ++-
> > > 40 files changed, 47 insertions(+), 55 deletions(-)
> >
> > Does this change the share object file names too, or only the macros?
> >
>
> It does indeed change the object name files, which is a little bit
> concerning. However, the consensus based on the RFC seemed to be that the
> benefit is likely worth the change. If we want, we can look to use symlinks
> to the old names on install, but I think that just delays the pain since I
> would expect few to actually change their build to the new names until the
> old ones and the symlinks completely go away.
>
> /Bruce
It is a backward incompatible change, so we need to provide symlinks,
right? On upgrade, programs linked to librte_old.so will fail to start.
Or was this targeted at 20.11 thus piggy-backing on the ABI change
which forces a re-link?
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 11:49 3% ` Slava Ovsiienko
@ 2020-10-15 12:49 0% ` Thomas Monjalon
2020-10-15 13:07 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2020-10-15 12:49 UTC (permalink / raw)
To: Ferruh Yigit, Jerin Jacob, Slava Ovsiienko, Andrew Rybchenko
Cc: dpdk-dev, Stephen Hemminger, Olivier Matz, Maxime Coquelin,
David Marchand
15/10/2020 13:49, Slava Ovsiienko:
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> > On 10/15/2020 12:26 PM, Jerin Jacob wrote:
> >
> > <...>
> >
> > >>>>> If we see some of the features of such kind or other PMDs adopts
> > >>>>> the split feature - we'll try to find the common root and consider
> > >>>>> the way how
> > >>> to report it.
> > >>>>
> > >>>> My only concern with that approach will be ABI break again if
> > >>>> something needs to exposed over rte_eth_dev_info().
> > >>
> > >> Let's reserve the pointer to struct rte_eth_rxseg_limitations in the
> > >> rte_eth_dev_info to avoid ABI break?
> > >
> > > Works for me. If we add an additional reserved field.
> > >
> > > Due to RC1 time constraint, I am OK to leave it as a reserved filed
> > > and fill meat when it is required if other ethdev maintainers are OK.
> > > I will be required for feature complete.
> > >
> >
> > Sounds good to me.
OK for me.
> OK, let's introduce the pointer in the rte_eth_dev_info and
> define struct rte_eth_rxseg_limitations as experimental.
> Will it be allowed to update this one later (after 20.11)?
> Is ABI break is allowed for the case?
If it is experimental, you can change it at anytime.
Ideally, we could try to have a first version of the limitations
during 20.11-rc2.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 11:36 0% ` Ferruh Yigit
@ 2020-10-15 11:49 3% ` Slava Ovsiienko
2020-10-15 12:49 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Slava Ovsiienko @ 2020-10-15 11:49 UTC (permalink / raw)
To: Ferruh Yigit, Jerin Jacob
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Olivier Matz, Maxime Coquelin, David Marchand, Andrew Rybchenko
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Thursday, October 15, 2020 14:37
> To: Jerin Jacob <jerinjacobk@gmail.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>
> Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Stephen Hemminger
> <stephen@networkplumber.org>; Olivier Matz <olivier.matz@6wind.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; David Marchand
> <david.marchand@redhat.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
>
> On 10/15/2020 12:26 PM, Jerin Jacob wrote:
>
> <...>
>
> >>>>> If we see some of the features of such kind or other PMDs adopts
> >>>>> the split feature - we'll try to find the common root and consider
> >>>>> the way how
> >>> to report it.
> >>>>
> >>>> My only concern with that approach will be ABI break again if
> >>>> something needs to exposed over rte_eth_dev_info().
> >>
> >> Let's reserve the pointer to struct rte_eth_rxseg_limitations in the
> >> rte_eth_dev_info to avoid ABI break?
> >
> > Works for me. If we add an additional reserved field.
> >
> > Due to RC1 time constraint, I am OK to leave it as a reserved filed
> > and fill meat when it is required if other ethdev maintainers are OK.
> > I will be required for feature complete.
> >
>
> Sounds good to me.
OK, let's introduce the pointer in the rte_eth_dev_info and
define struct rte_eth_rxseg_limitations as experimental.
Will it be allowed to update this one later (after 20.11)?
Is ABI break is allowed for the case?
With best regards, Slava
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 11:26 0% ` Jerin Jacob
@ 2020-10-15 11:36 0% ` Ferruh Yigit
2020-10-15 11:49 3% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2020-10-15 11:36 UTC (permalink / raw)
To: Jerin Jacob, Slava Ovsiienko
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Olivier Matz, Maxime Coquelin, David Marchand, Andrew Rybchenko
On 10/15/2020 12:26 PM, Jerin Jacob wrote:
<...>
>>>>> If we see some of the features of such kind or other PMDs adopts the
>>>>> split feature - we'll try to find the common root and consider the way how
>>> to report it.
>>>>
>>>> My only concern with that approach will be ABI break again if
>>>> something needs to exposed over rte_eth_dev_info().
>>
>> Let's reserve the pointer to struct rte_eth_rxseg_limitations
>> in the rte_eth_dev_info to avoid ABI break?
>
> Works for me. If we add an additional reserved field.
>
> Due to RC1 time constraint, I am OK to leave it as a reserved filed and fill
> meat when it is required if other ethdev maintainers are OK.
> I will be required for feature complete.
>
Sounds good to me.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 10:51 3% ` Slava Ovsiienko
@ 2020-10-15 11:26 0% ` Jerin Jacob
2020-10-15 11:36 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2020-10-15 11:26 UTC (permalink / raw)
To: Slava Ovsiienko
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
On Thu, Oct 15, 2020 at 4:21 PM Slava Ovsiienko <viacheslavo@nvidia.com> wrote:
>
> Hi, Jerin
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Thursday, October 15, 2020 13:28
> > To: Slava Ovsiienko <viacheslavo@nvidia.com>
> > Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>; Stephen Hemminger
> > <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
> > Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
> > <maxime.coquelin@redhat.com>; David Marchand
> > <david.marchand@redhat.com>; Andrew Rybchenko
> > <arybchenko@solarflare.com>
> > Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
> >
> [..snip..]
> >
> > struct rte_eth_rxseg {
> > enum rte_eth_rxseg_mode mode ;
> > union {
> > struct rte_eth_rxseg_mode xxx {
> > struct rte_mempool *mp; /**< Memory pool to allocate
> > segment from. */
> > uint16_t length; /**< Segment data length, configures split
> > point. */
> > uint16_t offset; /**< Data offset from beginning of mbuf data
> > buffer. */
> > uint32_t reserved; /**< Reserved field. */
> > }
> > }
>
> There is an array of rte_eth_rxseg. It would introduce multiple "enum rte_eth_rxseg_mode mode"
> and would cause some ambiguity. About mode selection - please, see below.
> Union seems to be good idea, let's adopt.
Ack. Let's take the only union concept.
>
> >
> > Another mode, Marvell PMD has it(I believe Intel also) i.e When we say:
> >
> > seg0 - pool0, len0=2000B, off0=0
> > seg1 - pool1, len1=2001B, off1=0
> >
> > packet size up to, 2000B goes to pool 0 and if is >=2001 goes to pool1.
> > I think, it is better to have mode param in rte_eth_rxseg for avoiding ABI
> > changes.(Just like clean rte_flow APIs)
>
> It is supposed to choose with RTE_ETH_RX_OFFLOAD_xxx flags.
> For packet sorting it should be something like this RTE_ETH_RX_OFFLOAD_SORT.
> PMD reports it supports the feature, the flag is set in rx_conf->offloads
> and rxseg structure is interpreted according to these flags.
Works for me.
>
> Please, note, there is intentionally no check for RTE_ETH_RX_OFFLOAD_xxx
> in rte_eth_dev_rx_queue_setup() - it should be done on PMD side.
>
> >
> > > > If we see some of the features of such kind or other PMDs adopts the
> > > > split feature - we'll try to find the common root and consider the way how
> > to report it.
> > >
> > > My only concern with that approach will be ABI break again if
> > > something needs to exposed over rte_eth_dev_info().
>
> Let's reserve the pointer to struct rte_eth_rxseg_limitations
> in the rte_eth_dev_info to avoid ABI break?
Works for me. If we add an additional reserved field.
Due to RC1 time constraint, I am OK to leave it as a reserved filed and fill
meat when it is required if other ethdev maintainers are OK.
I will be required for feature complete.
>
> With best regards, Slava
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 10:34 3% ` Slava Ovsiienko
@ 2020-10-15 11:09 0% ` Andrew Rybchenko
2020-10-15 14:39 0% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2020-10-15 11:09 UTC (permalink / raw)
To: Slava Ovsiienko, Jerin Jacob
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
On 10/15/20 1:34 PM, Slava Ovsiienko wrote:
> Hi, Andrew
>
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Thursday, October 15, 2020 12:49
>> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Jerin Jacob
>> <jerinjacobk@gmail.com>
>> Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
>> <thomas@monjalon.net>; Stephen Hemminger
>> <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
>> Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
>> <maxime.coquelin@redhat.com>; David Marchand
>> <david.marchand@redhat.com>; Andrew Rybchenko
>> <arybchenko@solarflare.com>
>> Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
>>
>> On 10/15/20 10:43 AM, Slava Ovsiienko wrote:
>>> Hi, Jerin
>>>
>>>> -----Original Message-----
>>>> From: Jerin Jacob <jerinjacobk@gmail.com>
>>>> Sent: Wednesday, October 14, 2020 21:57
>>>> To: Slava Ovsiienko <viacheslavo@nvidia.com>
>>>> Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
>>>> <thomas@monjalon.net>; Stephen Hemminger
>>>> <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
>>>> Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
>>>> <maxime.coquelin@redhat.com>; David Marchand
>>>> <david.marchand@redhat.com>; Andrew Rybchenko
>>>> <arybchenko@solarflare.com>
>>>> Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
>>>>
>>>> On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko
>>>> <viacheslavo@nvidia.com> wrote:
>>>>>
>>>>> The DPDK datapath in the transmit direction is very flexible.
>>>>> An application can build the multi-segment packet and manages almost
>>>>> all data aspects - the memory pools where segments are allocated
>>>>> from, the segment lengths, the memory attributes like external
>>>>> buffers, registered for DMA, etc.
>>>>>
>>>
>>> [..snip..]
>>>
>>>>> For example, let's suppose we configured the Rx queue with the
>>>>> following segments:
>>>>> seg0 - pool0, len0=14B, off0=2
>>>>> seg1 - pool1, len1=20B, off1=128B
>>>>> seg2 - pool2, len2=20B, off2=0B
>>>>> seg3 - pool3, len3=512B, off3=0B
>>>>
>>>>
>>>> Sorry for chime in late. This API lookout looks good to me.
>>>> But, I am wondering how the application can know the capability or
>>>> "limits" of struct rte_eth_rxseg structure for the specific PMD. The
>>>> other descriptor limit, it's being exposed with struct
>>>> rte_eth_dev_info::rx_desc_lim; If PMD can support a specific pattern
>>>> rather than returning the blanket error, the application should know the
>> limit.
>>>> IMO, it is better to add
>>>> struct rte_eth_rxseg *rxsegs;
>>>> unint16_t nb_max_rxsegs
>>>> in rte_eth_dev_info structure to express the capablity.
>>>> Where the en and offset can define the max offset.
>>>>
>>>> Thoughts?
>>>
>>> Moreover, there might be implied a lot of various limitations -
>>> offsets might be not supported at all or have some requirements for
>>> alignment, the similar requirements might be applied to segment size
>>> (say, ask for some granularity). Currently it is not obvious how to
>>> report all nuances, and it is supposed the limitations of this kind must be
>> documented in PMD chapter. As for mlx5 - it has no special limitations besides
>> common requirements to the regular segments.
>>>
>>> One more point - the split feature might be considered as just one of
>>> possible cases of using these segment descriptions, other features might
>> impose other (unknown for now) limitations.
>>> If we see some of the features of such kind or other PMDs adopts the
>>> split feature - we'll try to find the common root and consider the way how to
>> report it.
>>
>> At least there are few simple limitations which are easy to
>> express:
>> 1. Maximum number of segments
> We have scatter capability and we do not report the maximal number of segments,
> it is on PMD own. We could add the field to the rte_eth_dev_info, but not sure
> whether we have something special to report there even for mlx5 case.
There is always a limitation in programming and HW. Nothing is
unlimited. Limits could be high, but still exist.
Number of descriptors? Width of field in HW interface?
Maximum length of the config message to HW?
All above could limit it directly or indirectly.
>> 2. Possibility to use the last segment many times if required
>> (I was suggesting to use scatter for it, but you rejected
>> the idea - may be time to reconsider :) )
>
> Mmm, sorry I do not follow, it might be I did not understand/missed your idea.
> Some of the last segment attributes are used multiple times to scatter the rest
> of the data in fashion very close to the existing scattering approach - at least,
> pool and buffer size from this pool are used. The beginning of the packet
> scattered according to the new descriptions, the rest of the packet -
> according to the existing regular scattering with pool settings from
> the last segment description.
I believe that the possibility to split into a fixed segments
(BUFFER_SPLIT) and possibility to use a mempool (just mp or
last segment) many times if a packet does not fit (SCATTER)
it is *different* features.
I can easily imagine HW which could do BUFFER_SPLIT to
fixed segments, but cannot use the last segment many times
(i.e. no classical SCATTER).
>
> 3. Maximum offset
>> Frankly speaking I'm not sure why it cannot be handled on
>> PMD level (i.e. provide descriptors with offset taken into
>> account or guarantee that HW mempool objects initialized
>> correctly with required headroom). May be in some corner
>> cases when the same HW mempool is shared by various
>> segments with different offset requirements.
>
> HW offsets are beyond the feature scope, the offsets in the segment
> description is supposed to be added to the native pool offsets (if any).
Are you saying that offsets are not passed to HW and just
handled by PMD to provide correct IOVA addresses to put
data to? If so, it is an implementation detail which is
specific to mlx5. If so, no specific limitations
except data room, size and offset consistency.
But it could be passed to a HW and it could be, for example,
just 8 bits for the value.
>
>> 4. Offset alignment
>> 5. Maximum/minimum length of a segment
>> 6. Length alignment
> In which form? Mask of lsbs ? 0 means no limitations ?
log2, i.e. 0 => 1 (no limitations) 1 => 2 (even only),
6 => 64 (64-byte cache line aligned) etc.
>
>>
>> I realize that 3, 4 and 5 could be per segment number.
>> If it is really that complex, report common denominator which is guaranteed to
>> work. If we have no checks on ethdev layer, application can ignore it if it knows
>> better.
>
> Currently it is not clear at all what kind of limitations should be reported,
> we could include all of mentioned/proposed ones, and no one will report there -
> mlx5 has no any reasonable limitations to report for now.
>
> Should we reserve some pointer field in the rte_eth_dev_info to report
> the limitations? (Limitation description should contain variable size array,
> depending on the number of segments, so pointer seems to be appropriate).
> It would allow us to avoid ABI break, and present the limitation structure once it is defined.
I will let other ethdev maintainers to make a decision here.
My vote would be to report limitations mentioned above.
It looks like Jerin is also interested in limitations
reporting. Not sure if my form looks OK or no.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 10:27 3% ` Jerin Jacob
@ 2020-10-15 10:51 3% ` Slava Ovsiienko
2020-10-15 11:26 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Slava Ovsiienko @ 2020-10-15 10:51 UTC (permalink / raw)
To: Jerin Jacob
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
Hi, Jerin
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, October 15, 2020 13:28
> To: Slava Ovsiienko <viacheslavo@nvidia.com>
> Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Stephen Hemminger
> <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
> Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
> <maxime.coquelin@redhat.com>; David Marchand
> <david.marchand@redhat.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
>
[..snip..]
>
> struct rte_eth_rxseg {
> enum rte_eth_rxseg_mode mode ;
> union {
> struct rte_eth_rxseg_mode xxx {
> struct rte_mempool *mp; /**< Memory pool to allocate
> segment from. */
> uint16_t length; /**< Segment data length, configures split
> point. */
> uint16_t offset; /**< Data offset from beginning of mbuf data
> buffer. */
> uint32_t reserved; /**< Reserved field. */
> }
> }
There is an array of rte_eth_rxseg. It would introduce multiple "enum rte_eth_rxseg_mode mode"
and would cause some ambiguity. About mode selection - please, see below.
Union seems to be good idea, let's adopt.
>
> Another mode, Marvell PMD has it(I believe Intel also) i.e When we say:
>
> seg0 - pool0, len0=2000B, off0=0
> seg1 - pool1, len1=2001B, off1=0
>
> packet size up to, 2000B goes to pool 0 and if is >=2001 goes to pool1.
> I think, it is better to have mode param in rte_eth_rxseg for avoiding ABI
> changes.(Just like clean rte_flow APIs)
It is supposed to choose with RTE_ETH_RX_OFFLOAD_xxx flags.
For packet sorting it should be something like this RTE_ETH_RX_OFFLOAD_SORT.
PMD reports it supports the feature, the flag is set in rx_conf->offloads
and rxseg structure is interpreted according to these flags.
Please, note, there is intentionally no check for RTE_ETH_RX_OFFLOAD_xxx
in rte_eth_dev_rx_queue_setup() - it should be done on PMD side.
>
> > > If we see some of the features of such kind or other PMDs adopts the
> > > split feature - we'll try to find the common root and consider the way how
> to report it.
> >
> > My only concern with that approach will be ABI break again if
> > something needs to exposed over rte_eth_dev_info().
Let's reserve the pointer to struct rte_eth_rxseg_limitations
in the rte_eth_dev_info to avoid ABI break?
With best regards, Slava
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
@ 2020-10-15 10:34 3% ` Slava Ovsiienko
2020-10-15 11:09 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Slava Ovsiienko @ 2020-10-15 10:34 UTC (permalink / raw)
To: Andrew Rybchenko, Jerin Jacob
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
Hi, Andrew
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Thursday, October 15, 2020 12:49
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Jerin Jacob
> <jerinjacobk@gmail.com>
> Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; Stephen Hemminger
> <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
> Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
> <maxime.coquelin@redhat.com>; David Marchand
> <david.marchand@redhat.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>
> Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
>
> On 10/15/20 10:43 AM, Slava Ovsiienko wrote:
> > Hi, Jerin
> >
> >> -----Original Message-----
> >> From: Jerin Jacob <jerinjacobk@gmail.com>
> >> Sent: Wednesday, October 14, 2020 21:57
> >> To: Slava Ovsiienko <viacheslavo@nvidia.com>
> >> Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> >> <thomas@monjalon.net>; Stephen Hemminger
> >> <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
> >> Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
> >> <maxime.coquelin@redhat.com>; David Marchand
> >> <david.marchand@redhat.com>; Andrew Rybchenko
> >> <arybchenko@solarflare.com>
> >> Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
> >>
> >> On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko
> >> <viacheslavo@nvidia.com> wrote:
> >>>
> >>> The DPDK datapath in the transmit direction is very flexible.
> >>> An application can build the multi-segment packet and manages almost
> >>> all data aspects - the memory pools where segments are allocated
> >>> from, the segment lengths, the memory attributes like external
> >>> buffers, registered for DMA, etc.
> >>>
> >
> > [..snip..]
> >
> >>> For example, let's suppose we configured the Rx queue with the
> >>> following segments:
> >>> seg0 - pool0, len0=14B, off0=2
> >>> seg1 - pool1, len1=20B, off1=128B
> >>> seg2 - pool2, len2=20B, off2=0B
> >>> seg3 - pool3, len3=512B, off3=0B
> >>
> >>
> >> Sorry for chime in late. This API lookout looks good to me.
> >> But, I am wondering how the application can know the capability or
> >> "limits" of struct rte_eth_rxseg structure for the specific PMD. The
> >> other descriptor limit, it's being exposed with struct
> >> rte_eth_dev_info::rx_desc_lim; If PMD can support a specific pattern
> >> rather than returning the blanket error, the application should know the
> limit.
> >> IMO, it is better to add
> >> struct rte_eth_rxseg *rxsegs;
> >> unint16_t nb_max_rxsegs
> >> in rte_eth_dev_info structure to express the capablity.
> >> Where the en and offset can define the max offset.
> >>
> >> Thoughts?
> >
> > Moreover, there might be implied a lot of various limitations -
> > offsets might be not supported at all or have some requirements for
> > alignment, the similar requirements might be applied to segment size
> > (say, ask for some granularity). Currently it is not obvious how to
> > report all nuances, and it is supposed the limitations of this kind must be
> documented in PMD chapter. As for mlx5 - it has no special limitations besides
> common requirements to the regular segments.
> >
> > One more point - the split feature might be considered as just one of
> > possible cases of using these segment descriptions, other features might
> impose other (unknown for now) limitations.
> > If we see some of the features of such kind or other PMDs adopts the
> > split feature - we'll try to find the common root and consider the way how to
> report it.
>
> At least there are few simple limitations which are easy to
> express:
> 1. Maximum number of segments
We have scatter capability and we do not report the maximal number of segments,
it is on PMD own. We could add the field to the rte_eth_dev_info, but not sure
whether we have something special to report there even for mlx5 case.
> 2. Possibility to use the last segment many times if required
> (I was suggesting to use scatter for it, but you rejected
> the idea - may be time to reconsider :) )
Mmm, sorry I do not follow, it might be I did not understand/missed your idea.
Some of the last segment attributes are used multiple times to scatter the rest
of the data in fashion very close to the existing scattering approach - at least,
pool and buffer size from this pool are used. The beginning of the packet
scattered according to the new descriptions, the rest of the packet -
according to the existing regular scattering with pool settings from
the last segment description.
3. Maximum offset
> Frankly speaking I'm not sure why it cannot be handled on
> PMD level (i.e. provide descriptors with offset taken into
> account or guarantee that HW mempool objects initialized
> correctly with required headroom). May be in some corner
> cases when the same HW mempool is shared by various
> segments with different offset requirements.
HW offsets are beyond the feature scope, the offsets in the segment
description is supposed to be added to the native pool offsets (if any).
> 4. Offset alignment
> 5. Maximum/minimum length of a segment
> 6. Length alignment
In which form? Mask of lsbs ? 0 means no limitations ?
>
> I realize that 3, 4 and 5 could be per segment number.
> If it is really that complex, report common denominator which is guaranteed to
> work. If we have no checks on ethdev layer, application can ignore it if it knows
> better.
Currently it is not clear at all what kind of limitations should be reported,
we could include all of mentioned/proposed ones, and no one will report there -
mlx5 has no any reasonable limitations to report for now.
Should we reserve some pointer field in the rte_eth_dev_info to report
the limitations? (Limitation description should contain variable size array,
depending on the number of segments, so pointer seems to be appropriate).
It would allow us to avoid ABI break, and present the limitation structure once it is defined.
With best regards, Slava
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
2020-10-15 9:27 3% ` Jerin Jacob
@ 2020-10-15 10:27 3% ` Jerin Jacob
2020-10-15 10:51 3% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2020-10-15 10:27 UTC (permalink / raw)
To: Slava Ovsiienko
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
On Thu, Oct 15, 2020 at 2:57 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Thu, Oct 15, 2020 at 1:13 PM Slava Ovsiienko <viacheslavo@nvidia.com> wrote:
> >
> > Hi, Jerin
>
> Hi Slava,
>
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, October 14, 2020 21:57
> > > To: Slava Ovsiienko <viacheslavo@nvidia.com>
> > > Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> > > <thomas@monjalon.net>; Stephen Hemminger
> > > <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
> > > Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
> > > <maxime.coquelin@redhat.com>; David Marchand
> > > <david.marchand@redhat.com>; Andrew Rybchenko
> > > <arybchenko@solarflare.com>
> > > Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
> > >
> > > On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko
> > > <viacheslavo@nvidia.com> wrote:
> > > >
> > > > The DPDK datapath in the transmit direction is very flexible.
> > > > An application can build the multi-segment packet and manages almost
> > > > all data aspects - the memory pools where segments are allocated from,
> > > > the segment lengths, the memory attributes like external buffers,
> > > > registered for DMA, etc.
> > > >
> >
> > [..snip..]
> >
> > > > For example, let's suppose we configured the Rx queue with the
> > > > following segments:
> > > > seg0 - pool0, len0=14B, off0=2
> > > > seg1 - pool1, len1=20B, off1=128B
> > > > seg2 - pool2, len2=20B, off2=0B
> > > > seg3 - pool3, len3=512B, off3=0B
> > >
> > >
> > > Sorry for chime in late. This API lookout looks good to me.
> > > But, I am wondering how the application can know the capability or "limits" of
> > > struct rte_eth_rxseg structure for the specific PMD. The other descriptor limit,
> > > it's being exposed with struct rte_eth_dev_info::rx_desc_lim; If PMD can
> > > support a specific pattern rather than returning the blanket error, the
> > > application should know the limit.
> > > IMO, it is better to add
> > > struct rte_eth_rxseg *rxsegs;
> > > unint16_t nb_max_rxsegs
> > > in rte_eth_dev_info structure to express the capablity.
> > > Where the en and offset can define the max offset.
> > >
> > > Thoughts?
> >
> > Moreover, there might be implied a lot of various limitations - offsets might be not supported at all or
> > have some requirements for alignment, the similar requirements might be applied to segment size
> > (say, ask for some granularity). Currently it is not obvious how to report all nuances, and it is supposed
> > the limitations of this kind must be documented in PMD chapter. As for mlx5 - it has no special
> > limitations besides common requirements to the regular segments.
>
> Reporting the limitation in the documentation will not help for the
> generic applications.
>
> >
> > One more point - the split feature might be considered as just one of possible cases of using
> > these segment descriptions, other features might impose other (unknown for now) limitations.
Also , I agree that w will have multiple use cases with segment descriptors.
In order to make it future proof on the API definion is better to have
from:
struct rte_eth_rxseg {
struct rte_mempool *mp; /**< Memory pool to allocate segment from. */
uint16_t length; /**< Segment data length, configures split point. */
uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
uint32_t reserved; /**< Reserved field. */
};
something lime below:
struct rte_eth_rxseg {
enum rte_eth_rxseg_mode mode ;
union {
struct rte_eth_rxseg_mode xxx {
struct rte_mempool *mp; /**< Memory pool
to allocate segment from. */
uint16_t length; /**< Segment data
length, configures split point. */
uint16_t offset; /**< Data offset from
beginning of mbuf data buffer. */
uint32_t reserved; /**< Reserved field. */
}
}
Another mode, Marvell PMD has it(I believe Intel also) i.e
When we say:
seg0 - pool0, len0=2000B, off0=0
seg1 - pool1, len1=2001B, off1=0
packet size up to, 2000B goes to pool 0 and if is >=2001 goes to pool1.
I think, it is better to have mode param in rte_eth_rxseg for avoiding
ABI changes.(Just like clean rte_flow APIs)
> > If we see some of the features of such kind or other PMDs adopts the split feature - we'll try to find
> > the common root and consider the way how to report it.
>
> My only concern with that approach will be ABI break again if
> something needs to exposed over rte_eth_dev_info().
> IMO, if we featured needs to completed only when its capabilities are
> exposed in a programmatic manner.
> As of mlx5, if there not limitation then info
> rte_eth_dev_info::rxsegs[x].len, offset etc as UINT16_MAX so
> that application is aware of the state.
>
> >
> > With best regards, Slava
> >
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 2/4] devtools: abi and UX changes for test-meson-builds.sh
2020-10-14 10:41 26% ` [dpdk-dev] [PATCH v7 2/4] devtools: abi and UX changes for test-meson-builds.sh Conor Walsh
@ 2020-10-15 10:16 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-15 10:16 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 14/10/2020 11:41, Conor Walsh wrote:
> The core reason for this patch is to reduce the amount of time needed to
> run abi checks. The number of abi checks being run has been reduced to
> only 2 (1 x86_64 and 1 arm). The script can now also take adavtage of
> prebuilt abi references.
>
> Invoke using "./test-meson-builds.sh [-b <build directory>]
> [-a <dpdk tag or latest for abi check>] [-u <uri for abi references>]
> [-d <directory for abi references>]"
> - <build directory>: directory to store builds (relative or absolute)
> - <dpdk tag or latest for abi check>: dpdk tag e.g. "v20.11" or "latest"
> - <uri for abi references>: http location or directory to get prebuilt
> abi references from
> - <directory for abi references>: directory to store abi references
> (relative or absolute)
> e.g. "./test-meson-builds.sh -a latest"
> If no flags are specified test-meson-builds.sh will run the standard
> meson tests with default options unless environmental variables are
> specified.
>
> Signed-off-by: Conor Walsh <conor.walsh@intel.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives
2020-10-14 10:41 21% ` [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives Conor Walsh
@ 2020-10-15 10:15 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-15 10:15 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 14/10/2020 11:41, Conor Walsh wrote:
> This patch adds a script that generates compressed archives
> containing .dump files which can be used to perform abi
> breakage checking in test-meson-build.sh.
>
> Invoke using "./gen-abi-tarballs.sh [-v <dpdk tag>]"
> - <dpdk tag>: dpdk tag e.g. "v20.11" or "latest"
> e.g. "./gen-abi-tarballs.sh -v latest"
>
> If no tag is specified, the script will default to "latest"
> Using these parameters the script will produce several *.tar.gz
> archives containing .dump files required to do abi breakage checking
>
> Signed-off-by: Conor Walsh <conor.walsh@intel.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] cryptodev: revert support for 20.0 node
2020-10-15 10:08 0% ` David Marchand
@ 2020-10-15 10:10 3% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-15 10:10 UTC (permalink / raw)
To: David Marchand
Cc: Declan Doherty, Neil Horman, Anoob Joseph, Fiona Trahe,
Akhil Goyal, Arek Kusztal, Thomas Monjalon, dev
It is 100% ... my mistake, I was checking for ABI snafus.
Ray K
On 15/10/2020 11:08, David Marchand wrote:
> On Thu, Oct 15, 2020 at 11:59 AM Ray Kinsella <mdr@ashroe.eu> wrote:
>>
>> Function versioning to preserve the ABI was added to crytodev in
>> commit a0f0de06d457 ("cryptodev: fix ABI compatibility for
>> ChaCha20-Poly1305"). This is no longer required in the DPDK_21
>> version node.
>
> Is it a duplicate for [1]?
>
> 1: https://git.dpdk.org/next/dpdk-next-crypto/commit/lib/librte_cryptodev?id=e43f809f3a59a06f2bc80a2a6fe0c133f9e401fe
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] cryptodev: revert support for 20.0 node
2020-10-15 9:56 11% [dpdk-dev] [PATCH] cryptodev: revert support for 20.0 node Ray Kinsella
@ 2020-10-15 10:08 0% ` David Marchand
2020-10-15 10:10 3% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2020-10-15 10:08 UTC (permalink / raw)
To: Ray Kinsella
Cc: Declan Doherty, Neil Horman, Anoob Joseph, Fiona Trahe,
Akhil Goyal, Arek Kusztal, Thomas Monjalon, dev
On Thu, Oct 15, 2020 at 11:59 AM Ray Kinsella <mdr@ashroe.eu> wrote:
>
> Function versioning to preserve the ABI was added to crytodev in
> commit a0f0de06d457 ("cryptodev: fix ABI compatibility for
> ChaCha20-Poly1305"). This is no longer required in the DPDK_21
> version node.
Is it a duplicate for [1]?
1: https://git.dpdk.org/next/dpdk-next-crypto/commit/lib/librte_cryptodev?id=e43f809f3a59a06f2bc80a2a6fe0c133f9e401fe
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] cryptodev: revert support for 20.0 node
@ 2020-10-15 9:56 11% Ray Kinsella
2020-10-15 10:08 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2020-10-15 9:56 UTC (permalink / raw)
To: Declan Doherty, Ray Kinsella, Neil Horman, Anoob Joseph,
Fiona Trahe, Akhil Goyal, Arek Kusztal
Cc: thomas, david.marchand, dev
Function versioning to preserve the ABI was added to crytodev in
commit a0f0de06d457 ("cryptodev: fix ABI compatibility for
ChaCha20-Poly1305"). This is no longer required in the DPDK_21
version node.
Fixes: b922dbd38ced ("cryptodev: add ChaCha20-Poly1305 AEAD algorithm")
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
lib/librte_cryptodev/rte_cryptodev.c | 139 +-----------------
lib/librte_cryptodev/rte_cryptodev.h | 33 -----
.../rte_cryptodev_version.map | 6 -
3 files changed, 4 insertions(+), 174 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 1dd795bcb..a74daee46 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -36,8 +36,6 @@
#include <rte_errno.h>
#include <rte_spinlock.h>
#include <rte_string_fns.h>
-#include <rte_compat.h>
-#include <rte_function_versioning.h>
#include "rte_crypto.h"
#include "rte_cryptodev.h"
@@ -59,11 +57,6 @@ static struct rte_cryptodev_global cryptodev_globals = {
/* spinlock for crypto device callbacks */
static rte_spinlock_t rte_cryptodev_cb_lock = RTE_SPINLOCK_INITIALIZER;
-static const struct rte_cryptodev_capabilities
- cryptodev_undefined_capabilities[] = {
- RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
-};
-
static struct rte_cryptodev_capabilities
*capability_copy[RTE_CRYPTO_MAX_DEVS];
static uint8_t is_capability_checked[RTE_CRYPTO_MAX_DEVS];
@@ -291,43 +284,8 @@ rte_crypto_auth_operation_strings[] = {
[RTE_CRYPTO_AUTH_OP_GENERATE] = "generate"
};
-const struct rte_cryptodev_symmetric_capability __vsym *
-rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
- const struct rte_cryptodev_sym_capability_idx *idx)
-{
- const struct rte_cryptodev_capabilities *capability;
- struct rte_cryptodev_info dev_info;
- int i = 0;
-
- rte_cryptodev_info_get_v20(dev_id, &dev_info);
-
- while ((capability = &dev_info.capabilities[i++])->op !=
- RTE_CRYPTO_OP_TYPE_UNDEFINED) {
- if (capability->op != RTE_CRYPTO_OP_TYPE_SYMMETRIC)
- continue;
-
- if (capability->sym.xform_type != idx->type)
- continue;
-
- if (idx->type == RTE_CRYPTO_SYM_XFORM_AUTH &&
- capability->sym.auth.algo == idx->algo.auth)
- return &capability->sym;
-
- if (idx->type == RTE_CRYPTO_SYM_XFORM_CIPHER &&
- capability->sym.cipher.algo == idx->algo.cipher)
- return &capability->sym;
-
- if (idx->type == RTE_CRYPTO_SYM_XFORM_AEAD &&
- capability->sym.aead.algo == idx->algo.aead)
- return &capability->sym;
- }
-
- return NULL;
-}
-VERSION_SYMBOL(rte_cryptodev_sym_capability_get, _v20, 20.0);
-
-const struct rte_cryptodev_symmetric_capability __vsym *
-rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
+const struct rte_cryptodev_symmetric_capability *
+rte_cryptodev_sym_capability_get(uint8_t dev_id,
const struct rte_cryptodev_sym_capability_idx *idx)
{
const struct rte_cryptodev_capabilities *capability;
@@ -359,11 +317,6 @@ rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
return NULL;
}
-MAP_STATIC_SYMBOL(const struct rte_cryptodev_symmetric_capability *
- rte_cryptodev_sym_capability_get(uint8_t dev_id,
- const struct rte_cryptodev_sym_capability_idx *idx),
- rte_cryptodev_sym_capability_get_v21);
-BIND_DEFAULT_SYMBOL(rte_cryptodev_sym_capability_get, _v21, 21);
static int
param_range_check(uint16_t size, const struct rte_crypto_param_range *range)
@@ -1233,89 +1186,8 @@ rte_cryptodev_stats_reset(uint8_t dev_id)
(*dev->dev_ops->stats_reset)(dev);
}
-static void
-get_v20_capabilities(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
-{
- const struct rte_cryptodev_capabilities *capability;
- uint8_t found_invalid_capa = 0;
- uint8_t counter = 0;
-
- for (capability = dev_info->capabilities;
- capability->op != RTE_CRYPTO_OP_TYPE_UNDEFINED;
- ++capability, ++counter) {
- if (capability->op == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
- capability->sym.xform_type ==
- RTE_CRYPTO_SYM_XFORM_AEAD
- && capability->sym.aead.algo >=
- RTE_CRYPTO_AEAD_CHACHA20_POLY1305) {
- found_invalid_capa = 1;
- counter--;
- }
- }
- is_capability_checked[dev_id] = 1;
- if (!found_invalid_capa)
- return;
- capability_copy[dev_id] = malloc(counter *
- sizeof(struct rte_cryptodev_capabilities));
- if (capability_copy[dev_id] == NULL) {
- /*
- * error case - no memory to store the trimmed
- * list, so have to return an empty list
- */
- dev_info->capabilities =
- cryptodev_undefined_capabilities;
- is_capability_checked[dev_id] = 0;
- } else {
- counter = 0;
- for (capability = dev_info->capabilities;
- capability->op !=
- RTE_CRYPTO_OP_TYPE_UNDEFINED;
- capability++) {
- if (!(capability->op ==
- RTE_CRYPTO_OP_TYPE_SYMMETRIC
- && capability->sym.xform_type ==
- RTE_CRYPTO_SYM_XFORM_AEAD
- && capability->sym.aead.algo >=
- RTE_CRYPTO_AEAD_CHACHA20_POLY1305)) {
- capability_copy[dev_id][counter++] =
- *capability;
- }
- }
- dev_info->capabilities =
- capability_copy[dev_id];
- }
-}
-
-void __vsym
-rte_cryptodev_info_get_v20(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
-{
- struct rte_cryptodev *dev;
-
- if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
- CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
- return;
- }
-
- dev = &rte_crypto_devices[dev_id];
-
- memset(dev_info, 0, sizeof(struct rte_cryptodev_info));
-
- RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
- (*dev->dev_ops->dev_infos_get)(dev, dev_info);
-
- if (capability_copy[dev_id] == NULL) {
- if (!is_capability_checked[dev_id])
- get_v20_capabilities(dev_id, dev_info);
- } else
- dev_info->capabilities = capability_copy[dev_id];
-
- dev_info->driver_name = dev->device->driver->name;
- dev_info->device = dev->device;
-}
-VERSION_SYMBOL(rte_cryptodev_info_get, _v20, 20.0);
-
-void __vsym
-rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+void
+rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
{
struct rte_cryptodev *dev;
@@ -1334,9 +1206,6 @@ rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
dev_info->driver_name = dev->device->driver->name;
dev_info->device = dev->device;
}
-MAP_STATIC_SYMBOL(void rte_cryptodev_info_get(uint8_t dev_id,
- struct rte_cryptodev_info *dev_info), rte_cryptodev_info_get_v21);
-BIND_DEFAULT_SYMBOL(rte_cryptodev_info_get, _v21, 21);
int
rte_cryptodev_callback_register(uint8_t dev_id,
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 7b3ebc20f..f4767b52c 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -219,14 +219,6 @@ struct rte_cryptodev_asym_capability_idx {
* - Return NULL if the capability not exist.
*/
const struct rte_cryptodev_symmetric_capability *
-rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
- const struct rte_cryptodev_sym_capability_idx *idx);
-
-const struct rte_cryptodev_symmetric_capability *
-rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
- const struct rte_cryptodev_sym_capability_idx *idx);
-
-const struct rte_cryptodev_symmetric_capability *
rte_cryptodev_sym_capability_get(uint8_t dev_id,
const struct rte_cryptodev_sym_capability_idx *idx);
@@ -789,34 +781,9 @@ rte_cryptodev_stats_reset(uint8_t dev_id);
* the last valid element has it's op field set to
* RTE_CRYPTO_OP_TYPE_UNDEFINED.
*/
-
void
rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
-/* An extra element RTE_CRYPTO_AEAD_CHACHA20_POLY1305 is added
- * to enum rte_crypto_aead_algorithm, also changing the value of
- * RTE_CRYPTO_AEAD_LIST_END. To maintain ABI compatibility with applications
- * which linked against earlier versions, preventing them, for example, from
- * picking up the new value and using it to index into an array sized too small
- * for it, it is necessary to have two versions of rte_cryptodev_info_get()
- * The latest version just returns directly the capabilities retrieved from
- * the device. The compatible version inspects the capabilities retrieved
- * from the device, but only returns them directly if the new value
- * is not included. If the new value is included, it allocates space
- * for a copy of the device capabilities, trims the new value from this
- * and returns this copy. It only needs to do this once per device.
- * For the corner case of a corner case when the alloc may fail,
- * an empty capability list is returned, as there is no mechanism to return
- * an error and adding such a mechanism would itself be an ABI breakage.
- * The compatible version can be removed after the next major ABI release.
- */
-
-void
-rte_cryptodev_info_get_v20(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
-
-void
-rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
-
/**
* Register a callback function for specific device id.
*
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index 02f6dcf72..7727286ac 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -58,12 +58,6 @@ DPDK_21 {
local: *;
};
-DPDK_20.0 {
- global:
- rte_cryptodev_info_get;
- rte_cryptodev_sym_capability_get;
-};
-
EXPERIMENTAL {
global:
--
2.23.0
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split
@ 2020-10-15 9:27 3% ` Jerin Jacob
2020-10-15 10:27 3% ` Jerin Jacob
1 sibling, 1 reply; 200+ results
From: Jerin Jacob @ 2020-10-15 9:27 UTC (permalink / raw)
To: Slava Ovsiienko
Cc: dpdk-dev, NBU-Contact-Thomas Monjalon, Stephen Hemminger,
Ferruh Yigit, Olivier Matz, Maxime Coquelin, David Marchand,
Andrew Rybchenko
On Thu, Oct 15, 2020 at 1:13 PM Slava Ovsiienko <viacheslavo@nvidia.com> wrote:
>
> Hi, Jerin
Hi Slava,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, October 14, 2020 21:57
> > To: Slava Ovsiienko <viacheslavo@nvidia.com>
> > Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>; Stephen Hemminger
> > <stephen@networkplumber.org>; Ferruh Yigit <ferruh.yigit@intel.com>;
> > Olivier Matz <olivier.matz@6wind.com>; Maxime Coquelin
> > <maxime.coquelin@redhat.com>; David Marchand
> > <david.marchand@redhat.com>; Andrew Rybchenko
> > <arybchenko@solarflare.com>
> > Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
> >
> > On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko
> > <viacheslavo@nvidia.com> wrote:
> > >
> > > The DPDK datapath in the transmit direction is very flexible.
> > > An application can build the multi-segment packet and manages almost
> > > all data aspects - the memory pools where segments are allocated from,
> > > the segment lengths, the memory attributes like external buffers,
> > > registered for DMA, etc.
> > >
>
> [..snip..]
>
> > > For example, let's suppose we configured the Rx queue with the
> > > following segments:
> > > seg0 - pool0, len0=14B, off0=2
> > > seg1 - pool1, len1=20B, off1=128B
> > > seg2 - pool2, len2=20B, off2=0B
> > > seg3 - pool3, len3=512B, off3=0B
> >
> >
> > Sorry for chime in late. This API lookout looks good to me.
> > But, I am wondering how the application can know the capability or "limits" of
> > struct rte_eth_rxseg structure for the specific PMD. The other descriptor limit,
> > it's being exposed with struct rte_eth_dev_info::rx_desc_lim; If PMD can
> > support a specific pattern rather than returning the blanket error, the
> > application should know the limit.
> > IMO, it is better to add
> > struct rte_eth_rxseg *rxsegs;
> > unint16_t nb_max_rxsegs
> > in rte_eth_dev_info structure to express the capablity.
> > Where the en and offset can define the max offset.
> >
> > Thoughts?
>
> Moreover, there might be implied a lot of various limitations - offsets might be not supported at all or
> have some requirements for alignment, the similar requirements might be applied to segment size
> (say, ask for some granularity). Currently it is not obvious how to report all nuances, and it is supposed
> the limitations of this kind must be documented in PMD chapter. As for mlx5 - it has no special
> limitations besides common requirements to the regular segments.
Reporting the limitation in the documentation will not help for the
generic applications.
>
> One more point - the split feature might be considered as just one of possible cases of using
> these segment descriptions, other features might impose other (unknown for now) limitations.
> If we see some of the features of such kind or other PMDs adopts the split feature - we'll try to find
> the common root and consider the way how to report it.
My only concern with that approach will be ABI break again if
something needs to exposed over rte_eth_dev_info().
IMO, if we featured needs to completed only when its capabilities are
exposed in a programmatic manner.
As of mlx5, if there not limitation then info
rte_eth_dev_info::rxsegs[x].len, offset etc as UINT16_MAX so
that application is aware of the state.
>
> With best regards, Slava
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 2/5] ethdev: add new attributes to hairpin config
@ 2020-10-15 5:35 4% ` Bing Zhao
0 siblings, 0 replies; 200+ results
From: Bing Zhao @ 2020-10-15 5:35 UTC (permalink / raw)
To: thomas, orika, ferruh.yigit, arybchenko, mdr, nhorman,
bernard.iremonger, beilei.xing, wenzhuo.lu
Cc: dev
To support two ports hairpin mode and keep the backward compatibility
for the application, two new attribute members of the hairpin queue
configuration structure will be added.
`tx_explicit` means if the application itself will insert the TX part
flow rules. If not set, PMD will insert the rules implicitly.
`manual_bind` means if the hairpin TX queue and peer RX queue will be
bound automatically during the device start stage.
Different TX and RX queue pairs could have different values, but it
is highly recommended that all paired queues between one egress and
its peer ingress ports have the same values, in order not to bring
any chaos to the system. The actual support of these attribute
parameters will be checked and decided by the PMD drivers.
In the single port hairpin, if both are zero without any setting, the
behavior will remain the same as before. It means that no bind API
needs to be called and no TX flow rules need to be inserted manually
by the application.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
v4: squash document update and more info for the two new attributes
v2: optimize the structure and remove unused macros
---
doc/guides/prog_guide/rte_flow.rst | 3 +++
doc/guides/rel_notes/release_20_11.rst | 6 ++++++
lib/librte_ethdev/rte_ethdev.c | 8 ++++----
lib/librte_ethdev/rte_ethdev.h | 27 ++++++++++++++++++++++++++-
4 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index f26a6c2..c6f828a 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2592,6 +2592,9 @@ set, unpredictable value will be seen depending on driver implementation. For
loopback/hairpin packet, metadata set on Rx/Tx may or may not be propagated to
the other path depending on HW capability.
+In hairpin case with TX explicit flow mode, metadata could (not mandatory) be
+used to connect the RX and TX flows if it can be propagated from RX to TX path.
+
.. _table_rte_flow_action_set_meta:
.. table:: SET_META
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 0a9ae54..2e7dc2d 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -70,6 +70,7 @@ New Features
* **Updated the ethdev library to support hairpin between two ports.**
New APIs are introduced to support binding / unbinding 2 ports hairpin.
+ Hairpin TX part flow rules can be inserted explicitly.
* **Updated Broadcom bnxt driver.**
@@ -355,6 +356,11 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+ * ``struct rte_eth_hairpin_conf`` has two new members:
+
+ * ``uint32_t tx_explicit:1;``
+ * ``uint32_t manual_bind:1;``
+
Known Issues
------------
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 150c555..3cde7a7 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2004,13 +2004,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_rx_2_tx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Rx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_rx_2_tx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Rx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
@@ -2175,13 +2175,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_tx_2_rx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Tx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_tx_2_rx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Tx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 3bdb189..dabbbd4 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1045,7 +1045,32 @@ struct rte_eth_hairpin_peer {
* A structure used to configure hairpin binding.
*/
struct rte_eth_hairpin_conf {
- uint16_t peer_count; /**< The number of peers. */
+ uint32_t peer_count:16; /**< The number of peers. */
+
+ /**
+ * Explicit TX flow rule mode. One hairpin pair of queues should have
+ * the same attribute. The actual support depends on the PMD.
+ *
+ * - When set, the user should be responsible for inserting the hairpin
+ * TX part flows and removing them.
+ * - When clear, the PMD will try to handle the TX part of the flows,
+ * e.g., by splitting one flow into two parts.
+ */
+ uint32_t tx_explicit:1;
+
+ /**
+ * Manually bind hairpin queues. One hairpin pair of queues should have
+ * the same attribute. The actual support depends on the PMD.
+ *
+ * - When set, to enable hairpin, the user should call the hairpin bind
+ * API after all the queues are set up properly and the ports are
+ * started. Also, the hairpin unbind API should be called accordingly
+ * before stopping a port that with hairpin configured.
+ * - When clear, the PMD will try to enable the hairpin with the queues
+ * configured automatically during port start.
+ */
+ uint32_t manual_bind:1;
+ uint32_t reserved:14; /**< Reserved bits. */
struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
};
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] security: update session create API
2020-10-14 18:56 2% ` [dpdk-dev] [PATCH v3] " Akhil Goyal
@ 2020-10-15 1:11 0% ` Lukasz Wojciechowski
0 siblings, 0 replies; 200+ results
From: Lukasz Wojciechowski @ 2020-10-15 1:11 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, mdr, anoobj, hemant.agrawal, konstantin.ananyev,
declan.doherty, radu.nicolau, david.coyle,
"'Lukasz Wojciechowski'",
Hi Akhil,
thank you for responding to review and for v3.
You patch currently does not apply:
dpdk$ git apply v3-security-update-session-create-API.patch
error: patch failed: doc/guides/rel_notes/deprecation.rst:164
error: doc/guides/rel_notes/deprecation.rst: patch does not apply
error: patch failed: doc/guides/rel_notes/release_20_11.rst:344
error: doc/guides/rel_notes/release_20_11.rst: patch does not apply
and I'm sorry but there are still few things - see inline comments
W dniu 14.10.2020 o 20:56, Akhil Goyal pisze:
> The API ``rte_security_session_create`` takes only single
> mempool for session and session private data. So the
> application need to create mempool for twice the number of
> sessions needed and will also lead to wastage of memory as
> session private data need more memory compared to session.
> Hence the API is modified to take two mempool pointers
> - one for session and one for private data.
> This is very similar to crypto based session create APIs.
>
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
> Changes in v3:
> fixed checkpatch issues.
> Added new test in test_security.c for priv_mempool
>
> Changes in V2:
> incorporated comments from Lukasz and David.
>
> app/test-crypto-perf/cperf_ops.c | 4 +-
> app/test-crypto-perf/main.c | 12 +-
> app/test/test_cryptodev.c | 18 ++-
> app/test/test_ipsec.c | 3 +-
> app/test/test_security.c | 160 ++++++++++++++++++++++---
> doc/guides/prog_guide/rte_security.rst | 8 +-
> doc/guides/rel_notes/deprecation.rst | 7 --
> doc/guides/rel_notes/release_20_11.rst | 6 +
> examples/ipsec-secgw/ipsec-secgw.c | 12 +-
> examples/ipsec-secgw/ipsec.c | 9 +-
> lib/librte_security/rte_security.c | 7 +-
> lib/librte_security/rte_security.h | 4 +-
> 12 files changed, 196 insertions(+), 54 deletions(-)
>
> diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
> index 3da835a9c..3a64a2c34 100644
> --- a/app/test-crypto-perf/cperf_ops.c
> +++ b/app/test-crypto-perf/cperf_ops.c
> @@ -621,7 +621,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
>
> /* Create security session */
> return (void *)rte_security_session_create(ctx,
> - &sess_conf, sess_mp);
> + &sess_conf, sess_mp, priv_mp);
> }
> if (options->op_type == CPERF_DOCSIS) {
> enum rte_security_docsis_direction direction;
> @@ -664,7 +664,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
>
> /* Create security session */
> return (void *)rte_security_session_create(ctx,
> - &sess_conf, priv_mp);
> + &sess_conf, sess_mp, priv_mp);
> }
> #endif
> sess = rte_cryptodev_sym_session_create(sess_mp);
> diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
> index 62ae6048b..53864ffdd 100644
> --- a/app/test-crypto-perf/main.c
> +++ b/app/test-crypto-perf/main.c
> @@ -156,7 +156,14 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
> if (sess_size > max_sess_size)
> max_sess_size = sess_size;
> }
> -
> +#ifdef RTE_LIBRTE_SECURITY
> + for (cdev_id = 0; cdev_id < rte_cryptodev_count(); cdev_id++) {
> + sess_size = rte_security_session_get_size(
> + rte_cryptodev_get_sec_ctx(cdev_id));
> + if (sess_size > max_sess_size)
> + max_sess_size = sess_size;
> + }
> +#endif
> /*
> * Calculate number of needed queue pairs, based on the amount
> * of available number of logical cores and crypto devices.
> @@ -247,8 +254,7 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
> opts->nb_qps * nb_slaves;
> #endif
> } else
> - sessions_needed = enabled_cdev_count *
> - opts->nb_qps * 2;
> + sessions_needed = enabled_cdev_count * opts->nb_qps;
>
> /*
> * A single session is required per queue pair
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> index c7975ed01..9f1b92c51 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -773,9 +773,15 @@ testsuite_setup(void)
> unsigned int session_size =
> rte_cryptodev_sym_get_private_session_size(dev_id);
>
> +#ifdef RTE_LIBRTE_SECURITY
> + unsigned int security_session_size = rte_security_session_get_size(
> + rte_cryptodev_get_sec_ctx(dev_id));
> +
> + if (session_size < security_session_size)
> + session_size = security_session_size;
> +#endif
> /*
> - * Create mempool with maximum number of sessions * 2,
> - * to include the session headers
> + * Create mempool with maximum number of sessions.
> */
> if (info.sym.max_nb_sessions != 0 &&
> info.sym.max_nb_sessions < MAX_NB_SESSIONS) {
> @@ -7751,7 +7757,8 @@ test_pdcp_proto(int i, int oop,
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx,
> - &sess_conf, ts_params->session_priv_mpool);
> + &sess_conf, ts_params->session_mpool,
> + ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> printf("TestCase %s()-%d line %d failed %s: ",
> @@ -8011,7 +8018,8 @@ test_pdcp_proto_SGL(int i, int oop,
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx,
> - &sess_conf, ts_params->session_priv_mpool);
> + &sess_conf, ts_params->session_mpool,
> + ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> printf("TestCase %s()-%d line %d failed %s: ",
> @@ -8368,6 +8376,7 @@ test_docsis_proto_uplink(int i, struct docsis_test_data *d_td)
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
> + ts_params->session_mpool,
> ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> @@ -8543,6 +8552,7 @@ test_docsis_proto_downlink(int i, struct docsis_test_data *d_td)
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
> + ts_params->session_mpool,
> ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> index 79d00d7e0..9ad07a179 100644
> --- a/app/test/test_ipsec.c
> +++ b/app/test/test_ipsec.c
> @@ -632,7 +632,8 @@ create_dummy_sec_session(struct ipsec_unitest_params *ut,
> static struct rte_security_session_conf conf;
>
> ut->ss[j].security.ses = rte_security_session_create(&dummy_sec_ctx,
> - &conf, qp->mp_session_private);
> + &conf, qp->mp_session,
> + qp->mp_session_private);
>
> if (ut->ss[j].security.ses == NULL)
> return -ENOMEM;
> diff --git a/app/test/test_security.c b/app/test/test_security.c
> index 77fd5adc6..35ed6ff10 100644
> --- a/app/test/test_security.c
> +++ b/app/test/test_security.c
> @@ -200,6 +200,24 @@
> expected_mempool_usage, mempool_usage); \
> } while (0)
>
> +/**
> + * Verify usage of mempool by checking if number of allocated objects matches
> + * expectations. The mempool is used to manage objects for sessions priv data.
> + * A single object is acquired from mempool during session_create
> + * and put back in session_destroy.
> + *
> + * @param expected_priv_mp_usage expected number of used priv mp objects
> + */
> +#define TEST_ASSERT_PRIV_MP_USAGE(expected_priv_mp_usage) do { \
> + struct security_testsuite_params *ts_params = &testsuite_params;\
> + unsigned int priv_mp_usage; \
> + priv_mp_usage = rte_mempool_in_use_count( \
> + ts_params->session_priv_mpool); \
> + TEST_ASSERT_EQUAL(expected_priv_mp_usage, priv_mp_usage, \
> + "Expecting %u priv mempool allocations, " \
one tab less
> + "but there are %u allocated objects", \
> + expected_priv_mp_usage, priv_mp_usage); \
> +} while (0)
>
> /**
> * Mockup structures and functions for rte_security_ops;
> @@ -237,27 +255,38 @@ static struct mock_session_create_data {
> struct rte_security_session_conf *conf;
> struct rte_security_session *sess;
> struct rte_mempool *mp;
> + struct rte_mempool *priv_mp;
>
> int ret;
>
> int called;
> int failed;
> -} mock_session_create_exp = {NULL, NULL, NULL, NULL, 0, 0, 0};
> +} mock_session_create_exp = {NULL, NULL, NULL, NULL, NULL, 0, 0, 0};
>
> static int
> mock_session_create(void *device,
> struct rte_security_session_conf *conf,
> struct rte_security_session *sess,
> - struct rte_mempool *mp)
> + struct rte_mempool *priv_mp)
> {
> + void *sess_priv;
> + int ret;
> +
> mock_session_create_exp.called++;
>
> MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, device);
> MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, conf);
> - MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, mp);
> + MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, priv_mp);
> + ret = rte_mempool_get(priv_mp, &sess_priv);
> + TEST_ASSERT_EQUAL(0, ret,
> + "priv mempool does not have enough objects");
>
> + set_sec_session_private_data(sess, sess_priv);
if op function doesn't return 0, it shouldn't leave also sess_priv set
in sess.
Maybe put the code for getting sess_priv from mempool and setting it in
session inside:
if (mock_session_create_exp.ret == 0) {
...
}
> mock_session_create_exp.sess = sess;
>
> + if (mock_session_create_exp.ret != 0)
> + rte_mempool_put(priv_mp, sess_priv);
> +
> return mock_session_create_exp.ret;
> }
>
> @@ -363,8 +392,10 @@ static struct mock_session_destroy_data {
> static int
> mock_session_destroy(void *device, struct rte_security_session *sess)
> {
> - mock_session_destroy_exp.called++;
> + void *sess_priv = get_sec_session_private_data(sess);
>
> + mock_session_destroy_exp.called++;
> + rte_mempool_put(rte_mempool_from_obj(sess_priv), sess_priv);
sess_priv should be released only if op function is going to succeed.
You can check that in similar way as you did in create op by checking
mock_session_destroy_exp.ret
Otherwise testcase test_session_destroy_ops_failure might cause a
problem because your are putting same object twice into the mempool
(once in mock_session_destroy and 2nd time in ut_teardown when session
is destroyed)
> MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_destroy_exp, device);
> MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_destroy_exp, sess);
>
> @@ -502,6 +533,7 @@ struct rte_security_ops mock_ops = {
> */
> static struct security_testsuite_params {
> struct rte_mempool *session_mpool;
> + struct rte_mempool *session_priv_mpool;
> } testsuite_params = { NULL };
>
> /**
> @@ -524,9 +556,11 @@ static struct security_unittest_params {
> .sess = NULL,
> };
>
> -#define SECURITY_TEST_MEMPOOL_NAME "SecurityTestsMempoolName"
> +#define SECURITY_TEST_MEMPOOL_NAME "SecurityTestMp"
> +#define SECURITY_TEST_PRIV_MEMPOOL_NAME "SecurityTestPrivMp"
> #define SECURITY_TEST_MEMPOOL_SIZE 15
> -#define SECURITY_TEST_SESSION_OBJECT_SIZE sizeof(struct rte_security_session)
> +#define SECURITY_TEST_SESSION_OBJ_SZ sizeof(struct rte_security_session)
> +#define SECURITY_TEST_SESSION_PRIV_OBJ_SZ 64
>
> /**
> * testsuite_setup initializes whole test suite parameters.
> @@ -540,11 +574,27 @@ testsuite_setup(void)
> ts_params->session_mpool = rte_mempool_create(
> SECURITY_TEST_MEMPOOL_NAME,
> SECURITY_TEST_MEMPOOL_SIZE,
> - SECURITY_TEST_SESSION_OBJECT_SIZE,
> + SECURITY_TEST_SESSION_OBJ_SZ,
> 0, 0, NULL, NULL, NULL, NULL,
> SOCKET_ID_ANY, 0);
> TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
> "Cannot create mempool %s\n", rte_strerror(rte_errno));
> +
> + ts_params->session_priv_mpool = rte_mempool_create(
> + SECURITY_TEST_PRIV_MEMPOOL_NAME,
> + SECURITY_TEST_MEMPOOL_SIZE,
> + SECURITY_TEST_SESSION_PRIV_OBJ_SZ,
> + 0, 0, NULL, NULL, NULL, NULL,
> + SOCKET_ID_ANY, 0);
> + if (ts_params->session_priv_mpool == NULL) {
> + RTE_LOG(ERR, USER1, "TestCase %s() line %d failed (null): "
> + "Cannot create priv mempool %s\n",
> + __func__, __LINE__, rte_strerror(rte_errno));
> + rte_mempool_free(ts_params->session_mpool);
> + ts_params->session_mpool = NULL;
> + return TEST_FAILED;
> + }
> +
> return TEST_SUCCESS;
> }
>
> @@ -559,6 +609,10 @@ testsuite_teardown(void)
> rte_mempool_free(ts_params->session_mpool);
> ts_params->session_mpool = NULL;
> }
> + if (ts_params->session_priv_mpool) {
> + rte_mempool_free(ts_params->session_priv_mpool);
> + ts_params->session_priv_mpool = NULL;
> + }
> }
>
> /**
> @@ -656,10 +710,12 @@ ut_setup_with_session(void)
> mock_session_create_exp.device = NULL;
> mock_session_create_exp.conf = &ut_params->conf;
> mock_session_create_exp.mp = ts_params->session_mpool;
> + mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
> mock_session_create_exp.ret = 0;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
> sess);
> TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
> @@ -701,11 +757,13 @@ test_session_create_inv_context(void)
> struct rte_security_session *sess;
>
> sess = rte_security_session_create(NULL, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> return TEST_SUCCESS;
> @@ -725,11 +783,13 @@ test_session_create_inv_context_ops(void)
> ut_params->ctx.ops = NULL;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> return TEST_SUCCESS;
> @@ -749,11 +809,13 @@ test_session_create_inv_context_ops_fun(void)
> ut_params->ctx.ops = &empty_ops;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> return TEST_SUCCESS;
> @@ -770,18 +832,21 @@ test_session_create_inv_configuration(void)
> struct rte_security_session *sess;
>
> sess = rte_security_session_create(&ut_params->ctx, NULL,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> return TEST_SUCCESS;
> }
>
> /**
> - * Test execution of rte_security_session_create with NULL mp parameter
> + * Test execution of rte_security_session_create with NULL session
> + * mempool
> */
> static int
> test_session_create_inv_mempool(void)
> @@ -790,11 +855,35 @@ test_session_create_inv_mempool(void)
> struct rte_security_session *sess;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - NULL);
> + NULL, NULL);
...NULL, ts_params->session_priv_mpool); would be better as it would
test if making primary mempool NULL is the cause of session_create failure.
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> + TEST_ASSERT_SESSION_COUNT(0);
> +
> + return TEST_SUCCESS;
> +}
> +
> +/**
> + * Test execution of rte_security_session_create with NULL session
> + * priv mempool
> + */
> +static int
> +test_session_create_inv_sess_priv_mempool(void)
> +{
> + struct security_unittest_params *ut_params = &unittest_params;
> + struct security_testsuite_params *ts_params = &testsuite_params;
> + struct rte_security_session *sess;
> +
> + sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> + ts_params->session_mpool, NULL);
> + TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> + sess, NULL, "%p");
> + TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> + TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> return TEST_SUCCESS;
> @@ -810,6 +899,7 @@ test_session_create_mempool_empty(void)
> struct security_testsuite_params *ts_params = &testsuite_params;
> struct security_unittest_params *ut_params = &unittest_params;
> struct rte_security_session *tmp[SECURITY_TEST_MEMPOOL_SIZE];
> + void *tmp1[SECURITY_TEST_MEMPOOL_SIZE];
> struct rte_security_session *sess;
>
> /* Get all available objects from mempool. */
> @@ -820,21 +910,34 @@ test_session_create_mempool_empty(void)
> TEST_ASSERT_EQUAL(0, ret,
> "Expect getting %d object from mempool"
> " to succeed", i);
> + ret = rte_mempool_get(ts_params->session_priv_mpool,
> + (void **)(&tmp1[i]));
> + TEST_ASSERT_EQUAL(0, ret,
> + "Expect getting %d object from priv mempool"
> + " to succeed", i);
> }
> TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
> + TEST_ASSERT_PRIV_MP_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
> + TEST_ASSERT_PRIV_MP_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
> TEST_ASSERT_SESSION_COUNT(0);
>
> /* Put objects back to the pool. */
> - for (i = 0; i < SECURITY_TEST_MEMPOOL_SIZE; ++i)
> - rte_mempool_put(ts_params->session_mpool, (void *)(tmp[i]));
> + for (i = 0; i < SECURITY_TEST_MEMPOOL_SIZE; ++i) {
> + rte_mempool_put(ts_params->session_mpool,
> + (void *)(tmp[i]));
> + rte_mempool_put(ts_params->session_priv_mpool,
> + (tmp1[i]));
> + }
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
>
> return TEST_SUCCESS;
> }
> @@ -853,14 +956,17 @@ test_session_create_ops_failure(void)
> mock_session_create_exp.device = NULL;
> mock_session_create_exp.conf = &ut_params->conf;
> mock_session_create_exp.mp = ts_params->session_mpool;
> + mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
> mock_session_create_exp.ret = -1; /* Return failure status. */
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> return TEST_SUCCESS;
> @@ -879,10 +985,12 @@ test_session_create_success(void)
> mock_session_create_exp.device = NULL;
> mock_session_create_exp.conf = &ut_params->conf;
> mock_session_create_exp.mp = ts_params->session_mpool;
> + mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
> mock_session_create_exp.ret = 0; /* Return success status. */
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
> sess);
> TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
> @@ -891,6 +999,7 @@ test_session_create_success(void)
> sess, mock_session_create_exp.sess);
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> /*
> @@ -1276,6 +1385,7 @@ test_session_destroy_inv_context(void)
> struct security_unittest_params *ut_params = &unittest_params;
>
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> int ret = rte_security_session_destroy(NULL, ut_params->sess);
> @@ -1283,6 +1393,7 @@ test_session_destroy_inv_context(void)
> ret, -EINVAL, "%d");
> TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> return TEST_SUCCESS;
> @@ -1299,6 +1410,7 @@ test_session_destroy_inv_context_ops(void)
> ut_params->ctx.ops = NULL;
>
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> int ret = rte_security_session_destroy(&ut_params->ctx,
> @@ -1307,6 +1419,7 @@ test_session_destroy_inv_context_ops(void)
> ret, -EINVAL, "%d");
> TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> return TEST_SUCCESS;
> @@ -1323,6 +1436,7 @@ test_session_destroy_inv_context_ops_fun(void)
> ut_params->ctx.ops = &empty_ops;
>
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> int ret = rte_security_session_destroy(&ut_params->ctx,
> @@ -1331,6 +1445,7 @@ test_session_destroy_inv_context_ops_fun(void)
> ret, -ENOTSUP, "%d");
> TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> return TEST_SUCCESS;
> @@ -1345,6 +1460,7 @@ test_session_destroy_inv_session(void)
> struct security_unittest_params *ut_params = &unittest_params;
>
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> int ret = rte_security_session_destroy(&ut_params->ctx, NULL);
> @@ -1352,6 +1468,7 @@ test_session_destroy_inv_session(void)
> ret, -EINVAL, "%d");
> TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> return TEST_SUCCESS;
> @@ -1371,6 +1488,7 @@ test_session_destroy_ops_failure(void)
> mock_session_destroy_exp.ret = -1;
>
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> int ret = rte_security_session_destroy(&ut_params->ctx,
You can add also:
TEST_ASSERT_PRIV_MP_USAGE(1);
in line 1500 after rte_security_session_destroy() returned to verify
that private mempool usage stays on same level after failure of destroy op.
Currently adding it without fixing mock of session_destroy op, will
cause test failure:
EAL: Test assert test_session_destroy_ops_failure line 1500 failed:
Expecting 1 priv mempool allocations, but there are 0 allocated objects
EAL: in ../app/test/test_security.c:1500 test_session_destroy_ops_failure
> @@ -1396,6 +1514,7 @@ test_session_destroy_success(void)
> mock_session_destroy_exp.sess = ut_params->sess;
> mock_session_destroy_exp.ret = 0;
> TEST_ASSERT_MEMPOOL_USAGE(1);
> + TEST_ASSERT_PRIV_MP_USAGE(1);
> TEST_ASSERT_SESSION_COUNT(1);
>
> int ret = rte_security_session_destroy(&ut_params->ctx,
> @@ -1404,6 +1523,7 @@ test_session_destroy_success(void)
> ret, 0, "%d");
> TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 1);
> TEST_ASSERT_MEMPOOL_USAGE(0);
> + TEST_ASSERT_PRIV_MP_USAGE(0);
> TEST_ASSERT_SESSION_COUNT(0);
>
> /*
> @@ -2370,6 +2490,8 @@ static struct unit_test_suite security_testsuite = {
> test_session_create_inv_configuration),
> TEST_CASE_ST(ut_setup, ut_teardown,
> test_session_create_inv_mempool),
> + TEST_CASE_ST(ut_setup, ut_teardown,
> + test_session_create_inv_sess_priv_mempool),
> TEST_CASE_ST(ut_setup, ut_teardown,
> test_session_create_mempool_empty),
> TEST_CASE_ST(ut_setup, ut_teardown,
> diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
> index 127da2e4f..d30a79576 100644
> --- a/doc/guides/prog_guide/rte_security.rst
> +++ b/doc/guides/prog_guide/rte_security.rst
> @@ -533,8 +533,12 @@ and this allows further acceleration of the offload of Crypto workloads.
>
> The Security framework provides APIs to create and free sessions for crypto/ethernet
> devices, where sessions are mempool objects. It is the application's responsibility
> -to create and manage the session mempools. The mempool object size should be able to
> -accommodate the driver's private data of security session.
> +to create and manage two session mempools - one for session and other for session
> +private data. The private session data mempool object size should be able to
> +accommodate the driver's private data of security session. The application can get
> +the size of session private data using API ``rte_security_session_get_size``.
> +And the session mempool object size should be enough to accommodate
> +``rte_security_session``.
>
> Once the session mempools have been created, ``rte_security_session_create()``
> is used to allocate and initialize a session for the required crypto/ethernet device.
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 43cdd3c58..26be1b3de 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -164,13 +164,6 @@ Deprecation Notices
> following the IPv6 header, as proposed in RFC
> https://protect2.fireeye.com/v1/url?k=0ff8f153-529fb575-0ff97a1c-0cc47a31384a-da56d065c0f960ba&q=1&e=4b8cafbf-ec0f-4a52-9c77-e1c5a4efcfc5&u=https%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2020-August%2F177257.html.
>
> -* security: The API ``rte_security_session_create`` takes only single mempool
> - for session and session private data. So the application need to create
> - mempool for twice the number of sessions needed and will also lead to
> - wastage of memory as session private data need more memory compared to session.
> - Hence the API will be modified to take two mempool pointers - one for session
> - and one for private data.
> -
> * cryptodev: support for using IV with all sizes is added, J0 still can
> be used but only when IV length in following structs ``rte_crypto_auth_xform``,
> ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
> index f1b9b4dfe..0fb1b20cb 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -344,6 +344,12 @@ API Changes
> * The structure ``rte_crypto_sym_vec`` is updated to support both
> cpu_crypto synchrounous operation and asynchronous raw data-path APIs.
>
> +* security: The API ``rte_security_session_create`` is updated to take two
> + mempool objects one for session and other for session private data.
> + So the application need to create two mempools and get the size of session
> + private data using API ``rte_security_session_get_size`` for private session
> + mempool.
> +
>
> ABI Changes
> -----------
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> index 60132c4bd..2326089bb 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -2348,12 +2348,8 @@ session_pool_init(struct socket_ctx *ctx, int32_t socket_id, size_t sess_sz)
>
> snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
> "sess_mp_%u", socket_id);
> - /*
> - * Doubled due to rte_security_session_create() uses one mempool for
> - * session and for session private data.
> - */
> nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
> - rte_lcore_count()) * 2;
> + rte_lcore_count());
> sess_mp = rte_cryptodev_sym_session_pool_create(
> mp_name, nb_sess, sess_sz, CDEV_MP_CACHE_SZ, 0,
> socket_id);
> @@ -2376,12 +2372,8 @@ session_priv_pool_init(struct socket_ctx *ctx, int32_t socket_id,
>
> snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
> "sess_mp_priv_%u", socket_id);
> - /*
> - * Doubled due to rte_security_session_create() uses one mempool for
> - * session and for session private data.
> - */
> nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
> - rte_lcore_count()) * 2;
> + rte_lcore_count());
> sess_mp = rte_mempool_create(mp_name,
> nb_sess,
> sess_sz,
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 01faa7ac7..6baeeb342 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -117,7 +117,8 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
> set_ipsec_conf(sa, &(sess_conf.ipsec));
>
> ips->security.ses = rte_security_session_create(ctx,
> - &sess_conf, ipsec_ctx->session_priv_pool);
> + &sess_conf, ipsec_ctx->session_pool,
> + ipsec_ctx->session_priv_pool);
> if (ips->security.ses == NULL) {
> RTE_LOG(ERR, IPSEC,
> "SEC Session init failed: err: %d\n", ret);
> @@ -198,7 +199,8 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> }
>
> ips->security.ses = rte_security_session_create(sec_ctx,
> - &sess_conf, skt_ctx->session_pool);
> + &sess_conf, skt_ctx->session_pool,
> + skt_ctx->session_priv_pool);
> if (ips->security.ses == NULL) {
> RTE_LOG(ERR, IPSEC,
> "SEC Session init failed: err: %d\n", ret);
> @@ -378,7 +380,8 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> sess_conf.userdata = (void *) sa;
>
> ips->security.ses = rte_security_session_create(sec_ctx,
> - &sess_conf, skt_ctx->session_pool);
> + &sess_conf, skt_ctx->session_pool,
> + skt_ctx->session_priv_pool);
> if (ips->security.ses == NULL) {
> RTE_LOG(ERR, IPSEC,
> "SEC Session init failed: err: %d\n", ret);
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 515c29e04..ee4666026 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -26,18 +26,21 @@
> struct rte_security_session *
> rte_security_session_create(struct rte_security_ctx *instance,
> struct rte_security_session_conf *conf,
> - struct rte_mempool *mp)
> + struct rte_mempool *mp,
> + struct rte_mempool *priv_mp)
> {
> struct rte_security_session *sess = NULL;
>
> RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_create, NULL, NULL);
> RTE_PTR_OR_ERR_RET(conf, NULL);
> RTE_PTR_OR_ERR_RET(mp, NULL);
> + RTE_PTR_OR_ERR_RET(priv_mp, NULL);
>
> if (rte_mempool_get(mp, (void **)&sess))
> return NULL;
>
> - if (instance->ops->session_create(instance->device, conf, sess, mp)) {
> + if (instance->ops->session_create(instance->device, conf,
> + sess, priv_mp)) {
> rte_mempool_put(mp, (void *)sess);
> return NULL;
> }
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 16839e539..1710cdd6a 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -386,6 +386,7 @@ struct rte_security_session {
> * @param instance security instance
> * @param conf session configuration parameters
> * @param mp mempool to allocate session objects from
> + * @param priv_mp mempool to allocate session private data objects from
> * @return
> * - On success, pointer to session
> * - On failure, NULL
> @@ -393,7 +394,8 @@ struct rte_security_session {
> struct rte_security_session *
> rte_security_session_create(struct rte_security_ctx *instance,
> struct rte_security_session_conf *conf,
> - struct rte_mempool *mp);
> + struct rte_mempool *mp,
> + struct rte_mempool *priv_mp);
>
> /**
> * Update security session as specified by the session configuration
--
Lukasz Wojciechowski
Principal Software Engineer
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/8] crypto/bcmfs: add BCMFS driver
@ 2020-10-15 0:55 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-10-15 0:55 UTC (permalink / raw)
To: akhil.goyal, Raveendra Padasalagi, Vikas Gupta, ajit.khaparde
Cc: dev, vikram.prakash, mdr
07/10/2020 19:18, Vikas Gupta:
> --- /dev/null
> +++ b/drivers/crypto/bcmfs/rte_pmd_bcmfs_version.map
> @@ -0,0 +1,3 @@
> +DPDK_21.0 {
> + local: *;
> +};
No!
Please be careful, all other libs use ABI DPDK_21.
Will fix
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-14 13:10 0% ` Medvedkin, Vladimir
@ 2020-10-14 23:57 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2020-10-14 23:57 UTC (permalink / raw)
To: Medvedkin, Vladimir, Michel Machado, Kevin Traynor, Ruifeng Wang,
Bruce Richardson, Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, nd, Honnappa Nagarahalli, nd
<snip>
> >>
> >>
> >> On 13/10/2020 18:46, Michel Machado wrote:
> >>> On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
> >>>> Hi Michel,
> >>>>
> >>>> Could you please describe a condition when LPM gets inconsistent?
> >>>> As I can see if there is no free tbl8 it will return -ENOSPC.
> >>>
> >>> Consider this simple example, we need to add the following two
> >>> prefixes with different next hops: 10.99.0.0/16, 18.99.99.128/25. If
> >>> the LPM table is out of tbl8s, the second prefix is not added and
> >>> Gatekeeper will make decisions in violation of the policy. The data
> >>> structure of the LPM table is consistent, but its content
> >>> inconsistent with the policy.
max_rules and number_tbl8s in 'struct rte_lpm' contain the config information. These 2 fields do not change based on the routes added and do not indicate the amount of space left. So, you cannot use this information to decide if there is enough space to add more routes.
> >>
> >> Aha, thanks. So do I understand correctly that you need to add a set
> >> of routes atomically (either the entire set is installed or nothing)?
> >
> > Yes.
> >
> >> If so, then I would suggest having 2 lpm and switching them
> >> atomically after a successful addition. As for now, even if you have
> >> enough tbl8's, routes are installed non atomically, i.e. there will
> >> be a time gap between adding two routes, so in this time interval the
> >> table will be inconsistent with the policy.
> >> Also, if new lpm algorithms are added to the DPDK, they won't have
> >> such a thing as tbl8.
> >
> > Our code already deals with synchronization.
If the application code already deals with synchronization, is it possible to revert back (i.e. delete the routes that got added so far) when the addition of the route-set fails?
>
> OK, so my suggestion here would be to add new routes to the shadow copy
> of the lpm, and if it returns -ENOSPC, than create a new LPM with double
> amount of tbl8's and add all the routes to it. Then switch the active-shadow
> LPM pointers. In this case you'll always add a bulk of routes atomically.
>
> >
> >>> We minimize the need of replacing a LPM table by allocating LPM
> >>> tables with the double of what we need (see example here
> >>>
> https://github.com/AltraMayor/gatekeeper/blob/95d1d6e8201861a0d0c698
> >>> bfd06ad606674f1e07/lua/examples/policy.lua#L172-L183),
> >>> but the code must be ready for unexpected needs that may arise in
> >>> production.
> >>>
> >>
> >> Usually, the table is initialized with a large enough number of
> >> entries, enough to add a possible number of routes. One tbl8 group
> >> takes up 1Kb of memory which is nothing comparing to the size of
> >> tbl24 which is 64Mb.
> >
> > When the prefixes come from BGP, initializing a large enough table
> > is fine. But when prefixes come from threat intelligence, the number
> > of prefixes can vary wildly and the number of prefixes above 24 bits
> > are way more common.
> >
> >> P.S. consider using rte_fib library, it has a number of advantages
> >> over LPM. You can replace the loop in __lookup_fib_bulk() with a bulk
> >> lookup call and this will probably increase the speed.
> >
> > I'm not aware of the rte_fib library. The only documentation that
> > I found on Google was https://doc.dpdk.org/api/rte__fib_8h.html and it
> > just says "FIB (Forwarding information base) implementation for IPv4
> > Longest Prefix Match".
>
> That's true, I'm going to add programmer's guide soon.
> Although the fib API is very similar to existing LPM.
>
> >
> >>>>
> >>>> On 13/10/2020 15:58, Michel Machado wrote:
> >>>>> Hi Kevin,
> >>>>>
> >>>>> We do need fields max_rules and number_tbl8s of struct
> >>>>> rte_lpm, so the removal would force us to have another patch to
> >>>>> our local copy of DPDK. We'd rather avoid this new local patch
> >>>>> because we wish to eventually be in sync with the stock DPDK.
> >>>>>
> >>>>> Those fields are needed in Gatekeeper because we found a
> >>>>> condition in an ongoing deployment in which the entries of some
> >>>>> LPM tables may suddenly change a lot to reflect policy changes. To
> >>>>> avoid getting into a state in which the LPM table is inconsistent
> >>>>> because it cannot fit all the new entries, we compute the needed
> >>>>> parameters to support the new entries, and compare with the
> >>>>> current parameters. If the current table doesn't fit everything,
> >>>>> we have to replace it with a new LPM table.
> >>>>>
> >>>>> If there were a way to obtain the struct rte_lpm_config of a
> >>>>> given LPM table, it would cleanly address our need. We have the
> >>>>> same need in IPv6 and have a local patch to work around it (see
> >>>>>
> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db
> 26a78115cb8c8f).
I do not see why such an API is not possible, we could add one API that returns max_rules and number_tbl8s (essentially, the config that was passed to rte_lpm_create API).
But, is there a possibility to store that info in the application as that data was passed to rte_lpm from the application?
> >>>>> Thus, an IPv4 and IPv6 solution would be best.
> >>>>>
> >>>>> PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to
> >>>>> this disscussion.
> >>>>>
> >>>>> [ ]'s
> >>>>> Michel Machado
> >>>>>
> >>>>> On 10/13/20 9:53 AM, Kevin Traynor wrote:
> >>>>>> Hi Gatekeeper maintainers (I think),
> >>>>>>
> >>>>>> fyi - there is a proposal to remove some members of a struct in
> >>>>>> DPDK LPM API that Gatekeeper is using [1]. It would be only from
> >>>>>> DPDK 20.11 but as it's an LTS I guess it would probably hit
> >>>>>> Debian in a few months.
> >>>>>>
> >>>>>> The full thread is here:
> >>>>>> http://inbox.dpdk.org/dev/20200907081518.46350-1-
> ruifeng.wang@arm
> >>>>>> .com/
> >>>>>>
> >>>>>>
> >>>>>> Maybe you can take a look and tell us if they are needed in
> >>>>>> Gatekeeper or you can workaround it?
> >>>>>>
> >>>>>> thanks,
> >>>>>> Kevin.
> >>>>>>
> >>>>>> [1]
> >>>>>>
> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c
> >>>>>> #L235-L248
> >>>>>>
> >>>>>>
> >>>>>> On 09/10/2020 07:54, Ruifeng Wang wrote:
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Kevin Traynor <ktraynor@redhat.com>
> >>>>>>>> Sent: Wednesday, September 30, 2020 4:46 PM
> >>>>>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin,
> Vladimir
> >>>>>>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
> >>>>>>>> <bruce.richardson@intel.com>
> >>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
> >>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> >>>>>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
> >>>>>>>>
> >>>>>>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
> >>>>>>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
> >>>>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng
> >>>>>>>>>> Wang <Ruifeng.Wang@arm.com>
> >>>>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
> >>>>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> >>>>>>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
> >>>>>>>>>>
> >>>>>>>>>> Hi Ruifeng,
> >>>>>>>>>>
> >>>>>>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
> >>>>>>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang
> wrote:
> >>>>>>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no
> >>>>>>>>>>>> need to be exposed to the user.
> >>>>>>>>>>>> Hide the unneeded exposure of structure fields for better
> >>>>>>>>>>>> ABI maintainability.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Suggested-by: David Marchand
> <david.marchand@redhat.com>
> >>>>>>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
> >>>>>>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> lib/librte_lpm/rte_lpm.c | 152
> >>>>>>>>>>>> +++++++++++++++++++++++---------------
> >>>>>>>>>> -
> >>>>>>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
> >>>>>>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
> >>>>>>>>>>>>
> >>>>>>>>>>> <snip>
> >>>>>>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h
> >>>>>>>>>>>> b/lib/librte_lpm/rte_lpm.h index 03da2d37e..112d96f37
> >>>>>>>>>>>> 100644
> >>>>>>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
> >>>>>>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
> >>>>>>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
> >>>>>>>>>>>>
> >>>>>>>>>>>> /** @internal LPM structure. */
> >>>>>>>>>>>> struct rte_lpm {
> >>>>>>>>>>>> - /* LPM metadata. */
> >>>>>>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the
> >>>>>>>>>>>> lpm. */
> >>>>>>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm.
> >>>>>>>>>>>> */
> >>>>>>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
> >>>>>>>>>>>> - struct rte_lpm_rule_info
> rule_info[RTE_LPM_MAX_DEPTH];
> >>>>>>>>>>>> /**<
> >>>>>>>>>> Rule info table. */
> >>>>>>>>>>>> -
> >>>>>>>>>>>> /* LPM Tables. */
> >>>>>>>>>>>> struct rte_lpm_tbl_entry
> >>>>>>>>>>>> tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
> >>>>>>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table.
> >>>>>>>>>>>> */
> >>>>>>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table.
> >>>>>>>>>>>> */
> >>>>>>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
> >>>>>>>>>>>> };
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Since this changes the ABI, does it not need advance notice?
> >>>>>>>>>>>
> >>>>>>>>>>> [Basically the return value point from rte_lpm_create() will
> >>>>>>>>>>> be different, and that return value could be used by
> >>>>>>>>>>> rte_lpm_lookup()
> >>>>>>>>>>> which as a static inline function will be in the binary and
> >>>>>>>>>>> using the old structure offsets.]
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Agree with Bruce, this patch breaks ABI, so it can't be
> >>>>>>>>>> accepted without prior notice.
> >>>>>>>>>>
> >>>>>>>>> So if the change wants to happen in 20.11, a deprecation
> >>>>>>>>> notice should have been added in 20.08.
> >>>>>>>>> I should have added a deprecation notice. This change will
> >>>>>>>>> have to wait for
> >>>>>>>> next ABI update window.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Do you plan to extend? or is this just speculative?
> >>>>>>> It is speculative.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> A quick scan and there seems to be several projects using some
> >>>>>>>> of these
> >>>>>>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
> >>>>>>>> gatekeeper. I didn't look at the details to see if they are
> >>>>>>>> really needed.
> >>>>>>>>
> >>>>>>>> Not sure how much notice they'd need or if they update DPDK
> >>>>>>>> much, but I
> >>>>>>>> think it's worth having a closer look as to how they use lpm and
> >>>>>>>> what the
> >>>>>>>> impact to them is.
> >>>>>>> Checked the projects listed above. BESS, NFF-Go and DPVS don't
> >>>>>>> access the members to be hided.
> >>>>>>> They will not be impacted by this patch.
> >>>>>>> But Gatekeeper accesses the rte_lpm internal members that to be
> >>>>>>> hided. Its compilation will be broken with this patch.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> Thanks.
> >>>>>>>>> Ruifeng
> >>>>>>>>>>>> /** LPM RCU QSBR configuration structure. */
> >>>>>>>>>>>> --
> >>>>>>>>>>>> 2.17.1
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Regards,
> >>>>>>>>>> Vladimir
> >>>>>>>
> >>>>>>
> >>>>
> >>
>
> --
> Regards,
> Vladimir
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints
2020-10-14 21:36 9% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
@ 2020-10-14 21:36 2% ` Timothy McDaniel
2020-10-14 21:36 6% ` [dpdk-dev] [PATCH 2/2] eventdev: update app and examples for new eventdev ABI Timothy McDaniel
2020-10-15 14:26 7% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Jerin Jacob
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-14 21:36 UTC (permalink / raw)
To: Hemant Agrawal, Nipun Gupta, Mattias Rönnblom, Jerin Jacob,
Pavan Nikhilesh, Liang Ma, Peter Mccarthy, Harry van Haaren,
Nikhil Rao, Ray Kinsella, Neil Horman
Cc: dev, erik.g.carrillo, gage.eads
This commit implements the eventdev ABI changes required by
the DLB PMD.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
---
drivers/event/dpaa/dpaa_eventdev.c | 3 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
drivers/event/dsw/dsw_evdev.c | 3 +-
drivers/event/octeontx/ssovf_evdev.c | 5 +-
drivers/event/octeontx2/otx2_evdev.c | 3 +-
drivers/event/opdl/opdl_evdev.c | 3 +-
drivers/event/skeleton/skeleton_eventdev.c | 5 +-
drivers/event/sw/sw_evdev.c | 8 ++--
drivers/event/sw/sw_evdev_selftest.c | 6 +--
lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/librte_eventdev/rte_eventdev.c | 66 +++++++++++++++++++++++---
lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++++----
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
lib/librte_eventdev/rte_eventdev_trace.h | 7 +--
lib/librte_eventdev/rte_eventdev_version.map | 4 +-
15 files changed, 134 insertions(+), 38 deletions(-)
diff --git a/drivers/event/dpaa/dpaa_eventdev.c b/drivers/event/dpaa/dpaa_eventdev.c
index b5ae87a..07cd079 100644
--- a/drivers/event/dpaa/dpaa_eventdev.c
+++ b/drivers/event/dpaa/dpaa_eventdev.c
@@ -355,7 +355,8 @@ dpaa_event_dev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED |
RTE_EVENT_DEV_CAP_BURST_MODE |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static int
diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c b/drivers/event/dpaa2/dpaa2_eventdev.c
index 3ae4441..712db6c 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev.c
+++ b/drivers/event/dpaa2/dpaa2_eventdev.c
@@ -406,7 +406,8 @@ dpaa2_eventdev_info_get(struct rte_eventdev *dev,
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
RTE_EVENT_DEV_CAP_NONSEQ_MODE |
- RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES;
+ RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
@@ -536,7 +537,7 @@ dpaa2_eventdev_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
DPAA2_EVENT_MAX_PORT_DEQUEUE_DEPTH;
port_conf->enqueue_depth =
DPAA2_EVENT_MAX_PORT_ENQUEUE_DEPTH;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static int
diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
index e796975..933a5a5 100644
--- a/drivers/event/dsw/dsw_evdev.c
+++ b/drivers/event/dsw/dsw_evdev.c
@@ -224,7 +224,8 @@ dsw_info_get(struct rte_eventdev *dev __rte_unused,
.event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE|
RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED|
RTE_EVENT_DEV_CAP_NONSEQ_MODE|
- RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT
+ RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT|
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID
};
}
diff --git a/drivers/event/octeontx/ssovf_evdev.c b/drivers/event/octeontx/ssovf_evdev.c
index 4fc4e8f..1c6bcca 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -152,7 +152,8 @@ ssovf_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *dev_info)
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
@@ -218,7 +219,7 @@ ssovf_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = edev->max_num_events;
port_conf->dequeue_depth = 1;
port_conf->enqueue_depth = 1;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static void
diff --git a/drivers/event/octeontx2/otx2_evdev.c b/drivers/event/octeontx2/otx2_evdev.c
index b8b57c3..ae35bb5 100644
--- a/drivers/event/octeontx2/otx2_evdev.c
+++ b/drivers/event/octeontx2/otx2_evdev.c
@@ -501,7 +501,8 @@ otx2_sso_info_get(struct rte_eventdev *event_dev,
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static void
diff --git a/drivers/event/opdl/opdl_evdev.c b/drivers/event/opdl/opdl_evdev.c
index 9b2f75f..3050578 100644
--- a/drivers/event/opdl/opdl_evdev.c
+++ b/drivers/event/opdl/opdl_evdev.c
@@ -374,7 +374,8 @@ opdl_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
.max_event_port_dequeue_depth = MAX_OPDL_CONS_Q_DEPTH,
.max_event_port_enqueue_depth = MAX_OPDL_CONS_Q_DEPTH,
.max_num_events = OPDL_INFLIGHT_EVENTS_TOTAL,
- .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE,
+ .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID,
};
*info = evdev_opdl_info;
diff --git a/drivers/event/skeleton/skeleton_eventdev.c b/drivers/event/skeleton/skeleton_eventdev.c
index c889220..6fd1102 100644
--- a/drivers/event/skeleton/skeleton_eventdev.c
+++ b/drivers/event/skeleton/skeleton_eventdev.c
@@ -101,7 +101,8 @@ skeleton_eventdev_info_get(struct rte_eventdev *dev,
dev_info->max_num_events = (1ULL << 20);
dev_info->event_dev_cap = RTE_EVENT_DEV_CAP_QUEUE_QOS |
RTE_EVENT_DEV_CAP_BURST_MODE |
- RTE_EVENT_DEV_CAP_EVENT_QOS;
+ RTE_EVENT_DEV_CAP_EVENT_QOS |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
}
static int
@@ -209,7 +210,7 @@ skeleton_eventdev_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = 32 * 1024;
port_conf->dequeue_depth = 16;
port_conf->enqueue_depth = 16;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static void
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index 98dae71..058f568 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -175,7 +175,8 @@ sw_port_setup(struct rte_eventdev *dev, uint8_t port_id,
}
p->inflight_max = conf->new_event_threshold;
- p->implicit_release = !conf->disable_implicit_release;
+ p->implicit_release = !(conf->event_port_cfg &
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
/* check if ring exists, same as rx_worker above */
snprintf(buf, sizeof(buf), "sw%d_p%u, %s", dev->data->dev_id,
@@ -508,7 +509,7 @@ sw_port_def_conf(struct rte_eventdev *dev, uint8_t port_id,
port_conf->new_event_threshold = 1024;
port_conf->dequeue_depth = 16;
port_conf->enqueue_depth = 16;
- port_conf->disable_implicit_release = 0;
+ port_conf->event_port_cfg = 0;
}
static int
@@ -615,7 +616,8 @@ sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE|
RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
- RTE_EVENT_DEV_CAP_NONSEQ_MODE),
+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID),
};
*info = evdev_sw_info;
diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
index 38c21fa..4a7d823 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -172,7 +172,6 @@ create_ports(struct test *t, int num_ports)
.new_event_threshold = 1024,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (num_ports > MAX_PORTS)
return -1;
@@ -1227,7 +1226,6 @@ port_reconfig_credits(struct test *t)
.new_event_threshold = 128,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
printf("%d Error setting up port\n", __LINE__);
@@ -1317,7 +1315,6 @@ port_single_lb_reconfig(struct test *t)
.new_event_threshold = 128,
.dequeue_depth = 32,
.enqueue_depth = 64,
- .disable_implicit_release = 0,
};
if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
printf("%d Error setting up port\n", __LINE__);
@@ -3079,7 +3076,8 @@ worker_loopback(struct test *t, uint8_t disable_implicit_release)
* only be initialized once - and this needs to be set for multiple runs
*/
conf.new_event_threshold = 512;
- conf.disable_implicit_release = disable_implicit_release;
+ conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (rte_event_port_setup(evdev, 0, &conf) < 0) {
printf("Error setting up RX port\n");
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.c b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
index bb21dc4..8a72256 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
@@ -286,7 +286,7 @@ txa_service_conf_cb(uint8_t __rte_unused id, uint8_t dev_id,
return ret;
}
- pc->disable_implicit_release = 0;
+ pc->event_port_cfg = 0;
ret = rte_event_port_setup(dev_id, port_id, pc);
if (ret) {
RTE_EDEV_LOG_ERR("failed to setup event port %u\n",
diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
index 82c177c..3a5b738 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -32,6 +32,7 @@
#include <rte_ethdev.h>
#include <rte_cryptodev.h>
#include <rte_cryptodev_pmd.h>
+#include <rte_compat.h>
#include "rte_eventdev.h"
#include "rte_eventdev_pmd.h"
@@ -437,9 +438,29 @@ rte_event_dev_configure(uint8_t dev_id,
dev_id);
return -EINVAL;
}
- if (dev_conf->nb_event_queues > info.max_event_queues) {
- RTE_EDEV_LOG_ERR("%d nb_event_queues=%d > max_event_queues=%d",
- dev_id, dev_conf->nb_event_queues, info.max_event_queues);
+ if (dev_conf->nb_event_queues > info.max_event_queues +
+ info.max_single_link_event_port_queue_pairs) {
+ RTE_EDEV_LOG_ERR("%d nb_event_queues=%d > max_event_queues=%d + max_single_link_event_port_queue_pairs=%d",
+ dev_id, dev_conf->nb_event_queues,
+ info.max_event_queues,
+ info.max_single_link_event_port_queue_pairs);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_event_queues -
+ dev_conf->nb_single_link_event_port_queues >
+ info.max_event_queues) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_queues=%d - nb_single_link_event_port_queues=%d > max_event_queues=%d",
+ dev_id, dev_conf->nb_event_queues,
+ dev_conf->nb_single_link_event_port_queues,
+ info.max_event_queues);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_single_link_event_port_queues >
+ dev_conf->nb_event_queues) {
+ RTE_EDEV_LOG_ERR("dev%d nb_single_link_event_port_queues=%d > nb_event_queues=%d",
+ dev_id,
+ dev_conf->nb_single_link_event_port_queues,
+ dev_conf->nb_event_queues);
return -EINVAL;
}
@@ -448,9 +469,31 @@ rte_event_dev_configure(uint8_t dev_id,
RTE_EDEV_LOG_ERR("dev%d nb_event_ports cannot be zero", dev_id);
return -EINVAL;
}
- if (dev_conf->nb_event_ports > info.max_event_ports) {
- RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d > max_event_ports= %d",
- dev_id, dev_conf->nb_event_ports, info.max_event_ports);
+ if (dev_conf->nb_event_ports > info.max_event_ports +
+ info.max_single_link_event_port_queue_pairs) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d > max_event_ports=%d + max_single_link_event_port_queue_pairs=%d",
+ dev_id, dev_conf->nb_event_ports,
+ info.max_event_ports,
+ info.max_single_link_event_port_queue_pairs);
+ return -EINVAL;
+ }
+ if (dev_conf->nb_event_ports -
+ dev_conf->nb_single_link_event_port_queues
+ > info.max_event_ports) {
+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d - nb_single_link_event_port_queues=%d > max_event_ports=%d",
+ dev_id, dev_conf->nb_event_ports,
+ dev_conf->nb_single_link_event_port_queues,
+ info.max_event_ports);
+ return -EINVAL;
+ }
+
+ if (dev_conf->nb_single_link_event_port_queues >
+ dev_conf->nb_event_ports) {
+ RTE_EDEV_LOG_ERR(
+ "dev%d nb_single_link_event_port_queues=%d > nb_event_ports=%d",
+ dev_id,
+ dev_conf->nb_single_link_event_port_queues,
+ dev_conf->nb_event_ports);
return -EINVAL;
}
@@ -737,7 +780,8 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
return -EINVAL;
}
- if (port_conf && port_conf->disable_implicit_release &&
+ if (port_conf &&
+ (port_conf->event_port_cfg & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL) &&
!(dev->data->event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
RTE_EDEV_LOG_ERR(
@@ -830,6 +874,14 @@ rte_event_port_attr_get(uint8_t dev_id, uint8_t port_id, uint32_t attr_id,
case RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD:
*attr_value = dev->data->ports_cfg[port_id].new_event_threshold;
break;
+ case RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE:
+ {
+ uint32_t config;
+
+ config = dev->data->ports_cfg[port_id].event_port_cfg;
+ *attr_value = !!(config & RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
+ break;
+ }
default:
return -EINVAL;
};
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 7dc8323..ce1fc2c 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -291,6 +291,12 @@ struct rte_event;
* single queue to each port or map a single queue to many port.
*/
+#define RTE_EVENT_DEV_CAP_CARRY_FLOW_ID (1ULL << 9)
+/**< Event device preserves the flow ID from the enqueued
+ * event to the dequeued event if the flag is set. Otherwise,
+ * the content of this field is implementation dependent.
+ */
+
/* Event device priority levels */
#define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
/**< Highest priority expressed across eventdev subsystem
@@ -380,6 +386,10 @@ struct rte_event_dev_info {
* event port by this device.
* A device that does not support bulk enqueue will set this as 1.
*/
+ uint8_t max_event_port_links;
+ /**< Maximum number of queues that can be linked to a single event
+ * port by this device.
+ */
int32_t max_num_events;
/**< A *closed system* event dev has a limit on the number of events it
* can manage at a time. An *open system* event dev does not have a
@@ -387,6 +397,12 @@ struct rte_event_dev_info {
*/
uint32_t event_dev_cap;
/**< Event device capabilities(RTE_EVENT_DEV_CAP_)*/
+ uint8_t max_single_link_event_port_queue_pairs;
+ /**< Maximum number of event ports and queues that are optimized for
+ * (and only capable of) single-link configurations supported by this
+ * device. These ports and queues are not accounted for in
+ * max_event_ports or max_event_queues.
+ */
};
/**
@@ -494,6 +510,14 @@ struct rte_event_dev_config {
*/
uint32_t event_dev_cfg;
/**< Event device config flags(RTE_EVENT_DEV_CFG_)*/
+ uint8_t nb_single_link_event_port_queues;
+ /**< Number of event ports and queues that will be singly-linked to
+ * each other. These are a subset of the overall event ports and
+ * queues; this value cannot exceed *nb_event_ports* or
+ * *nb_event_queues*. If the device has ports and queues that are
+ * optimized for single-link usage, this field is a hint for how many
+ * to allocate; otherwise, regular event ports and queues can be used.
+ */
};
/**
@@ -519,7 +543,6 @@ int
rte_event_dev_configure(uint8_t dev_id,
const struct rte_event_dev_config *dev_conf);
-
/* Event queue specific APIs */
/* Event queue configuration bitmap flags */
@@ -671,6 +694,20 @@ rte_event_queue_attr_get(uint8_t dev_id, uint8_t queue_id, uint32_t attr_id,
/* Event port specific APIs */
+/* Event port configuration bitmap flags */
+#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL (1ULL << 0)
+/**< Configure the port not to release outstanding events in
+ * rte_event_dev_dequeue_burst(). If set, all events received through
+ * the port must be explicitly released with RTE_EVENT_OP_RELEASE or
+ * RTE_EVENT_OP_FORWARD. Must be unset if the device is not
+ * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
+ */
+#define RTE_EVENT_PORT_CFG_SINGLE_LINK (1ULL << 1)
+/**< This event port links only to a single event queue.
+ *
+ * @see rte_event_port_setup(), rte_event_port_link()
+ */
+
/** Event port configuration structure */
struct rte_event_port_conf {
int32_t new_event_threshold;
@@ -698,13 +735,7 @@ struct rte_event_port_conf {
* which previously supplied to rte_event_dev_configure().
* Ignored when device is not RTE_EVENT_DEV_CAP_BURST_MODE capable.
*/
- uint8_t disable_implicit_release;
- /**< Configure the port not to release outstanding events in
- * rte_event_dev_dequeue_burst(). If true, all events received through
- * the port must be explicitly released with RTE_EVENT_OP_RELEASE or
- * RTE_EVENT_OP_FORWARD. Must be false when the device is not
- * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
- */
+ uint32_t event_port_cfg; /**< Port cfg flags(EVENT_PORT_CFG_) */
};
/**
@@ -769,6 +800,10 @@ rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
* The new event threshold of the port
*/
#define RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD 2
+/**
+ * The implicit release disable attribute of the port
+ */
+#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
/**
* Get an attribute from a port.
diff --git a/lib/librte_eventdev/rte_eventdev_pmd_pci.h b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
index 443cd38..a3f9244 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
@@ -88,7 +88,6 @@ rte_event_pmd_pci_probe(struct rte_pci_driver *pci_drv,
return -ENXIO;
}
-
/**
* @internal
* Wrapper for use by pci drivers as a .remove function to detach a event
diff --git a/lib/librte_eventdev/rte_eventdev_trace.h b/lib/librte_eventdev/rte_eventdev_trace.h
index 4de6341..5ec43d8 100644
--- a/lib/librte_eventdev/rte_eventdev_trace.h
+++ b/lib/librte_eventdev/rte_eventdev_trace.h
@@ -34,6 +34,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_u32(dev_conf->nb_event_port_dequeue_depth);
rte_trace_point_emit_u32(dev_conf->nb_event_port_enqueue_depth);
rte_trace_point_emit_u32(dev_conf->event_dev_cfg);
+ rte_trace_point_emit_u8(dev_conf->nb_single_link_event_port_queues);
rte_trace_point_emit_int(rc);
)
@@ -59,7 +60,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
rte_trace_point_emit_int(rc);
)
@@ -165,7 +166,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
rte_trace_point_emit_ptr(conf_cb);
rte_trace_point_emit_int(rc);
)
@@ -257,7 +258,7 @@ RTE_TRACE_POINT(
rte_trace_point_emit_i32(port_conf->new_event_threshold);
rte_trace_point_emit_u16(port_conf->dequeue_depth);
rte_trace_point_emit_u16(port_conf->enqueue_depth);
- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
)
RTE_TRACE_POINT(
diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
index 3d9d0ca..2846d04 100644
--- a/lib/librte_eventdev/rte_eventdev_version.map
+++ b/lib/librte_eventdev/rte_eventdev_version.map
@@ -100,7 +100,6 @@ EXPERIMENTAL {
# added in 20.05
__rte_eventdev_trace_configure;
__rte_eventdev_trace_queue_setup;
- __rte_eventdev_trace_port_setup;
__rte_eventdev_trace_port_link;
__rte_eventdev_trace_port_unlink;
__rte_eventdev_trace_start;
@@ -134,4 +133,7 @@ EXPERIMENTAL {
__rte_eventdev_trace_crypto_adapter_queue_pair_del;
__rte_eventdev_trace_crypto_adapter_start;
__rte_eventdev_trace_crypto_adapter_stop;
+
+ # changed in 20.11
+ __rte_eventdev_trace_port_setup;
};
--
2.6.4
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH 2/2] eventdev: update app and examples for new eventdev ABI
2020-10-14 21:36 9% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-14 21:36 2% ` [dpdk-dev] [PATCH 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
@ 2020-10-14 21:36 6% ` Timothy McDaniel
2020-10-15 14:26 7% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Jerin Jacob
2 siblings, 0 replies; 200+ results
From: Timothy McDaniel @ 2020-10-14 21:36 UTC (permalink / raw)
To: Jerin Jacob, Harry van Haaren, Marko Kovacevic, Ori Kam,
Bruce Richardson, Radu Nicolau, Akhil Goyal, Tomasz Kantecki,
Sunil Kumar Kori, Pavan Nikhilesh
Cc: dev, erik.g.carrillo, gage.eads, hemant.agrawal
Several data structures and constants changed, or were added,
in the previous patch. This commit updates the dependent
apps and examples to use the new ABI.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
app/test-eventdev/evt_common.h | 11 ++++++++
app/test-eventdev/test_order_atq.c | 28 +++++++++++++++------
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 ++++++++++++++++------
app/test/test_eventdev.c | 4 +--
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +++--
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++++--
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +++--
examples/l3fwd/l3fwd_event_generic.c | 7 ++++--
examples/l3fwd/l3fwd_event_internal_port.c | 6 +++--
11 files changed, 80 insertions(+), 26 deletions(-)
diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
index f9d7378..a1da1cf 100644
--- a/app/test-eventdev/evt_common.h
+++ b/app/test-eventdev/evt_common.h
@@ -104,6 +104,16 @@ evt_has_all_types_queue(uint8_t dev_id)
true : false;
}
+static inline bool
+evt_has_flow_id(uint8_t dev_id)
+{
+ struct rte_event_dev_info dev_info;
+
+ rte_event_dev_info_get(dev_id, &dev_info);
+ return (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_CARRY_FLOW_ID) ?
+ true : false;
+}
+
static inline int
evt_service_setup(uint32_t service_id)
{
@@ -169,6 +179,7 @@ evt_configure_eventdev(struct evt_options *opt, uint8_t nb_queues,
.dequeue_timeout_ns = opt->deq_tmo_nsec,
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = info.max_num_events,
.nb_event_queue_flows = opt->nb_flows,
.nb_event_port_dequeue_depth =
diff --git a/app/test-eventdev/test_order_atq.c b/app/test-eventdev/test_order_atq.c
index 3366cfc..cfcb1dc 100644
--- a/app/test-eventdev/test_order_atq.c
+++ b/app/test-eventdev/test_order_atq.c
@@ -19,7 +19,7 @@ order_atq_process_stage_0(struct rte_event *const ev)
}
static int
-order_atq_worker(void *arg)
+order_atq_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_atq_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.sub_event_type == 0) { /* stage 0 from producer */
order_atq_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_atq_worker(void *arg)
}
static int
-order_atq_worker_burst(void *arg)
+order_atq_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,9 @@ order_atq_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].sub_event_type == 0) { /*stage 0 */
order_atq_process_stage_0(&ev[i]);
} else if (ev[i].sub_event_type == 1) { /* stage 1 */
@@ -95,11 +101,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_atq_worker_burst(arg);
- else
- return order_atq_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_atq_worker_burst(arg, true);
+ else
+ return order_atq_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_atq_worker(arg, true);
+ else
+ return order_atq_worker(arg, false);
+ }
}
static int
diff --git a/app/test-eventdev/test_order_common.c b/app/test-eventdev/test_order_common.c
index 4190f9a..7942390 100644
--- a/app/test-eventdev/test_order_common.c
+++ b/app/test-eventdev/test_order_common.c
@@ -49,6 +49,7 @@ order_producer(void *arg)
const uint32_t flow = (uintptr_t)m % nb_flows;
/* Maintain seq number per flow */
m->seqn = producer_flow_seq[flow]++;
+ m->udata64 = flow;
ev.flow_id = flow;
ev.mbuf = m;
diff --git a/app/test-eventdev/test_order_queue.c b/app/test-eventdev/test_order_queue.c
index 495efd9..1511c00 100644
--- a/app/test-eventdev/test_order_queue.c
+++ b/app/test-eventdev/test_order_queue.c
@@ -19,7 +19,7 @@ order_queue_process_stage_0(struct rte_event *const ev)
}
static int
-order_queue_worker(void *arg)
+order_queue_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_queue_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_queue_worker(void *arg)
}
static int
-order_queue_worker_burst(void *arg)
+order_queue_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,10 @@ order_queue_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev[i]);
} else if (ev[i].queue_id == 1) {/* from atomic queue */
@@ -95,11 +102,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_queue_worker_burst(arg);
- else
- return order_queue_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_queue_worker_burst(arg, true);
+ else
+ return order_queue_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_queue_worker(arg, true);
+ else
+ return order_queue_worker(arg, false);
+ }
}
static int
diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index 43ccb1c..62019c1 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -559,10 +559,10 @@ test_eventdev_port_setup(void)
if (!(info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
pconf.enqueue_depth = info.max_event_port_enqueue_depth;
- pconf.disable_implicit_release = 1;
+ pconf.event_port_cfg = RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
ret = rte_event_port_setup(TEST_DEV_ID, 0, &pconf);
TEST_ASSERT(ret == -EINVAL, "Expected -EINVAL, %d", ret);
- pconf.disable_implicit_release = 0;
+ pconf.event_port_cfg = 0;
}
ret = rte_event_port_setup(TEST_DEV_ID, info.max_event_ports,
diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c b/examples/eventdev_pipeline/pipeline_worker_generic.c
index 42ff4ee..f70ab0c 100644
--- a/examples/eventdev_pipeline/pipeline_worker_generic.c
+++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
@@ -129,6 +129,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 1,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
@@ -143,7 +144,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
.schedule_type = cdata.queue_type,
.priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
.nb_atomic_flows = 1024,
- .nb_atomic_order_sequences = 1024,
+ .nb_atomic_order_sequences = 1024,
};
struct rte_event_queue_conf tx_q_conf = {
.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST,
@@ -167,7 +168,8 @@ setup_eventdev_generic(struct worker_data *worker_data)
disable_implicit_release = (dev_info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
- wkr_p_conf.disable_implicit_release = disable_implicit_release;
+ wkr_p_conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (dev_info.max_num_events < config.nb_events_limit)
config.nb_events_limit = dev_info.max_num_events;
diff --git a/examples/eventdev_pipeline/pipeline_worker_tx.c b/examples/eventdev_pipeline/pipeline_worker_tx.c
index 55bb2f7..ca6cd20 100644
--- a/examples/eventdev_pipeline/pipeline_worker_tx.c
+++ b/examples/eventdev_pipeline/pipeline_worker_tx.c
@@ -436,6 +436,7 @@ setup_eventdev_worker_tx_enq(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c b/examples/l2fwd-event/l2fwd_event_generic.c
index 2dc95e5..9a3167c 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -126,8 +126,11 @@ l2fwd_event_port_setup_generic(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c b/examples/l2fwd-event/l2fwd_event_internal_port.c
index 63d57b4..203a14c 100644
--- a/examples/l2fwd-event/l2fwd_event_internal_port.c
+++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
@@ -123,8 +123,10 @@ l2fwd_event_port_setup_internal_port(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
diff --git a/examples/l3fwd/l3fwd_event_generic.c b/examples/l3fwd/l3fwd_event_generic.c
index f8c9843..c80573f 100644
--- a/examples/l3fwd/l3fwd_event_generic.c
+++ b/examples/l3fwd/l3fwd_event_generic.c
@@ -115,8 +115,11 @@ l3fwd_event_port_setup_generic(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l3fwd/l3fwd_event_internal_port.c b/examples/l3fwd/l3fwd_event_internal_port.c
index 03ac581..9916a7f 100644
--- a/examples/l3fwd/l3fwd_event_internal_port.c
+++ b/examples/l3fwd/l3fwd_event_internal_port.c
@@ -113,8 +113,10 @@ l3fwd_event_port_setup_internal_port(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
--
2.6.4
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2
@ 2020-10-14 21:36 9% ` Timothy McDaniel
2020-10-14 21:36 2% ` [dpdk-dev] [PATCH 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
` (2 more replies)
2020-10-15 17:31 9% ` [dpdk-dev] [PATCH 0/3] " Timothy McDaniel
2020-10-15 18:07 9% ` [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2 siblings, 3 replies; 200+ results
From: Timothy McDaniel @ 2020-10-14 21:36 UTC (permalink / raw)
Cc: dev, erik.g.carrillo, gage.eads, harry.van.haaren, hemant.agrawal
This series implements the eventdev ABI changes required by
the DLB and DLB2 PMDs. This ABI change was announced in the
20.08 release notes [1]. This patch was initially part of
the V1 DLB PMD patchset.
The DLB hardware does not conform exactly to the eventdev interface.
1) It has a limit on the number of queues that may be linked to a port.
2) Some ports are further restricted to a maximum of 1 linked queue.
3) It does not (currently) have the ability to carry the flow_id as part
of the event (QE) payload.
Due to the above, we would like to propose the following enhancements.
1) Add new fields to the rte_event_dev_info struct. These fields allow
the device to advertise its capabilities so that applications can take
the appropriate actions based on those capabilities.
2) Add a new field to the rte_event_dev_config struct. This field allows
the application to specify how many of its ports are limited to a single
link, or will be used in single link mode.
3) Replace the dedicated implicit_release_disabled field with a bit field
of explicit port capabilities. The implicit_release_disable functionality
is assigned to one bit, and a port-is-single-link-only attribute is
assigned to another, with the remaining bits available for future
assignment.
Note that it was requested that we split this app/test
changes out from the eventdev ABI patch. As a result,
neither of these patches will build without the other
also being applied.
Major changes since V1:
Reworded commit message, as requested
Fixed errors reported by clang
Testing showed no performance impact due to the flow_id template code
added to test app.
[1] http://mails.dpdk.org/archives/dev/2020-August/177261.html
Timothy McDaniel (2):
eventdev: eventdev: express DLB/DLB2 PMD constraints
eventdev: update app and examples for new eventdev ABI
Timothy McDaniel (2):
eventdev: eventdev: express DLB/DLB2 PMD constraints
eventdev: update app and examples for new eventdev ABI
app/test-eventdev/evt_common.h | 11 ++++
app/test-eventdev/test_order_atq.c | 28 ++++++---
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 +++++++---
app/test/test_eventdev.c | 4 +-
drivers/event/dpaa/dpaa_eventdev.c | 3 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
drivers/event/dsw/dsw_evdev.c | 3 +-
drivers/event/octeontx/ssovf_evdev.c | 5 +-
drivers/event/octeontx2/otx2_evdev.c | 3 +-
drivers/event/opdl/opdl_evdev.c | 3 +-
drivers/event/skeleton/skeleton_eventdev.c | 5 +-
drivers/event/sw/sw_evdev.c | 8 ++-
drivers/event/sw/sw_evdev_selftest.c | 6 +-
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +-
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++-
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +-
examples/l3fwd/l3fwd_event_generic.c | 7 ++-
examples/l3fwd/l3fwd_event_internal_port.c | 6 +-
lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/librte_eventdev/rte_eventdev.c | 66 +++++++++++++++++++---
lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++---
lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
lib/librte_eventdev/rte_eventdev_trace.h | 7 ++-
lib/librte_eventdev/rte_eventdev_version.map | 4 +-
26 files changed, 214 insertions(+), 64 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v3] eventdev: update app and examples for new eventdev ABI
2020-10-14 17:33 6% ` [dpdk-dev] [PATCH v3] " Timothy McDaniel
@ 2020-10-14 20:01 4% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2020-10-14 20:01 UTC (permalink / raw)
To: Timothy McDaniel
Cc: Jerin Jacob, Harry van Haaren, Marko Kovacevic, Ori Kam,
Bruce Richardson, Radu Nicolau, Akhil Goyal, Tomasz Kantecki,
Sunil Kumar Kori, Pavan Nikhilesh, dpdk-dev,
Erik Gabriel Carrillo, Gage Eads
On Wed, Oct 14, 2020 at 11:01 PM Timothy McDaniel
<timothy.mcdaniel@intel.com> wrote:
>
> Several data structures and constants changed, or were added,
> in the previous patch. This commit updates the dependent
> apps and examples to use the new ABI.
>
> Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
> Acked-by: Pavan Nikhilesh <pbhagavatula at marvell.com>
> Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
Please send both spec and this patches as series. Not this
http://patches.dpdk.org/patch/80782/ alone.
Reason: The spec patch[1] still has apply issue[2]. Please rebase both
patches on top of next-evendev and send a series.
I am changing the patchwork status for the following patches as
"Changes requested"
http://patches.dpdk.org/patch/79715/
http://patches.dpdk.org/patch/79716/
http://patches.dpdk.org/patch/80782/
[1]
http://patches.dpdk.org/patch/79715/
[2]
[for-main]dell[dpdk-next-eventdev] $ date &&
/home/jerin/config/scripts/build_each_patch.sh /tmp/r/ && date
Thu Oct 15 01:23:43 AM IST 2020
HEAD is now at 1d41eebe8 event/sw: performance improvements
meson build test
Applying: eventdev: eventdev: express DLB/DLB2 PMD constraints
Using index info to reconstruct a base tree...
M drivers/event/dpaa2/dpaa2_eventdev.c
M drivers/event/octeontx/ssovf_evdev.c
M drivers/event/octeontx2/otx2_evdev.c
M drivers/event/sw/sw_evdev.c
M lib/librte_eventdev/rte_event_eth_tx_adapter.c
M lib/librte_eventdev/rte_eventdev.c
Falling back to patching base and 3-way merge...
Auto-merging lib/librte_eventdev/rte_eventdev.c
CONFLICT (content): Merge conflict in lib/librte_eventdev/rte_eventdev.c
Auto-merging lib/librte_eventdev/rte_event_eth_tx_adapter.c
Auto-merging drivers/event/sw/sw_evdev.c
Auto-merging drivers/event/octeontx2/otx2_evdev.c
Auto-merging drivers/event/octeontx/ssovf_evdev.c
Auto-merging drivers/event/dpaa2/dpaa2_eventdev.c
Recorded preimage for 'lib/librte_eventdev/rte_eventdev.c'
error: Failed to merge in the changes.
Patch failed at 0001 eventdev: eventdev: express DLB/DLB2 PMD constraints
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
git am failed /tmp/r//v2-1-2-eventdev-eventdev-express-DLB-DLB2-PMD-constraints
HEAD is now at 1d41eebe8 event/sw: performance improvements
Thu Oct 15 01:23:43 AM IST 2020
> ---
> app/test-eventdev/evt_common.h | 11 ++++++++
> app/test-eventdev/test_order_atq.c | 28 +++++++++++++++------
> app/test-eventdev/test_order_common.c | 1 +
> app/test-eventdev/test_order_queue.c | 29 ++++++++++++++++------
> app/test/test_eventdev.c | 4 +--
> .../eventdev_pipeline/pipeline_worker_generic.c | 6 +++--
> examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
> examples/l2fwd-event/l2fwd_event_generic.c | 7 ++++--
> examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +++--
> examples/l3fwd/l3fwd_event_generic.c | 7 ++++--
> examples/l3fwd/l3fwd_event_internal_port.c | 6 +++--
> 11 files changed, 80 insertions(+), 26 deletions(-)
>
> diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
> index f9d7378..a1da1cf 100644
> --- a/app/test-eventdev/evt_common.h
> +++ b/app/test-eventdev/evt_common.h
> @@ -104,6 +104,16 @@ evt_has_all_types_queue(uint8_t dev_id)
> true : false;
> }
>
> +static inline bool
> +evt_has_flow_id(uint8_t dev_id)
> +{
> + struct rte_event_dev_info dev_info;
> +
> + rte_event_dev_info_get(dev_id, &dev_info);
> + return (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_CARRY_FLOW_ID) ?
> + true : false;
> +}
> +
> static inline int
> evt_service_setup(uint32_t service_id)
> {
> @@ -169,6 +179,7 @@ evt_configure_eventdev(struct evt_options *opt, uint8_t nb_queues,
> .dequeue_timeout_ns = opt->deq_tmo_nsec,
> .nb_event_queues = nb_queues,
> .nb_event_ports = nb_ports,
> + .nb_single_link_event_port_queues = 0,
> .nb_events_limit = info.max_num_events,
> .nb_event_queue_flows = opt->nb_flows,
> .nb_event_port_dequeue_depth =
> diff --git a/app/test-eventdev/test_order_atq.c b/app/test-eventdev/test_order_atq.c
> index 3366cfc..cfcb1dc 100644
> --- a/app/test-eventdev/test_order_atq.c
> +++ b/app/test-eventdev/test_order_atq.c
> @@ -19,7 +19,7 @@ order_atq_process_stage_0(struct rte_event *const ev)
> }
>
> static int
> -order_atq_worker(void *arg)
> +order_atq_worker(void *arg, const bool flow_id_cap)
> {
> ORDER_WORKER_INIT;
> struct rte_event ev;
> @@ -34,6 +34,9 @@ order_atq_worker(void *arg)
> continue;
> }
>
> + if (!flow_id_cap)
> + ev.flow_id = ev.mbuf->udata64;
> +
> if (ev.sub_event_type == 0) { /* stage 0 from producer */
> order_atq_process_stage_0(&ev);
> while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
> @@ -50,7 +53,7 @@ order_atq_worker(void *arg)
> }
>
> static int
> -order_atq_worker_burst(void *arg)
> +order_atq_worker_burst(void *arg, const bool flow_id_cap)
> {
> ORDER_WORKER_INIT;
> struct rte_event ev[BURST_SIZE];
> @@ -68,6 +71,9 @@ order_atq_worker_burst(void *arg)
> }
>
> for (i = 0; i < nb_rx; i++) {
> + if (!flow_id_cap)
> + ev[i].flow_id = ev[i].mbuf->udata64;
> +
> if (ev[i].sub_event_type == 0) { /*stage 0 */
> order_atq_process_stage_0(&ev[i]);
> } else if (ev[i].sub_event_type == 1) { /* stage 1 */
> @@ -95,11 +101,19 @@ worker_wrapper(void *arg)
> {
> struct worker_data *w = arg;
> const bool burst = evt_has_burst_mode(w->dev_id);
> -
> - if (burst)
> - return order_atq_worker_burst(arg);
> - else
> - return order_atq_worker(arg);
> + const bool flow_id_cap = evt_has_flow_id(w->dev_id);
> +
> + if (burst) {
> + if (flow_id_cap)
> + return order_atq_worker_burst(arg, true);
> + else
> + return order_atq_worker_burst(arg, false);
> + } else {
> + if (flow_id_cap)
> + return order_atq_worker(arg, true);
> + else
> + return order_atq_worker(arg, false);
> + }
> }
>
> static int
> diff --git a/app/test-eventdev/test_order_common.c b/app/test-eventdev/test_order_common.c
> index 4190f9a..7942390 100644
> --- a/app/test-eventdev/test_order_common.c
> +++ b/app/test-eventdev/test_order_common.c
> @@ -49,6 +49,7 @@ order_producer(void *arg)
> const uint32_t flow = (uintptr_t)m % nb_flows;
> /* Maintain seq number per flow */
> m->seqn = producer_flow_seq[flow]++;
> + m->udata64 = flow;
>
> ev.flow_id = flow;
> ev.mbuf = m;
> diff --git a/app/test-eventdev/test_order_queue.c b/app/test-eventdev/test_order_queue.c
> index 495efd9..1511c00 100644
> --- a/app/test-eventdev/test_order_queue.c
> +++ b/app/test-eventdev/test_order_queue.c
> @@ -19,7 +19,7 @@ order_queue_process_stage_0(struct rte_event *const ev)
> }
>
> static int
> -order_queue_worker(void *arg)
> +order_queue_worker(void *arg, const bool flow_id_cap)
> {
> ORDER_WORKER_INIT;
> struct rte_event ev;
> @@ -34,6 +34,9 @@ order_queue_worker(void *arg)
> continue;
> }
>
> + if (!flow_id_cap)
> + ev.flow_id = ev.mbuf->udata64;
> +
> if (ev.queue_id == 0) { /* from ordered queue */
> order_queue_process_stage_0(&ev);
> while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
> @@ -50,7 +53,7 @@ order_queue_worker(void *arg)
> }
>
> static int
> -order_queue_worker_burst(void *arg)
> +order_queue_worker_burst(void *arg, const bool flow_id_cap)
> {
> ORDER_WORKER_INIT;
> struct rte_event ev[BURST_SIZE];
> @@ -68,6 +71,10 @@ order_queue_worker_burst(void *arg)
> }
>
> for (i = 0; i < nb_rx; i++) {
> +
> + if (!flow_id_cap)
> + ev[i].flow_id = ev[i].mbuf->udata64;
> +
> if (ev[i].queue_id == 0) { /* from ordered queue */
> order_queue_process_stage_0(&ev[i]);
> } else if (ev[i].queue_id == 1) {/* from atomic queue */
> @@ -95,11 +102,19 @@ worker_wrapper(void *arg)
> {
> struct worker_data *w = arg;
> const bool burst = evt_has_burst_mode(w->dev_id);
> -
> - if (burst)
> - return order_queue_worker_burst(arg);
> - else
> - return order_queue_worker(arg);
> + const bool flow_id_cap = evt_has_flow_id(w->dev_id);
> +
> + if (burst) {
> + if (flow_id_cap)
> + return order_queue_worker_burst(arg, true);
> + else
> + return order_queue_worker_burst(arg, false);
> + } else {
> + if (flow_id_cap)
> + return order_queue_worker(arg, true);
> + else
> + return order_queue_worker(arg, false);
> + }
> }
>
> static int
> diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
> index 43ccb1c..62019c1 100644
> --- a/app/test/test_eventdev.c
> +++ b/app/test/test_eventdev.c
> @@ -559,10 +559,10 @@ test_eventdev_port_setup(void)
> if (!(info.event_dev_cap &
> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
> pconf.enqueue_depth = info.max_event_port_enqueue_depth;
> - pconf.disable_implicit_release = 1;
> + pconf.event_port_cfg = RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
> ret = rte_event_port_setup(TEST_DEV_ID, 0, &pconf);
> TEST_ASSERT(ret == -EINVAL, "Expected -EINVAL, %d", ret);
> - pconf.disable_implicit_release = 0;
> + pconf.event_port_cfg = 0;
> }
>
> ret = rte_event_port_setup(TEST_DEV_ID, info.max_event_ports,
> diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c b/examples/eventdev_pipeline/pipeline_worker_generic.c
> index 42ff4ee..f70ab0c 100644
> --- a/examples/eventdev_pipeline/pipeline_worker_generic.c
> +++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
> @@ -129,6 +129,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
> struct rte_event_dev_config config = {
> .nb_event_queues = nb_queues,
> .nb_event_ports = nb_ports,
> + .nb_single_link_event_port_queues = 1,
> .nb_events_limit = 4096,
> .nb_event_queue_flows = 1024,
> .nb_event_port_dequeue_depth = 128,
> @@ -143,7 +144,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
> .schedule_type = cdata.queue_type,
> .priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
> .nb_atomic_flows = 1024,
> - .nb_atomic_order_sequences = 1024,
> + .nb_atomic_order_sequences = 1024,
> };
> struct rte_event_queue_conf tx_q_conf = {
> .priority = RTE_EVENT_DEV_PRIORITY_HIGHEST,
> @@ -167,7 +168,8 @@ setup_eventdev_generic(struct worker_data *worker_data)
> disable_implicit_release = (dev_info.event_dev_cap &
> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
>
> - wkr_p_conf.disable_implicit_release = disable_implicit_release;
> + wkr_p_conf.event_port_cfg = disable_implicit_release ?
> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
>
> if (dev_info.max_num_events < config.nb_events_limit)
> config.nb_events_limit = dev_info.max_num_events;
> diff --git a/examples/eventdev_pipeline/pipeline_worker_tx.c b/examples/eventdev_pipeline/pipeline_worker_tx.c
> index 55bb2f7..ca6cd20 100644
> --- a/examples/eventdev_pipeline/pipeline_worker_tx.c
> +++ b/examples/eventdev_pipeline/pipeline_worker_tx.c
> @@ -436,6 +436,7 @@ setup_eventdev_worker_tx_enq(struct worker_data *worker_data)
> struct rte_event_dev_config config = {
> .nb_event_queues = nb_queues,
> .nb_event_ports = nb_ports,
> + .nb_single_link_event_port_queues = 0,
> .nb_events_limit = 4096,
> .nb_event_queue_flows = 1024,
> .nb_event_port_dequeue_depth = 128,
> diff --git a/examples/l2fwd-event/l2fwd_event_generic.c b/examples/l2fwd-event/l2fwd_event_generic.c
> index 2dc95e5..9a3167c 100644
> --- a/examples/l2fwd-event/l2fwd_event_generic.c
> +++ b/examples/l2fwd-event/l2fwd_event_generic.c
> @@ -126,8 +126,11 @@ l2fwd_event_port_setup_generic(struct l2fwd_resources *rsrc)
> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
> event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
>
> - event_p_conf.disable_implicit_release =
> - evt_rsrc->disable_implicit_release;
> + event_p_conf.event_port_cfg = 0;
> + if (evt_rsrc->disable_implicit_release)
> + event_p_conf.event_port_cfg |=
> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
> +
> evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
>
> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
> diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c b/examples/l2fwd-event/l2fwd_event_internal_port.c
> index 63d57b4..203a14c 100644
> --- a/examples/l2fwd-event/l2fwd_event_internal_port.c
> +++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
> @@ -123,8 +123,10 @@ l2fwd_event_port_setup_internal_port(struct l2fwd_resources *rsrc)
> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
> event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
>
> - event_p_conf.disable_implicit_release =
> - evt_rsrc->disable_implicit_release;
> + event_p_conf.event_port_cfg = 0;
> + if (evt_rsrc->disable_implicit_release)
> + event_p_conf.event_port_cfg |=
> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>
> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
> event_p_id++) {
> diff --git a/examples/l3fwd/l3fwd_event_generic.c b/examples/l3fwd/l3fwd_event_generic.c
> index f8c9843..c80573f 100644
> --- a/examples/l3fwd/l3fwd_event_generic.c
> +++ b/examples/l3fwd/l3fwd_event_generic.c
> @@ -115,8 +115,11 @@ l3fwd_event_port_setup_generic(void)
> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
> event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
>
> - event_p_conf.disable_implicit_release =
> - evt_rsrc->disable_implicit_release;
> + event_p_conf.event_port_cfg = 0;
> + if (evt_rsrc->disable_implicit_release)
> + event_p_conf.event_port_cfg |=
> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
> +
> evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
>
> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
> diff --git a/examples/l3fwd/l3fwd_event_internal_port.c b/examples/l3fwd/l3fwd_event_internal_port.c
> index 03ac581..9916a7f 100644
> --- a/examples/l3fwd/l3fwd_event_internal_port.c
> +++ b/examples/l3fwd/l3fwd_event_internal_port.c
> @@ -113,8 +113,10 @@ l3fwd_event_port_setup_internal_port(void)
> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
> event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
>
> - event_p_conf.disable_implicit_release =
> - evt_rsrc->disable_implicit_release;
> + event_p_conf.event_port_cfg = 0;
> + if (evt_rsrc->disable_implicit_release)
> + event_p_conf.event_port_cfg |=
> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>
> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
> event_p_id++) {
> --
> 2.6.4
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] security: update session create API
2020-10-13 2:12 0% ` Lukasz Wojciechowski
@ 2020-10-14 18:56 2% ` Akhil Goyal
2020-10-15 1:11 0% ` Lukasz Wojciechowski
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2020-10-14 18:56 UTC (permalink / raw)
To: dev
Cc: thomas, mdr, anoobj, hemant.agrawal, konstantin.ananyev,
declan.doherty, radu.nicolau, david.coyle, l.wojciechow,
Akhil Goyal
The API ``rte_security_session_create`` takes only single
mempool for session and session private data. So the
application need to create mempool for twice the number of
sessions needed and will also lead to wastage of memory as
session private data need more memory compared to session.
Hence the API is modified to take two mempool pointers
- one for session and one for private data.
This is very similar to crypto based session create APIs.
Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
---
Changes in v3:
fixed checkpatch issues.
Added new test in test_security.c for priv_mempool
Changes in V2:
incorporated comments from Lukasz and David.
app/test-crypto-perf/cperf_ops.c | 4 +-
app/test-crypto-perf/main.c | 12 +-
app/test/test_cryptodev.c | 18 ++-
app/test/test_ipsec.c | 3 +-
app/test/test_security.c | 160 ++++++++++++++++++++++---
doc/guides/prog_guide/rte_security.rst | 8 +-
doc/guides/rel_notes/deprecation.rst | 7 --
doc/guides/rel_notes/release_20_11.rst | 6 +
examples/ipsec-secgw/ipsec-secgw.c | 12 +-
examples/ipsec-secgw/ipsec.c | 9 +-
lib/librte_security/rte_security.c | 7 +-
lib/librte_security/rte_security.h | 4 +-
12 files changed, 196 insertions(+), 54 deletions(-)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 3da835a9c..3a64a2c34 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -621,7 +621,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
/* Create security session */
return (void *)rte_security_session_create(ctx,
- &sess_conf, sess_mp);
+ &sess_conf, sess_mp, priv_mp);
}
if (options->op_type == CPERF_DOCSIS) {
enum rte_security_docsis_direction direction;
@@ -664,7 +664,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
/* Create security session */
return (void *)rte_security_session_create(ctx,
- &sess_conf, priv_mp);
+ &sess_conf, sess_mp, priv_mp);
}
#endif
sess = rte_cryptodev_sym_session_create(sess_mp);
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 62ae6048b..53864ffdd 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -156,7 +156,14 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
if (sess_size > max_sess_size)
max_sess_size = sess_size;
}
-
+#ifdef RTE_LIBRTE_SECURITY
+ for (cdev_id = 0; cdev_id < rte_cryptodev_count(); cdev_id++) {
+ sess_size = rte_security_session_get_size(
+ rte_cryptodev_get_sec_ctx(cdev_id));
+ if (sess_size > max_sess_size)
+ max_sess_size = sess_size;
+ }
+#endif
/*
* Calculate number of needed queue pairs, based on the amount
* of available number of logical cores and crypto devices.
@@ -247,8 +254,7 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
opts->nb_qps * nb_slaves;
#endif
} else
- sessions_needed = enabled_cdev_count *
- opts->nb_qps * 2;
+ sessions_needed = enabled_cdev_count * opts->nb_qps;
/*
* A single session is required per queue pair
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index c7975ed01..9f1b92c51 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -773,9 +773,15 @@ testsuite_setup(void)
unsigned int session_size =
rte_cryptodev_sym_get_private_session_size(dev_id);
+#ifdef RTE_LIBRTE_SECURITY
+ unsigned int security_session_size = rte_security_session_get_size(
+ rte_cryptodev_get_sec_ctx(dev_id));
+
+ if (session_size < security_session_size)
+ session_size = security_session_size;
+#endif
/*
- * Create mempool with maximum number of sessions * 2,
- * to include the session headers
+ * Create mempool with maximum number of sessions.
*/
if (info.sym.max_nb_sessions != 0 &&
info.sym.max_nb_sessions < MAX_NB_SESSIONS) {
@@ -7751,7 +7757,8 @@ test_pdcp_proto(int i, int oop,
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx,
- &sess_conf, ts_params->session_priv_mpool);
+ &sess_conf, ts_params->session_mpool,
+ ts_params->session_priv_mpool);
if (!ut_params->sec_session) {
printf("TestCase %s()-%d line %d failed %s: ",
@@ -8011,7 +8018,8 @@ test_pdcp_proto_SGL(int i, int oop,
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx,
- &sess_conf, ts_params->session_priv_mpool);
+ &sess_conf, ts_params->session_mpool,
+ ts_params->session_priv_mpool);
if (!ut_params->sec_session) {
printf("TestCase %s()-%d line %d failed %s: ",
@@ -8368,6 +8376,7 @@ test_docsis_proto_uplink(int i, struct docsis_test_data *d_td)
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
+ ts_params->session_mpool,
ts_params->session_priv_mpool);
if (!ut_params->sec_session) {
@@ -8543,6 +8552,7 @@ test_docsis_proto_downlink(int i, struct docsis_test_data *d_td)
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
+ ts_params->session_mpool,
ts_params->session_priv_mpool);
if (!ut_params->sec_session) {
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 79d00d7e0..9ad07a179 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -632,7 +632,8 @@ create_dummy_sec_session(struct ipsec_unitest_params *ut,
static struct rte_security_session_conf conf;
ut->ss[j].security.ses = rte_security_session_create(&dummy_sec_ctx,
- &conf, qp->mp_session_private);
+ &conf, qp->mp_session,
+ qp->mp_session_private);
if (ut->ss[j].security.ses == NULL)
return -ENOMEM;
diff --git a/app/test/test_security.c b/app/test/test_security.c
index 77fd5adc6..35ed6ff10 100644
--- a/app/test/test_security.c
+++ b/app/test/test_security.c
@@ -200,6 +200,24 @@
expected_mempool_usage, mempool_usage); \
} while (0)
+/**
+ * Verify usage of mempool by checking if number of allocated objects matches
+ * expectations. The mempool is used to manage objects for sessions priv data.
+ * A single object is acquired from mempool during session_create
+ * and put back in session_destroy.
+ *
+ * @param expected_priv_mp_usage expected number of used priv mp objects
+ */
+#define TEST_ASSERT_PRIV_MP_USAGE(expected_priv_mp_usage) do { \
+ struct security_testsuite_params *ts_params = &testsuite_params;\
+ unsigned int priv_mp_usage; \
+ priv_mp_usage = rte_mempool_in_use_count( \
+ ts_params->session_priv_mpool); \
+ TEST_ASSERT_EQUAL(expected_priv_mp_usage, priv_mp_usage, \
+ "Expecting %u priv mempool allocations, " \
+ "but there are %u allocated objects", \
+ expected_priv_mp_usage, priv_mp_usage); \
+} while (0)
/**
* Mockup structures and functions for rte_security_ops;
@@ -237,27 +255,38 @@ static struct mock_session_create_data {
struct rte_security_session_conf *conf;
struct rte_security_session *sess;
struct rte_mempool *mp;
+ struct rte_mempool *priv_mp;
int ret;
int called;
int failed;
-} mock_session_create_exp = {NULL, NULL, NULL, NULL, 0, 0, 0};
+} mock_session_create_exp = {NULL, NULL, NULL, NULL, NULL, 0, 0, 0};
static int
mock_session_create(void *device,
struct rte_security_session_conf *conf,
struct rte_security_session *sess,
- struct rte_mempool *mp)
+ struct rte_mempool *priv_mp)
{
+ void *sess_priv;
+ int ret;
+
mock_session_create_exp.called++;
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, device);
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, conf);
- MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, mp);
+ MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, priv_mp);
+ ret = rte_mempool_get(priv_mp, &sess_priv);
+ TEST_ASSERT_EQUAL(0, ret,
+ "priv mempool does not have enough objects");
+ set_sec_session_private_data(sess, sess_priv);
mock_session_create_exp.sess = sess;
+ if (mock_session_create_exp.ret != 0)
+ rte_mempool_put(priv_mp, sess_priv);
+
return mock_session_create_exp.ret;
}
@@ -363,8 +392,10 @@ static struct mock_session_destroy_data {
static int
mock_session_destroy(void *device, struct rte_security_session *sess)
{
- mock_session_destroy_exp.called++;
+ void *sess_priv = get_sec_session_private_data(sess);
+ mock_session_destroy_exp.called++;
+ rte_mempool_put(rte_mempool_from_obj(sess_priv), sess_priv);
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_destroy_exp, device);
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_destroy_exp, sess);
@@ -502,6 +533,7 @@ struct rte_security_ops mock_ops = {
*/
static struct security_testsuite_params {
struct rte_mempool *session_mpool;
+ struct rte_mempool *session_priv_mpool;
} testsuite_params = { NULL };
/**
@@ -524,9 +556,11 @@ static struct security_unittest_params {
.sess = NULL,
};
-#define SECURITY_TEST_MEMPOOL_NAME "SecurityTestsMempoolName"
+#define SECURITY_TEST_MEMPOOL_NAME "SecurityTestMp"
+#define SECURITY_TEST_PRIV_MEMPOOL_NAME "SecurityTestPrivMp"
#define SECURITY_TEST_MEMPOOL_SIZE 15
-#define SECURITY_TEST_SESSION_OBJECT_SIZE sizeof(struct rte_security_session)
+#define SECURITY_TEST_SESSION_OBJ_SZ sizeof(struct rte_security_session)
+#define SECURITY_TEST_SESSION_PRIV_OBJ_SZ 64
/**
* testsuite_setup initializes whole test suite parameters.
@@ -540,11 +574,27 @@ testsuite_setup(void)
ts_params->session_mpool = rte_mempool_create(
SECURITY_TEST_MEMPOOL_NAME,
SECURITY_TEST_MEMPOOL_SIZE,
- SECURITY_TEST_SESSION_OBJECT_SIZE,
+ SECURITY_TEST_SESSION_OBJ_SZ,
0, 0, NULL, NULL, NULL, NULL,
SOCKET_ID_ANY, 0);
TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
"Cannot create mempool %s\n", rte_strerror(rte_errno));
+
+ ts_params->session_priv_mpool = rte_mempool_create(
+ SECURITY_TEST_PRIV_MEMPOOL_NAME,
+ SECURITY_TEST_MEMPOOL_SIZE,
+ SECURITY_TEST_SESSION_PRIV_OBJ_SZ,
+ 0, 0, NULL, NULL, NULL, NULL,
+ SOCKET_ID_ANY, 0);
+ if (ts_params->session_priv_mpool == NULL) {
+ RTE_LOG(ERR, USER1, "TestCase %s() line %d failed (null): "
+ "Cannot create priv mempool %s\n",
+ __func__, __LINE__, rte_strerror(rte_errno));
+ rte_mempool_free(ts_params->session_mpool);
+ ts_params->session_mpool = NULL;
+ return TEST_FAILED;
+ }
+
return TEST_SUCCESS;
}
@@ -559,6 +609,10 @@ testsuite_teardown(void)
rte_mempool_free(ts_params->session_mpool);
ts_params->session_mpool = NULL;
}
+ if (ts_params->session_priv_mpool) {
+ rte_mempool_free(ts_params->session_priv_mpool);
+ ts_params->session_priv_mpool = NULL;
+ }
}
/**
@@ -656,10 +710,12 @@ ut_setup_with_session(void)
mock_session_create_exp.device = NULL;
mock_session_create_exp.conf = &ut_params->conf;
mock_session_create_exp.mp = ts_params->session_mpool;
+ mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
mock_session_create_exp.ret = 0;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
sess);
TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
@@ -701,11 +757,13 @@ test_session_create_inv_context(void)
struct rte_security_session *sess;
sess = rte_security_session_create(NULL, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -725,11 +783,13 @@ test_session_create_inv_context_ops(void)
ut_params->ctx.ops = NULL;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -749,11 +809,13 @@ test_session_create_inv_context_ops_fun(void)
ut_params->ctx.ops = &empty_ops;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -770,18 +832,21 @@ test_session_create_inv_configuration(void)
struct rte_security_session *sess;
sess = rte_security_session_create(&ut_params->ctx, NULL,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
}
/**
- * Test execution of rte_security_session_create with NULL mp parameter
+ * Test execution of rte_security_session_create with NULL session
+ * mempool
*/
static int
test_session_create_inv_mempool(void)
@@ -790,11 +855,35 @@ test_session_create_inv_mempool(void)
struct rte_security_session *sess;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- NULL);
+ NULL, NULL);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
+ TEST_ASSERT_SESSION_COUNT(0);
+
+ return TEST_SUCCESS;
+}
+
+/**
+ * Test execution of rte_security_session_create with NULL session
+ * priv mempool
+ */
+static int
+test_session_create_inv_sess_priv_mempool(void)
+{
+ struct security_unittest_params *ut_params = &unittest_params;
+ struct security_testsuite_params *ts_params = &testsuite_params;
+ struct rte_security_session *sess;
+
+ sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
+ ts_params->session_mpool, NULL);
+ TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
+ sess, NULL, "%p");
+ TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
+ TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -810,6 +899,7 @@ test_session_create_mempool_empty(void)
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
struct rte_security_session *tmp[SECURITY_TEST_MEMPOOL_SIZE];
+ void *tmp1[SECURITY_TEST_MEMPOOL_SIZE];
struct rte_security_session *sess;
/* Get all available objects from mempool. */
@@ -820,21 +910,34 @@ test_session_create_mempool_empty(void)
TEST_ASSERT_EQUAL(0, ret,
"Expect getting %d object from mempool"
" to succeed", i);
+ ret = rte_mempool_get(ts_params->session_priv_mpool,
+ (void **)(&tmp1[i]));
+ TEST_ASSERT_EQUAL(0, ret,
+ "Expect getting %d object from priv mempool"
+ " to succeed", i);
}
TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
+ TEST_ASSERT_PRIV_MP_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
+ TEST_ASSERT_PRIV_MP_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
TEST_ASSERT_SESSION_COUNT(0);
/* Put objects back to the pool. */
- for (i = 0; i < SECURITY_TEST_MEMPOOL_SIZE; ++i)
- rte_mempool_put(ts_params->session_mpool, (void *)(tmp[i]));
+ for (i = 0; i < SECURITY_TEST_MEMPOOL_SIZE; ++i) {
+ rte_mempool_put(ts_params->session_mpool,
+ (void *)(tmp[i]));
+ rte_mempool_put(ts_params->session_priv_mpool,
+ (tmp1[i]));
+ }
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
return TEST_SUCCESS;
}
@@ -853,14 +956,17 @@ test_session_create_ops_failure(void)
mock_session_create_exp.device = NULL;
mock_session_create_exp.conf = &ut_params->conf;
mock_session_create_exp.mp = ts_params->session_mpool;
+ mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
mock_session_create_exp.ret = -1; /* Return failure status. */
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -879,10 +985,12 @@ test_session_create_success(void)
mock_session_create_exp.device = NULL;
mock_session_create_exp.conf = &ut_params->conf;
mock_session_create_exp.mp = ts_params->session_mpool;
+ mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
mock_session_create_exp.ret = 0; /* Return success status. */
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool);
+ ts_params->session_mpool,
+ ts_params->session_priv_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
sess);
TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
@@ -891,6 +999,7 @@ test_session_create_success(void)
sess, mock_session_create_exp.sess);
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
/*
@@ -1276,6 +1385,7 @@ test_session_destroy_inv_context(void)
struct security_unittest_params *ut_params = &unittest_params;
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(NULL, ut_params->sess);
@@ -1283,6 +1393,7 @@ test_session_destroy_inv_context(void)
ret, -EINVAL, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1299,6 +1410,7 @@ test_session_destroy_inv_context_ops(void)
ut_params->ctx.ops = NULL;
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1307,6 +1419,7 @@ test_session_destroy_inv_context_ops(void)
ret, -EINVAL, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1323,6 +1436,7 @@ test_session_destroy_inv_context_ops_fun(void)
ut_params->ctx.ops = &empty_ops;
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1331,6 +1445,7 @@ test_session_destroy_inv_context_ops_fun(void)
ret, -ENOTSUP, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1345,6 +1460,7 @@ test_session_destroy_inv_session(void)
struct security_unittest_params *ut_params = &unittest_params;
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx, NULL);
@@ -1352,6 +1468,7 @@ test_session_destroy_inv_session(void)
ret, -EINVAL, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1371,6 +1488,7 @@ test_session_destroy_ops_failure(void)
mock_session_destroy_exp.ret = -1;
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1396,6 +1514,7 @@ test_session_destroy_success(void)
mock_session_destroy_exp.sess = ut_params->sess;
mock_session_destroy_exp.ret = 0;
TEST_ASSERT_MEMPOOL_USAGE(1);
+ TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1404,6 +1523,7 @@ test_session_destroy_success(void)
ret, 0, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(0);
+ TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
/*
@@ -2370,6 +2490,8 @@ static struct unit_test_suite security_testsuite = {
test_session_create_inv_configuration),
TEST_CASE_ST(ut_setup, ut_teardown,
test_session_create_inv_mempool),
+ TEST_CASE_ST(ut_setup, ut_teardown,
+ test_session_create_inv_sess_priv_mempool),
TEST_CASE_ST(ut_setup, ut_teardown,
test_session_create_mempool_empty),
TEST_CASE_ST(ut_setup, ut_teardown,
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index 127da2e4f..d30a79576 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -533,8 +533,12 @@ and this allows further acceleration of the offload of Crypto workloads.
The Security framework provides APIs to create and free sessions for crypto/ethernet
devices, where sessions are mempool objects. It is the application's responsibility
-to create and manage the session mempools. The mempool object size should be able to
-accommodate the driver's private data of security session.
+to create and manage two session mempools - one for session and other for session
+private data. The private session data mempool object size should be able to
+accommodate the driver's private data of security session. The application can get
+the size of session private data using API ``rte_security_session_get_size``.
+And the session mempool object size should be enough to accommodate
+``rte_security_session``.
Once the session mempools have been created, ``rte_security_session_create()``
is used to allocate and initialize a session for the required crypto/ethernet device.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 43cdd3c58..26be1b3de 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -164,13 +164,6 @@ Deprecation Notices
following the IPv6 header, as proposed in RFC
https://mails.dpdk.org/archives/dev/2020-August/177257.html.
-* security: The API ``rte_security_session_create`` takes only single mempool
- for session and session private data. So the application need to create
- mempool for twice the number of sessions needed and will also lead to
- wastage of memory as session private data need more memory compared to session.
- Hence the API will be modified to take two mempool pointers - one for session
- and one for private data.
-
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index f1b9b4dfe..0fb1b20cb 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -344,6 +344,12 @@ API Changes
* The structure ``rte_crypto_sym_vec`` is updated to support both
cpu_crypto synchrounous operation and asynchronous raw data-path APIs.
+* security: The API ``rte_security_session_create`` is updated to take two
+ mempool objects one for session and other for session private data.
+ So the application need to create two mempools and get the size of session
+ private data using API ``rte_security_session_get_size`` for private session
+ mempool.
+
ABI Changes
-----------
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 60132c4bd..2326089bb 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -2348,12 +2348,8 @@ session_pool_init(struct socket_ctx *ctx, int32_t socket_id, size_t sess_sz)
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
"sess_mp_%u", socket_id);
- /*
- * Doubled due to rte_security_session_create() uses one mempool for
- * session and for session private data.
- */
nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
- rte_lcore_count()) * 2;
+ rte_lcore_count());
sess_mp = rte_cryptodev_sym_session_pool_create(
mp_name, nb_sess, sess_sz, CDEV_MP_CACHE_SZ, 0,
socket_id);
@@ -2376,12 +2372,8 @@ session_priv_pool_init(struct socket_ctx *ctx, int32_t socket_id,
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
"sess_mp_priv_%u", socket_id);
- /*
- * Doubled due to rte_security_session_create() uses one mempool for
- * session and for session private data.
- */
nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
- rte_lcore_count()) * 2;
+ rte_lcore_count());
sess_mp = rte_mempool_create(mp_name,
nb_sess,
sess_sz,
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 01faa7ac7..6baeeb342 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -117,7 +117,8 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
set_ipsec_conf(sa, &(sess_conf.ipsec));
ips->security.ses = rte_security_session_create(ctx,
- &sess_conf, ipsec_ctx->session_priv_pool);
+ &sess_conf, ipsec_ctx->session_pool,
+ ipsec_ctx->session_priv_pool);
if (ips->security.ses == NULL) {
RTE_LOG(ERR, IPSEC,
"SEC Session init failed: err: %d\n", ret);
@@ -198,7 +199,8 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
}
ips->security.ses = rte_security_session_create(sec_ctx,
- &sess_conf, skt_ctx->session_pool);
+ &sess_conf, skt_ctx->session_pool,
+ skt_ctx->session_priv_pool);
if (ips->security.ses == NULL) {
RTE_LOG(ERR, IPSEC,
"SEC Session init failed: err: %d\n", ret);
@@ -378,7 +380,8 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
sess_conf.userdata = (void *) sa;
ips->security.ses = rte_security_session_create(sec_ctx,
- &sess_conf, skt_ctx->session_pool);
+ &sess_conf, skt_ctx->session_pool,
+ skt_ctx->session_priv_pool);
if (ips->security.ses == NULL) {
RTE_LOG(ERR, IPSEC,
"SEC Session init failed: err: %d\n", ret);
diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 515c29e04..ee4666026 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -26,18 +26,21 @@
struct rte_security_session *
rte_security_session_create(struct rte_security_ctx *instance,
struct rte_security_session_conf *conf,
- struct rte_mempool *mp)
+ struct rte_mempool *mp,
+ struct rte_mempool *priv_mp)
{
struct rte_security_session *sess = NULL;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_create, NULL, NULL);
RTE_PTR_OR_ERR_RET(conf, NULL);
RTE_PTR_OR_ERR_RET(mp, NULL);
+ RTE_PTR_OR_ERR_RET(priv_mp, NULL);
if (rte_mempool_get(mp, (void **)&sess))
return NULL;
- if (instance->ops->session_create(instance->device, conf, sess, mp)) {
+ if (instance->ops->session_create(instance->device, conf,
+ sess, priv_mp)) {
rte_mempool_put(mp, (void *)sess);
return NULL;
}
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 16839e539..1710cdd6a 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -386,6 +386,7 @@ struct rte_security_session {
* @param instance security instance
* @param conf session configuration parameters
* @param mp mempool to allocate session objects from
+ * @param priv_mp mempool to allocate session private data objects from
* @return
* - On success, pointer to session
* - On failure, NULL
@@ -393,7 +394,8 @@ struct rte_security_session {
struct rte_security_session *
rte_security_session_create(struct rte_security_ctx *instance,
struct rte_security_session_conf *conf,
- struct rte_mempool *mp);
+ struct rte_mempool *mp,
+ struct rte_mempool *priv_mp);
/**
* Update security session as specified by the session configuration
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v3] eventdev: update app and examples for new eventdev ABI
@ 2020-10-14 17:33 6% ` Timothy McDaniel
2020-10-14 20:01 4% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Timothy McDaniel @ 2020-10-14 17:33 UTC (permalink / raw)
To: Jerin Jacob, Harry van Haaren, Marko Kovacevic, Ori Kam,
Bruce Richardson, Radu Nicolau, Akhil Goyal, Tomasz Kantecki,
Sunil Kumar Kori, Pavan Nikhilesh
Cc: dev, erik.g.carrillo, gage.eads
Several data structures and constants changed, or were added,
in the previous patch. This commit updates the dependent
apps and examples to use the new ABI.
Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
Acked-by: Pavan Nikhilesh <pbhagavatula at marvell.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
app/test-eventdev/evt_common.h | 11 ++++++++
app/test-eventdev/test_order_atq.c | 28 +++++++++++++++------
app/test-eventdev/test_order_common.c | 1 +
app/test-eventdev/test_order_queue.c | 29 ++++++++++++++++------
app/test/test_eventdev.c | 4 +--
.../eventdev_pipeline/pipeline_worker_generic.c | 6 +++--
examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
examples/l2fwd-event/l2fwd_event_generic.c | 7 ++++--
examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +++--
examples/l3fwd/l3fwd_event_generic.c | 7 ++++--
examples/l3fwd/l3fwd_event_internal_port.c | 6 +++--
11 files changed, 80 insertions(+), 26 deletions(-)
diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
index f9d7378..a1da1cf 100644
--- a/app/test-eventdev/evt_common.h
+++ b/app/test-eventdev/evt_common.h
@@ -104,6 +104,16 @@ evt_has_all_types_queue(uint8_t dev_id)
true : false;
}
+static inline bool
+evt_has_flow_id(uint8_t dev_id)
+{
+ struct rte_event_dev_info dev_info;
+
+ rte_event_dev_info_get(dev_id, &dev_info);
+ return (dev_info.event_dev_cap & RTE_EVENT_DEV_CAP_CARRY_FLOW_ID) ?
+ true : false;
+}
+
static inline int
evt_service_setup(uint32_t service_id)
{
@@ -169,6 +179,7 @@ evt_configure_eventdev(struct evt_options *opt, uint8_t nb_queues,
.dequeue_timeout_ns = opt->deq_tmo_nsec,
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = info.max_num_events,
.nb_event_queue_flows = opt->nb_flows,
.nb_event_port_dequeue_depth =
diff --git a/app/test-eventdev/test_order_atq.c b/app/test-eventdev/test_order_atq.c
index 3366cfc..cfcb1dc 100644
--- a/app/test-eventdev/test_order_atq.c
+++ b/app/test-eventdev/test_order_atq.c
@@ -19,7 +19,7 @@ order_atq_process_stage_0(struct rte_event *const ev)
}
static int
-order_atq_worker(void *arg)
+order_atq_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_atq_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.sub_event_type == 0) { /* stage 0 from producer */
order_atq_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_atq_worker(void *arg)
}
static int
-order_atq_worker_burst(void *arg)
+order_atq_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,9 @@ order_atq_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].sub_event_type == 0) { /*stage 0 */
order_atq_process_stage_0(&ev[i]);
} else if (ev[i].sub_event_type == 1) { /* stage 1 */
@@ -95,11 +101,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_atq_worker_burst(arg);
- else
- return order_atq_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_atq_worker_burst(arg, true);
+ else
+ return order_atq_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_atq_worker(arg, true);
+ else
+ return order_atq_worker(arg, false);
+ }
}
static int
diff --git a/app/test-eventdev/test_order_common.c b/app/test-eventdev/test_order_common.c
index 4190f9a..7942390 100644
--- a/app/test-eventdev/test_order_common.c
+++ b/app/test-eventdev/test_order_common.c
@@ -49,6 +49,7 @@ order_producer(void *arg)
const uint32_t flow = (uintptr_t)m % nb_flows;
/* Maintain seq number per flow */
m->seqn = producer_flow_seq[flow]++;
+ m->udata64 = flow;
ev.flow_id = flow;
ev.mbuf = m;
diff --git a/app/test-eventdev/test_order_queue.c b/app/test-eventdev/test_order_queue.c
index 495efd9..1511c00 100644
--- a/app/test-eventdev/test_order_queue.c
+++ b/app/test-eventdev/test_order_queue.c
@@ -19,7 +19,7 @@ order_queue_process_stage_0(struct rte_event *const ev)
}
static int
-order_queue_worker(void *arg)
+order_queue_worker(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev;
@@ -34,6 +34,9 @@ order_queue_worker(void *arg)
continue;
}
+ if (!flow_id_cap)
+ ev.flow_id = ev.mbuf->udata64;
+
if (ev.queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev);
while (rte_event_enqueue_burst(dev_id, port, &ev, 1)
@@ -50,7 +53,7 @@ order_queue_worker(void *arg)
}
static int
-order_queue_worker_burst(void *arg)
+order_queue_worker_burst(void *arg, const bool flow_id_cap)
{
ORDER_WORKER_INIT;
struct rte_event ev[BURST_SIZE];
@@ -68,6 +71,10 @@ order_queue_worker_burst(void *arg)
}
for (i = 0; i < nb_rx; i++) {
+
+ if (!flow_id_cap)
+ ev[i].flow_id = ev[i].mbuf->udata64;
+
if (ev[i].queue_id == 0) { /* from ordered queue */
order_queue_process_stage_0(&ev[i]);
} else if (ev[i].queue_id == 1) {/* from atomic queue */
@@ -95,11 +102,19 @@ worker_wrapper(void *arg)
{
struct worker_data *w = arg;
const bool burst = evt_has_burst_mode(w->dev_id);
-
- if (burst)
- return order_queue_worker_burst(arg);
- else
- return order_queue_worker(arg);
+ const bool flow_id_cap = evt_has_flow_id(w->dev_id);
+
+ if (burst) {
+ if (flow_id_cap)
+ return order_queue_worker_burst(arg, true);
+ else
+ return order_queue_worker_burst(arg, false);
+ } else {
+ if (flow_id_cap)
+ return order_queue_worker(arg, true);
+ else
+ return order_queue_worker(arg, false);
+ }
}
static int
diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
index 43ccb1c..62019c1 100644
--- a/app/test/test_eventdev.c
+++ b/app/test/test_eventdev.c
@@ -559,10 +559,10 @@ test_eventdev_port_setup(void)
if (!(info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
pconf.enqueue_depth = info.max_event_port_enqueue_depth;
- pconf.disable_implicit_release = 1;
+ pconf.event_port_cfg = RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
ret = rte_event_port_setup(TEST_DEV_ID, 0, &pconf);
TEST_ASSERT(ret == -EINVAL, "Expected -EINVAL, %d", ret);
- pconf.disable_implicit_release = 0;
+ pconf.event_port_cfg = 0;
}
ret = rte_event_port_setup(TEST_DEV_ID, info.max_event_ports,
diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c b/examples/eventdev_pipeline/pipeline_worker_generic.c
index 42ff4ee..f70ab0c 100644
--- a/examples/eventdev_pipeline/pipeline_worker_generic.c
+++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
@@ -129,6 +129,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 1,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
@@ -143,7 +144,7 @@ setup_eventdev_generic(struct worker_data *worker_data)
.schedule_type = cdata.queue_type,
.priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
.nb_atomic_flows = 1024,
- .nb_atomic_order_sequences = 1024,
+ .nb_atomic_order_sequences = 1024,
};
struct rte_event_queue_conf tx_q_conf = {
.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST,
@@ -167,7 +168,8 @@ setup_eventdev_generic(struct worker_data *worker_data)
disable_implicit_release = (dev_info.event_dev_cap &
RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
- wkr_p_conf.disable_implicit_release = disable_implicit_release;
+ wkr_p_conf.event_port_cfg = disable_implicit_release ?
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
if (dev_info.max_num_events < config.nb_events_limit)
config.nb_events_limit = dev_info.max_num_events;
diff --git a/examples/eventdev_pipeline/pipeline_worker_tx.c b/examples/eventdev_pipeline/pipeline_worker_tx.c
index 55bb2f7..ca6cd20 100644
--- a/examples/eventdev_pipeline/pipeline_worker_tx.c
+++ b/examples/eventdev_pipeline/pipeline_worker_tx.c
@@ -436,6 +436,7 @@ setup_eventdev_worker_tx_enq(struct worker_data *worker_data)
struct rte_event_dev_config config = {
.nb_event_queues = nb_queues,
.nb_event_ports = nb_ports,
+ .nb_single_link_event_port_queues = 0,
.nb_events_limit = 4096,
.nb_event_queue_flows = 1024,
.nb_event_port_dequeue_depth = 128,
diff --git a/examples/l2fwd-event/l2fwd_event_generic.c b/examples/l2fwd-event/l2fwd_event_generic.c
index 2dc95e5..9a3167c 100644
--- a/examples/l2fwd-event/l2fwd_event_generic.c
+++ b/examples/l2fwd-event/l2fwd_event_generic.c
@@ -126,8 +126,11 @@ l2fwd_event_port_setup_generic(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c b/examples/l2fwd-event/l2fwd_event_internal_port.c
index 63d57b4..203a14c 100644
--- a/examples/l2fwd-event/l2fwd_event_internal_port.c
+++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
@@ -123,8 +123,10 @@ l2fwd_event_port_setup_internal_port(struct l2fwd_resources *rsrc)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
diff --git a/examples/l3fwd/l3fwd_event_generic.c b/examples/l3fwd/l3fwd_event_generic.c
index f8c9843..c80573f 100644
--- a/examples/l3fwd/l3fwd_event_generic.c
+++ b/examples/l3fwd/l3fwd_event_generic.c
@@ -115,8 +115,11 @@ l3fwd_event_port_setup_generic(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
+
evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
diff --git a/examples/l3fwd/l3fwd_event_internal_port.c b/examples/l3fwd/l3fwd_event_internal_port.c
index 03ac581..9916a7f 100644
--- a/examples/l3fwd/l3fwd_event_internal_port.c
+++ b/examples/l3fwd/l3fwd_event_internal_port.c
@@ -113,8 +113,10 @@ l3fwd_event_port_setup_internal_port(void)
if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
event_p_conf.enqueue_depth = def_p_conf.enqueue_depth;
- event_p_conf.disable_implicit_release =
- evt_rsrc->disable_implicit_release;
+ event_p_conf.event_port_cfg = 0;
+ if (evt_rsrc->disable_implicit_release)
+ event_p_conf.event_port_cfg |=
+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
event_p_id++) {
--
2.6.4
^ permalink raw reply [relevance 6%]
* Re: [dpdk-dev] [PATCH v7 0/5] support match on L3 fragmented packets
2020-10-14 16:35 3% ` [dpdk-dev] [PATCH v7 0/5] " Dekel Peled
2020-10-14 16:35 4% ` [dpdk-dev] [PATCH v7 1/5] ethdev: add extensions attributes to IPv6 item Dekel Peled
@ 2020-10-14 17:18 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2020-10-14 17:18 UTC (permalink / raw)
To: Dekel Peled, orika, thomas, arybchenko, konstantin.ananyev,
olivier.matz, wenzhuo.lu, beilei.xing, bernard.iremonger, matan,
shahafs, viacheslavo
Cc: dev
On 10/14/2020 5:35 PM, Dekel Peled wrote:
> This series implements support of matching on packets based on the
> fragmentation attribute of the packet, i.e. if packet is a fragment
> of a larger packet, or the opposite - packet is not a fragment.
>
> In ethdev, add API to support IPv6 extension headers, and specifically
> the IPv6 fragment extension header item.
> Testpmd CLI is updated accordingly.
> Documentation is updated accordingly.
>
> ---
> v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
> v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
> v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
> v5: update following rebase on recent ICMP changes.
> v6: - move MLX5 PMD patches to separate series.
> - rename IPv6 extension flags for clarity (e.g. frag_ext_exist renamed to has_frag_ext).
> v7: remove the announcement from deprecation file.
> ---
>
> Dekel Peled (5):
> ethdev: add extensions attributes to IPv6 item
> ethdev: add IPv6 fragment extension header item
> app/testpmd: support IPv4 fragments
> app/testpmd: support IPv6 fragments
> app/testpmd: support IPv6 fragment extension item
>
Series applied to dpdk-next-net/main, thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 0/5] support match on L3 fragmented packets
@ 2020-10-14 16:35 3% ` Dekel Peled
2020-10-14 16:35 4% ` [dpdk-dev] [PATCH v7 1/5] ethdev: add extensions attributes to IPv6 item Dekel Peled
2020-10-14 17:18 0% ` [dpdk-dev] [PATCH v7 0/5] support match on L3 fragmented packets Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Dekel Peled @ 2020-10-14 16:35 UTC (permalink / raw)
To: orika, thomas, ferruh.yigit, arybchenko, konstantin.ananyev,
olivier.matz, wenzhuo.lu, beilei.xing, bernard.iremonger, matan,
shahafs, viacheslavo
Cc: dev
This series implements support of matching on packets based on the
fragmentation attribute of the packet, i.e. if packet is a fragment
of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically
the IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
v5: update following rebase on recent ICMP changes.
v6: - move MLX5 PMD patches to separate series.
- rename IPv6 extension flags for clarity (e.g. frag_ext_exist renamed to has_frag_ext).
v7: remove the announcement from deprecation file.
---
Dekel Peled (5):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item
app/testpmd: support IPv4 fragments
app/testpmd: support IPv6 fragments
app/testpmd: support IPv6 fragment extension item
app/test-pmd/cmdline_flow.c | 53 ++++++++++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 32 ++++++++++++++++++--
doc/guides/rel_notes/deprecation.rst | 5 ----
doc/guides/rel_notes/release_20_11.rst | 5 ++++
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 43 +++++++++++++++++++++++++--
lib/librte_ip_frag/rte_ip_frag.h | 26 ++---------------
lib/librte_net/rte_ip.h | 26 +++++++++++++++--
8 files changed, 155 insertions(+), 36 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 1/5] ethdev: add extensions attributes to IPv6 item
2020-10-14 16:35 3% ` [dpdk-dev] [PATCH v7 0/5] " Dekel Peled
@ 2020-10-14 16:35 4% ` Dekel Peled
2020-10-14 17:18 0% ` [dpdk-dev] [PATCH v7 0/5] support match on L3 fragmented packets Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Dekel Peled @ 2020-10-14 16:35 UTC (permalink / raw)
To: orika, thomas, ferruh.yigit, arybchenko, konstantin.ananyev,
olivier.matz, wenzhuo.lu, beilei.xing, bernard.iremonger, matan,
shahafs, viacheslavo
Cc: dev
Using the current implementation of DPDK, an application cannot match on
IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension
header only. Following extension headers can't be identified by
inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers
can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header
(which is implemented in a later patch of this series).
Non-fragmented packets don't contain the fragment extension header.
For an application to match on non-fragmented IPv6 packets, the current
implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional
extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct.
These values will indicate the existence of every defined extension
header type, providing simple means for identification of existing
extensions in the packet header.
Continuing the above example, fragmented packets can be identified using
the specific value indicating existence of fragment extension header.
To match on non-fragmented IPv6 packets, need to use has_frag_ext 0.
To match on fragmented IPv6 packets, need to use has_frag_ext 1.
To match on any IPv6 packets, the has_frag_ext field should
not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Signed-off-by: Dekel Peled <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/prog_guide/rte_flow.rst | 20 +++++++++++++++++---
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_20_11.rst | 5 +++++
lib/librte_ethdev/rte_flow.h | 23 +++++++++++++++++++++--
4 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index f26a6c2..97fdf2a 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -946,11 +946,25 @@ Item: ``IPV6``
Matches an IPv6 header.
-Note: IPv6 options are handled by dedicated pattern items, see `Item:
-IPV6_EXT`_.
+Dedicated flags indicate if header contains specific extension headers.
+To match on packets containing a specific extension header, an application
+should match on the dedicated flag set to 1.
+To match on packets not containing a specific extension header, an application
+should match on the dedicated flag clear to 0.
+In case application doesn't care about the existence of a specific extension
+header, it should not specify the dedicated flag for matching.
- ``hdr``: IPv6 header definition (``rte_ip.h``).
-- Default ``mask`` matches source and destination addresses only.
+- ``has_hop_ext``: header contains Hop-by-Hop Options extension header.
+- ``has_route_ext``: header contains Routing extension header.
+- ``has_frag_ext``: header contains Fragment extension header.
+- ``has_auth_ext``: header contains Authentication extension header.
+- ``has_esp_ext``: header contains Encapsulation Security Payload extension header.
+- ``has_dest_ext``: header contains Destination Options extension header.
+- ``has_mobil_ext``: header contains Mobility extension header.
+- ``has_hip_ext``: header contains Host Identity Protocol extension header.
+- ``has_shim6_ext``: header contains Shim6 Protocol extension header.
+- Default ``mask`` matches ``hdr`` source and destination addresses only.
Item: ``ICMP``
^^^^^^^^^^^^^^
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 584e720..87a7c44 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -159,11 +159,6 @@ Deprecation Notices
or absence of a VLAN header following the current header, as proposed in RFC
https://mails.dpdk.org/archives/dev/2020-August/177536.html.
-* ethdev: The ``struct rte_flow_item_ipv6`` struct will be modified to include
- additional values, indicating existence or absence of IPv6 extension headers
- following the IPv6 header, as proposed in RFC
- https://mails.dpdk.org/archives/dev/2020-August/177257.html.
-
* security: The API ``rte_security_session_create`` takes only single mempool
for session and session private data. So the application need to create
mempool for twice the number of sessions needed and will also lead to
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 30db8f2..730e9df 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -351,6 +351,11 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+ * Added extensions' attributes to struct ``rte_flow_item_ipv6``.
+ A set of additional values added to struct, indicating the existence of
+ every defined extension header type.
+ Applications should use the new values for identification of existing
+ extensions in the packet header.
Known Issues
------------
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 3d5fb09..aa18925 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -792,11 +792,30 @@ struct rte_flow_item_ipv4 {
*
* Matches an IPv6 header.
*
- * Note: IPv6 options are handled by dedicated pattern items, see
- * RTE_FLOW_ITEM_TYPE_IPV6_EXT.
+ * Dedicated flags indicate if header contains specific extension headers.
*/
struct rte_flow_item_ipv6 {
struct rte_ipv6_hdr hdr; /**< IPv6 header definition. */
+ uint32_t has_hop_ext:1;
+ /**< Header contains Hop-by-Hop Options extension header. */
+ uint32_t has_route_ext:1;
+ /**< Header contains Routing extension header. */
+ uint32_t has_frag_ext:1;
+ /**< Header contains Fragment extension header. */
+ uint32_t has_auth_ext:1;
+ /**< Header contains Authentication extension header. */
+ uint32_t has_esp_ext:1;
+ /**< Header contains Encapsulation Security Payload extension header. */
+ uint32_t has_dest_ext:1;
+ /**< Header contains Destination Options extension header. */
+ uint32_t has_mobil_ext:1;
+ /**< Header contains Mobility extension header. */
+ uint32_t has_hip_ext:1;
+ /**< Header contains Host Identity Protocol extension header. */
+ uint32_t has_shim6_ext:1;
+ /**< Header contains Shim6 Protocol extension header. */
+ uint32_t reserved:23;
+ /**< Reserved for future extension headers, must be zero. */
};
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 03/18] eal: rename lcore word choices
@ 2020-10-14 15:27 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-14 15:27 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Anatoly Burakov
Replace master lcore with main lcore and
replace slave lcore with worker lcore.
Keep the old functions and macros but mark them as deprecated
for this release.
The "--master-lcore" command line option is also deprecated
and any usage will print a warning and use "--main-lcore"
as replacement.
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 19 -------
doc/guides/rel_notes/release_20_11.rst | 11 ++++
lib/librte_eal/common/eal_common_dynmem.c | 10 ++--
lib/librte_eal/common/eal_common_launch.c | 36 ++++++------
lib/librte_eal/common/eal_common_lcore.c | 8 +--
lib/librte_eal/common/eal_common_options.c | 64 ++++++++++++----------
lib/librte_eal/common/eal_options.h | 2 +
lib/librte_eal/common/eal_private.h | 6 +-
lib/librte_eal/common/rte_random.c | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
lib/librte_eal/freebsd/eal.c | 28 +++++-----
lib/librte_eal/freebsd/eal_thread.c | 32 +++++------
lib/librte_eal/include/rte_eal.h | 4 +-
lib/librte_eal/include/rte_eal_trace.h | 4 +-
lib/librte_eal/include/rte_launch.h | 60 ++++++++++----------
lib/librte_eal/include/rte_lcore.h | 35 ++++++++----
lib/librte_eal/linux/eal.c | 28 +++++-----
lib/librte_eal/linux/eal_memory.c | 10 ++--
lib/librte_eal/linux/eal_thread.c | 32 +++++------
lib/librte_eal/rte_eal_version.map | 2 +-
lib/librte_eal/windows/eal.c | 16 +++---
lib/librte_eal/windows/eal_thread.c | 30 +++++-----
22 files changed, 230 insertions(+), 211 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 584e72087934..7271e9ca4d39 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,25 +20,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: To be more inclusive in choice of naming, the DPDK project
- will replace uses of master/slave in the API's and command line arguments.
-
- References to master/slave in relation to lcore will be renamed
- to initial/worker. The function ``rte_get_master_lcore()``
- will be renamed to ``rte_get_initial_lcore()``.
- For the 20.11 release, both names will be present and the
- old function will be marked with the deprecated tag.
- The old function will be removed in a future version.
-
- The iterator for worker lcores will also change:
- ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
- ``RTE_LCORE_FOREACH_WORKER``.
-
- The ``master-lcore`` argument to testpmd will be replaced
- with ``initial-lcore``. The old ``master-lcore`` argument
- will produce a runtime notification in 20.11 release, and
- be removed completely in a future release.
-
* 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 as well as macros.
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 71665c1de65f..bbc64ea2e3a6 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -298,6 +298,17 @@ API Changes
* bpf: ``RTE_BPF_XTYPE_NUM`` has been dropped from ``rte_bpf_xtype``.
+* eal: Changed the function ``rte_get_master_lcore()`` is
+ replaced to ``rte_get_main_lcore()``. The old function is deprecated.
+
+ The iterator for worker lcores will also change:
+ ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
+ ``RTE_LCORE_FOREACH_WORKER``.
+
+ The ``master-lcore`` argument to testpmd will be replaced
+ with ``main-lcore``. The old ``master-lcore`` argument
+ will produce a runtime notification in 20.11 release, and
+ be removed completely in a future release.
ABI Changes
-----------
diff --git a/lib/librte_eal/common/eal_common_dynmem.c b/lib/librte_eal/common/eal_common_dynmem.c
index 614648d8a4de..1cefe52443c4 100644
--- a/lib/librte_eal/common/eal_common_dynmem.c
+++ b/lib/librte_eal/common/eal_common_dynmem.c
@@ -427,19 +427,19 @@ eal_dynmem_calc_num_pages_per_socket(
total_size -= default_size;
}
#else
- /* in 32-bit mode, allocate all of the memory only on master
+ /* in 32-bit mode, allocate all of the memory only on main
* lcore socket
*/
total_size = internal_conf->memory;
for (socket = 0; socket < RTE_MAX_NUMA_NODES && total_size != 0;
socket++) {
struct rte_config *cfg = rte_eal_get_configuration();
- unsigned int master_lcore_socket;
+ unsigned int main_lcore_socket;
- master_lcore_socket =
- rte_lcore_to_socket_id(cfg->master_lcore);
+ main_lcore_socket =
+ rte_lcore_to_socket_id(cfg->main_lcore);
- if (master_lcore_socket != socket)
+ if (main_lcore_socket != socket)
continue;
/* Update sizes */
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index cf52d717f68e..34f854ad80c8 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -21,55 +21,55 @@
* Wait until a lcore finished its job.
*/
int
-rte_eal_wait_lcore(unsigned slave_id)
+rte_eal_wait_lcore(unsigned worker_id)
{
- if (lcore_config[slave_id].state == WAIT)
+ if (lcore_config[worker_id].state == WAIT)
return 0;
- while (lcore_config[slave_id].state != WAIT &&
- lcore_config[slave_id].state != FINISHED)
+ while (lcore_config[worker_id].state != WAIT &&
+ lcore_config[worker_id].state != FINISHED)
rte_pause();
rte_rmb();
/* we are in finished state, go to wait state */
- lcore_config[slave_id].state = WAIT;
- return lcore_config[slave_id].ret;
+ lcore_config[worker_id].state = WAIT;
+ return lcore_config[worker_id].ret;
}
/*
- * Check that every SLAVE lcores are in WAIT state, then call
- * rte_eal_remote_launch() for all of them. If call_master is true
- * (set to CALL_MASTER), also call the function on the master lcore.
+ * Check that every WORKER lcores are in WAIT state, then call
+ * rte_eal_remote_launch() for all of them. If call_main is true
+ * (set to CALL_MAIN), also call the function on the main lcore.
*/
int
rte_eal_mp_remote_launch(int (*f)(void *), void *arg,
- enum rte_rmt_call_master_t call_master)
+ enum rte_rmt_call_main_t call_main)
{
int lcore_id;
- int master = rte_get_master_lcore();
+ int main_lcore = rte_get_main_lcore();
/* check state of lcores */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (lcore_config[lcore_id].state != WAIT)
return -EBUSY;
}
/* send messages to cores */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_remote_launch(f, arg, lcore_id);
}
- if (call_master == CALL_MASTER) {
- lcore_config[master].ret = f(arg);
- lcore_config[master].state = FINISHED;
+ if (call_main == CALL_MAIN) {
+ lcore_config[main_lcore].ret = f(arg);
+ lcore_config[main_lcore].state = FINISHED;
}
return 0;
}
/*
- * Return the state of the lcore identified by slave_id.
+ * Return the state of the lcore identified by worker_id.
*/
enum rte_lcore_state_t
rte_eal_get_lcore_state(unsigned lcore_id)
@@ -86,7 +86,7 @@ rte_eal_mp_wait_lcore(void)
{
unsigned lcore_id;
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_wait_lcore(lcore_id);
}
}
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index d64569b3c758..66d6bad1a7d7 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -18,9 +18,9 @@
#include "eal_private.h"
#include "eal_thread.h"
-unsigned int rte_get_master_lcore(void)
+unsigned int rte_get_main_lcore(void)
{
- return rte_eal_get_configuration()->master_lcore;
+ return rte_eal_get_configuration()->main_lcore;
}
unsigned int rte_lcore_count(void)
@@ -93,7 +93,7 @@ int rte_lcore_is_enabled(unsigned int lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap)
+unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap)
{
i++;
if (wrap)
@@ -101,7 +101,7 @@ unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap)
while (i < RTE_MAX_LCORE) {
if (!rte_lcore_is_enabled(i) ||
- (skip_master && (i == rte_get_master_lcore()))) {
+ (skip_main && (i == rte_get_main_lcore()))) {
i++;
if (wrap)
i %= RTE_MAX_LCORE;
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index a5426e12346a..d221886eb22c 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -81,6 +81,7 @@ eal_long_options[] = {
{OPT_TRACE_BUF_SIZE, 1, NULL, OPT_TRACE_BUF_SIZE_NUM },
{OPT_TRACE_MODE, 1, NULL, OPT_TRACE_MODE_NUM },
{OPT_MASTER_LCORE, 1, NULL, OPT_MASTER_LCORE_NUM },
+ {OPT_MAIN_LCORE, 1, NULL, OPT_MAIN_LCORE_NUM },
{OPT_MBUF_POOL_OPS_NAME, 1, NULL, OPT_MBUF_POOL_OPS_NAME_NUM},
{OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
{OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
@@ -144,7 +145,7 @@ struct device_option {
static struct device_option_list devopt_list =
TAILQ_HEAD_INITIALIZER(devopt_list);
-static int master_lcore_parsed;
+static int main_lcore_parsed;
static int mem_parsed;
static int core_parsed;
@@ -575,12 +576,12 @@ eal_parse_service_coremask(const char *coremask)
for (j = 0; j < BITS_PER_HEX && idx < RTE_MAX_LCORE;
j++, idx++) {
if ((1 << j) & val) {
- /* handle master lcore already parsed */
+ /* handle main lcore already parsed */
uint32_t lcore = idx;
- if (master_lcore_parsed &&
- cfg->master_lcore == lcore) {
+ if (main_lcore_parsed &&
+ cfg->main_lcore == lcore) {
RTE_LOG(ERR, EAL,
- "lcore %u is master lcore, cannot use as service core\n",
+ "lcore %u is main lcore, cannot use as service core\n",
idx);
return -1;
}
@@ -748,12 +749,12 @@ eal_parse_service_corelist(const char *corelist)
min = idx;
for (idx = min; idx <= max; idx++) {
if (cfg->lcore_role[idx] != ROLE_SERVICE) {
- /* handle master lcore already parsed */
+ /* handle main lcore already parsed */
uint32_t lcore = idx;
- if (cfg->master_lcore == lcore &&
- master_lcore_parsed) {
+ if (cfg->main_lcore == lcore &&
+ main_lcore_parsed) {
RTE_LOG(ERR, EAL,
- "Error: lcore %u is master lcore, cannot use as service core\n",
+ "Error: lcore %u is main lcore, cannot use as service core\n",
idx);
return -1;
}
@@ -836,25 +837,25 @@ eal_parse_corelist(const char *corelist, int *cores)
return 0;
}
-/* Changes the lcore id of the master thread */
+/* Changes the lcore id of the main thread */
static int
-eal_parse_master_lcore(const char *arg)
+eal_parse_main_lcore(const char *arg)
{
char *parsing_end;
struct rte_config *cfg = rte_eal_get_configuration();
errno = 0;
- cfg->master_lcore = (uint32_t) strtol(arg, &parsing_end, 0);
+ cfg->main_lcore = (uint32_t) strtol(arg, &parsing_end, 0);
if (errno || parsing_end[0] != 0)
return -1;
- if (cfg->master_lcore >= RTE_MAX_LCORE)
+ if (cfg->main_lcore >= RTE_MAX_LCORE)
return -1;
- master_lcore_parsed = 1;
+ main_lcore_parsed = 1;
- /* ensure master core is not used as service core */
- if (lcore_config[cfg->master_lcore].core_role == ROLE_SERVICE) {
+ /* ensure main core is not used as service core */
+ if (lcore_config[cfg->main_lcore].core_role == ROLE_SERVICE) {
RTE_LOG(ERR, EAL,
- "Error: Master lcore is used as a service core\n");
+ "Error: Main lcore is used as a service core\n");
return -1;
}
@@ -1593,9 +1594,14 @@ eal_parse_common_option(int opt, const char *optarg,
break;
case OPT_MASTER_LCORE_NUM:
- if (eal_parse_master_lcore(optarg) < 0) {
+ fprintf(stderr,
+ "Option --" OPT_MASTER_LCORE
+ " is deprecated use " OPT_MAIN_LCORE "\n");
+ /* fallthrough */
+ case OPT_MAIN_LCORE_NUM:
+ if (eal_parse_main_lcore(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
- OPT_MASTER_LCORE "\n");
+ OPT_MAIN_LCORE "\n");
return -1;
}
break;
@@ -1763,9 +1769,9 @@ compute_ctrl_threads_cpuset(struct internal_config *internal_cfg)
RTE_CPU_AND(cpuset, cpuset, &default_set);
- /* if no remaining cpu, use master lcore cpu affinity */
+ /* if no remaining cpu, use main lcore cpu affinity */
if (!CPU_COUNT(cpuset)) {
- memcpy(cpuset, &lcore_config[rte_get_master_lcore()].cpuset,
+ memcpy(cpuset, &lcore_config[rte_get_main_lcore()].cpuset,
sizeof(*cpuset));
}
}
@@ -1797,12 +1803,12 @@ eal_adjust_config(struct internal_config *internal_cfg)
if (internal_conf->process_type == RTE_PROC_AUTO)
internal_conf->process_type = eal_proc_type_detect();
- /* default master lcore is the first one */
- if (!master_lcore_parsed) {
- cfg->master_lcore = rte_get_next_lcore(-1, 0, 0);
- if (cfg->master_lcore >= RTE_MAX_LCORE)
+ /* default main lcore is the first one */
+ if (!main_lcore_parsed) {
+ cfg->main_lcore = rte_get_next_lcore(-1, 0, 0);
+ if (cfg->main_lcore >= RTE_MAX_LCORE)
return -1;
- lcore_config[cfg->master_lcore].core_role = ROLE_RTE;
+ lcore_config[cfg->main_lcore].core_role = ROLE_RTE;
}
compute_ctrl_threads_cpuset(internal_cfg);
@@ -1822,8 +1828,8 @@ eal_check_common_options(struct internal_config *internal_cfg)
const struct internal_config *internal_conf =
eal_get_internal_configuration();
- if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
- RTE_LOG(ERR, EAL, "Master lcore is not enabled for DPDK\n");
+ if (cfg->lcore_role[cfg->main_lcore] != ROLE_RTE) {
+ RTE_LOG(ERR, EAL, "Main lcore is not enabled for DPDK\n");
return -1;
}
@@ -1921,7 +1927,7 @@ eal_common_usage(void)
" '( )' can be omitted for single element group,\n"
" '@' can be omitted if cpus and lcores have the same value\n"
" -s SERVICE COREMASK Hexadecimal bitmask of cores to be used as service cores\n"
- " --"OPT_MASTER_LCORE" ID Core ID that is used as master\n"
+ " --"OPT_MAIN_LCORE" ID Core ID that is used as main\n"
" --"OPT_MBUF_POOL_OPS_NAME" Pool ops name for mbuf to use\n"
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index 89769d48b487..d363228a7a25 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -43,6 +43,8 @@ enum {
OPT_TRACE_BUF_SIZE_NUM,
#define OPT_TRACE_MODE "trace-mode"
OPT_TRACE_MODE_NUM,
+#define OPT_MAIN_LCORE "main-lcore"
+ OPT_MAIN_LCORE_NUM,
#define OPT_MASTER_LCORE "master-lcore"
OPT_MASTER_LCORE_NUM,
#define OPT_MBUF_POOL_OPS_NAME "mbuf-pool-ops-name"
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index a6a6381567f4..4684c4c7df19 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -20,8 +20,8 @@
*/
struct lcore_config {
pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
+ int pipe_main2worker[2]; /**< communication pipe with main */
+ int pipe_worker2main[2]; /**< communication pipe with main */
lcore_function_t * volatile f; /**< function to call */
void * volatile arg; /**< argument of function */
@@ -42,7 +42,7 @@ extern struct lcore_config lcore_config[RTE_MAX_LCORE];
* The global RTE configuration structure.
*/
struct rte_config {
- uint32_t master_lcore; /**< Id of the master lcore */
+ uint32_t main_lcore; /**< Id of the main lcore */
uint32_t lcore_count; /**< Number of available logical cores. */
uint32_t numa_node_count; /**< Number of detected NUMA nodes. */
uint32_t numa_nodes[RTE_MAX_NUMA_NODES]; /**< List of detected NUMA nodes. */
diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
index b2c5416b331d..ce21c2242a22 100644
--- a/lib/librte_eal/common/rte_random.c
+++ b/lib/librte_eal/common/rte_random.c
@@ -122,7 +122,7 @@ struct rte_rand_state *__rte_rand_get_state(void)
lcore_id = rte_lcore_id();
if (unlikely(lcore_id == LCORE_ID_ANY))
- lcore_id = rte_get_master_lcore();
+ lcore_id = rte_get_main_lcore();
return &rand_states[lcore_id];
}
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 98565bbef340..6c955d319ad4 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -107,7 +107,7 @@ rte_service_init(void)
struct rte_config *cfg = rte_eal_get_configuration();
for (i = 0; i < RTE_MAX_LCORE; i++) {
if (lcore_config[i].core_role == ROLE_SERVICE) {
- if ((unsigned int)i == cfg->master_lcore)
+ if ((unsigned int)i == cfg->main_lcore)
continue;
rte_service_lcore_add(i);
count++;
diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
index ccea60afe77b..d6ea02375025 100644
--- a/lib/librte_eal/freebsd/eal.c
+++ b/lib/librte_eal/freebsd/eal.c
@@ -625,10 +625,10 @@ eal_check_mem_on_local_socket(void)
int socket_id;
const struct rte_config *config = rte_eal_get_configuration();
- socket_id = rte_lcore_to_socket_id(config->master_lcore);
+ socket_id = rte_lcore_to_socket_id(config->main_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
- RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
+ RTE_LOG(WARNING, EAL, "WARNING: Main core has no memory on local socket!\n");
}
@@ -851,29 +851,29 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
if (pthread_setaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
- &lcore_config[config->master_lcore].cpuset) != 0) {
+ &lcore_config[config->main_lcore].cpuset) != 0) {
rte_eal_init_alert("Cannot set affinity");
rte_errno = EINVAL;
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%p;cpuset=[%s%s])\n",
- config->master_lcore, thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Main lcore %u is ready (tid=%p;cpuset=[%s%s])\n",
+ config->main_lcore, thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_main2worker) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_worker2main) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -886,7 +886,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-worker-%d", i);
rte_thread_setname(lcore_config[i].thread_id, thread_name);
ret = pthread_setaffinity_np(lcore_config[i].thread_id,
@@ -896,10 +896,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
/* initialize services so vdevs register service during bus_probe. */
diff --git a/lib/librte_eal/freebsd/eal_thread.c b/lib/librte_eal/freebsd/eal_thread.c
index 99b5fefc4c5b..1dce9b04f24a 100644
--- a/lib/librte_eal/freebsd/eal_thread.c
+++ b/lib/librte_eal/freebsd/eal_thread.c
@@ -26,35 +26,35 @@
#include "eal_thread.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
+rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
int rc = -EBUSY;
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
goto finish;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
+ n = write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = read(s2m, &c, 1);
+ n = read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -62,7 +62,7 @@ rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
rc = 0;
finish:
- rte_eal_trace_thread_remote_launch(f, arg, slave_id, rc);
+ rte_eal_trace_thread_remote_launch(f, arg, worker_id, rc);
return rc;
}
@@ -74,21 +74,21 @@ eal_thread_loop(__rte_unused void *arg)
int n, ret;
unsigned lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -104,7 +104,7 @@ eal_thread_loop(__rte_unused void *arg)
/* wait command */
do {
- n = read(m2s, &c, 1);
+ n = read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -115,7 +115,7 @@ eal_thread_loop(__rte_unused void *arg)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(s2m, &c, 1);
+ n = write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
diff --git a/lib/librte_eal/include/rte_eal.h b/lib/librte_eal/include/rte_eal.h
index e3c2ef185eed..0ae12cf4fbac 100644
--- a/lib/librte_eal/include/rte_eal.h
+++ b/lib/librte_eal/include/rte_eal.h
@@ -65,11 +65,11 @@ int rte_eal_iopl_init(void);
/**
* Initialize the Environment Abstraction Layer (EAL).
*
- * This function is to be executed on the MASTER lcore only, as soon
+ * This function is to be executed on the MAIN lcore only, as soon
* as possible in the application's main() function.
*
* The function finishes the initialization process before main() is called.
- * It puts the SLAVE lcores in the WAIT state.
+ * It puts the WORKER lcores in the WAIT state.
*
* When the multi-partition feature is supported, depending on the
* configuration (if CONFIG_RTE_EAL_MAIN_PARTITION is disabled), this
diff --git a/lib/librte_eal/include/rte_eal_trace.h b/lib/librte_eal/include/rte_eal_trace.h
index 19df549d29be..495ae1ee1d61 100644
--- a/lib/librte_eal/include/rte_eal_trace.h
+++ b/lib/librte_eal/include/rte_eal_trace.h
@@ -264,10 +264,10 @@ RTE_TRACE_POINT(
RTE_TRACE_POINT(
rte_eal_trace_thread_remote_launch,
RTE_TRACE_POINT_ARGS(int (*f)(void *), void *arg,
- unsigned int slave_id, int rc),
+ unsigned int worker_id, int rc),
rte_trace_point_emit_ptr(f);
rte_trace_point_emit_ptr(arg);
- rte_trace_point_emit_u32(slave_id);
+ rte_trace_point_emit_u32(worker_id);
rte_trace_point_emit_int(rc);
)
RTE_TRACE_POINT(
diff --git a/lib/librte_eal/include/rte_launch.h b/lib/librte_eal/include/rte_launch.h
index 06a671752ace..22a901ce62f6 100644
--- a/lib/librte_eal/include/rte_launch.h
+++ b/lib/librte_eal/include/rte_launch.h
@@ -32,12 +32,12 @@ typedef int (lcore_function_t)(void *);
/**
* Launch a function on another lcore.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * Sends a message to a slave lcore (identified by the slave_id) that
+ * Sends a message to a worker lcore (identified by the worker_id) that
* is in the WAIT state (this is true after the first call to
* rte_eal_init()). This can be checked by first calling
- * rte_eal_wait_lcore(slave_id).
+ * rte_eal_wait_lcore(worker_id).
*
* When the remote lcore receives the message, it switches to
* the RUNNING state, then calls the function f with argument arg. Once the
@@ -45,7 +45,7 @@ typedef int (lcore_function_t)(void *);
* the return value of f is stored in a local variable to be read using
* rte_eal_wait_lcore().
*
- * The MASTER lcore returns as soon as the message is sent and knows
+ * The MAIN lcore returns as soon as the message is sent and knows
* nothing about the completion of f.
*
* Note: This function is not designed to offer optimum
@@ -56,37 +56,41 @@ typedef int (lcore_function_t)(void *);
* The function to be called.
* @param arg
* The argument for the function.
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore on which the function should be executed.
* @return
* - 0: Success. Execution of function f started on the remote lcore.
* - (-EBUSY): The remote lcore is not in a WAIT state.
*/
-int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned slave_id);
+int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned worker_id);
/**
- * This enum indicates whether the master core must execute the handler
+ * This enum indicates whether the main core must execute the handler
* launched on all logical cores.
*/
-enum rte_rmt_call_master_t {
- SKIP_MASTER = 0, /**< lcore handler not executed by master core. */
- CALL_MASTER, /**< lcore handler executed by master core. */
+enum rte_rmt_call_main_t {
+ SKIP_MAIN = 0, /**< lcore handler not executed by main core. */
+ CALL_MAIN, /**< lcore handler executed by main core. */
};
+/* These legacy definitions will be removed in future release */
+#define SKIP_MASTER RTE_DEPRECATED(SKIP_MASTER) SKIP_MAIN
+#define CALL_MASTER RTE_DEPRECATED(CALL_MASTER) CALL_MAIN
+
/**
* Launch a function on all lcores.
*
- * Check that each SLAVE lcore is in a WAIT state, then call
+ * Check that each WORKER lcore is in a WAIT state, then call
* rte_eal_remote_launch() for each lcore.
*
* @param f
* The function to be called.
* @param arg
* The argument for the function.
- * @param call_master
- * If call_master set to SKIP_MASTER, the MASTER lcore does not call
- * the function. If call_master is set to CALL_MASTER, the function
- * is also called on master before returning. In any case, the master
+ * @param call_main
+ * If call_main set to SKIP_MAIN, the MAIN lcore does not call
+ * the function. If call_main is set to CALL_MAIN, the function
+ * is also called on main before returning. In any case, the main
* lcore returns as soon as it finished its job and knows nothing
* about the completion of f on the other lcores.
* @return
@@ -95,49 +99,49 @@ enum rte_rmt_call_master_t {
* case, no message is sent to any of the lcores.
*/
int rte_eal_mp_remote_launch(lcore_function_t *f, void *arg,
- enum rte_rmt_call_master_t call_master);
+ enum rte_rmt_call_main_t call_main);
/**
- * Get the state of the lcore identified by slave_id.
+ * Get the state of the lcore identified by worker_id.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore.
* @return
* The state of the lcore.
*/
-enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned slave_id);
+enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned int worker_id);
/**
* Wait until an lcore finishes its job.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * If the slave lcore identified by the slave_id is in a FINISHED state,
+ * If the worker lcore identified by the worker_id is in a FINISHED state,
* switch to the WAIT state. If the lcore is in RUNNING state, wait until
* the lcore finishes its job and moves to the FINISHED state.
*
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore.
* @return
- * - 0: If the lcore identified by the slave_id is in a WAIT state.
+ * - 0: If the lcore identified by the worker_id is in a WAIT state.
* - The value that was returned by the previous remote launch
- * function call if the lcore identified by the slave_id was in a
+ * function call if the lcore identified by the worker_id was in a
* FINISHED or RUNNING state. In this case, it changes the state
* of the lcore to WAIT.
*/
-int rte_eal_wait_lcore(unsigned slave_id);
+int rte_eal_wait_lcore(unsigned worker_id);
/**
* Wait until all lcores finish their jobs.
*
- * To be executed on the MASTER lcore only. Issue an
+ * To be executed on the MAIN lcore only. Issue an
* rte_eal_wait_lcore() for every lcore. The return values are
* ignored.
*
* After a call to rte_eal_mp_wait_lcore(), the caller can assume
- * that all slave lcores are in a WAIT state.
+ * that all worker lcores are in a WAIT state.
*/
void rte_eal_mp_wait_lcore(void);
diff --git a/lib/librte_eal/include/rte_lcore.h b/lib/librte_eal/include/rte_lcore.h
index b8b64a625200..48b87e253afa 100644
--- a/lib/librte_eal/include/rte_lcore.h
+++ b/lib/librte_eal/include/rte_lcore.h
@@ -78,12 +78,24 @@ rte_lcore_id(void)
}
/**
- * Get the id of the master lcore
+ * Get the id of the main lcore
*
* @return
- * the id of the master lcore
+ * the id of the main lcore
*/
-unsigned int rte_get_master_lcore(void);
+unsigned int rte_get_main_lcore(void);
+
+/**
+ * Deprecated function the id of the main lcore
+ *
+ * @return
+ * the id of the main lcore
+ */
+__rte_deprecated
+static inline unsigned int rte_get_master_lcore(void)
+{
+ return rte_get_main_lcore();
+}
/**
* Return the number of execution units (lcores) on the system.
@@ -203,32 +215,35 @@ int rte_lcore_is_enabled(unsigned int lcore_id);
*
* @param i
* The current lcore (reference).
- * @param skip_master
- * If true, do not return the ID of the master lcore.
+ * @param skip_main
+ * If true, do not return the ID of the main lcore.
* @param wrap
* If true, go back to 0 when RTE_MAX_LCORE is reached; otherwise,
* return RTE_MAX_LCORE.
* @return
* The next lcore_id or RTE_MAX_LCORE if not found.
*/
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap);
+unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap);
/**
* Macro to browse all running lcores.
*/
#define RTE_LCORE_FOREACH(i) \
for (i = rte_get_next_lcore(-1, 0, 0); \
- i<RTE_MAX_LCORE; \
+ i < RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 0, 0))
/**
- * Macro to browse all running lcores except the master lcore.
+ * Macro to browse all running lcores except the main lcore.
*/
-#define RTE_LCORE_FOREACH_SLAVE(i) \
+#define RTE_LCORE_FOREACH_WORKER(i) \
for (i = rte_get_next_lcore(-1, 1, 0); \
- i<RTE_MAX_LCORE; \
+ i < RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 1, 0))
+#define RTE_LCORE_FOREACH_SLAVE(l) \
+ RTE_DEPRECATED(RTE_LCORE_FOREACH_SLAVE) RTE_LCORE_FOREACH_WORKER(l)
+
/**
* Callback prototype for initializing lcores.
*
diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
index 9cf0e2ec0137..1c9dd8db1e6a 100644
--- a/lib/librte_eal/linux/eal.c
+++ b/lib/librte_eal/linux/eal.c
@@ -883,10 +883,10 @@ eal_check_mem_on_local_socket(void)
int socket_id;
const struct rte_config *config = rte_eal_get_configuration();
- socket_id = rte_lcore_to_socket_id(config->master_lcore);
+ socket_id = rte_lcore_to_socket_id(config->main_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
- RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
+ RTE_LOG(WARNING, EAL, "WARNING: Main core has no memory on local socket!\n");
}
static int
@@ -1215,28 +1215,28 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
if (pthread_setaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
- &lcore_config[config->master_lcore].cpuset) != 0) {
+ &lcore_config[config->main_lcore].cpuset) != 0) {
rte_eal_init_alert("Cannot set affinity");
rte_errno = EINVAL;
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
- config->master_lcore, (uintptr_t)thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Main lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
+ config->main_lcore, (uintptr_t)thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_main2worker) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_worker2main) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -1249,7 +1249,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-worker-%d", i);
ret = rte_thread_setname(lcore_config[i].thread_id,
thread_name);
if (ret != 0)
@@ -1263,10 +1263,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
/* initialize services so vdevs register service during bus_probe. */
diff --git a/lib/librte_eal/linux/eal_memory.c b/lib/librte_eal/linux/eal_memory.c
index 89725291b0ce..3e47efe58212 100644
--- a/lib/librte_eal/linux/eal_memory.c
+++ b/lib/librte_eal/linux/eal_memory.c
@@ -1737,7 +1737,7 @@ memseg_primary_init_32(void)
/* the allocation logic is a little bit convoluted, but here's how it
* works, in a nutshell:
* - if user hasn't specified on which sockets to allocate memory via
- * --socket-mem, we allocate all of our memory on master core socket.
+ * --socket-mem, we allocate all of our memory on main core socket.
* - if user has specified sockets to allocate memory on, there may be
* some "unused" memory left (e.g. if user has specified --socket-mem
* such that not all memory adds up to 2 gigabytes), so add it to all
@@ -1751,7 +1751,7 @@ memseg_primary_init_32(void)
for (i = 0; i < rte_socket_count(); i++) {
int hp_sizes = (int) internal_conf->num_hugepage_sizes;
uint64_t max_socket_mem, cur_socket_mem;
- unsigned int master_lcore_socket;
+ unsigned int main_lcore_socket;
struct rte_config *cfg = rte_eal_get_configuration();
bool skip;
@@ -1767,10 +1767,10 @@ memseg_primary_init_32(void)
skip = active_sockets != 0 &&
internal_conf->socket_mem[socket_id] == 0;
/* ...or if we didn't specifically request memory on *any*
- * socket, and this is not master lcore
+ * socket, and this is not main lcore
*/
- master_lcore_socket = rte_lcore_to_socket_id(cfg->master_lcore);
- skip |= active_sockets == 0 && socket_id != master_lcore_socket;
+ main_lcore_socket = rte_lcore_to_socket_id(cfg->main_lcore);
+ skip |= active_sockets == 0 && socket_id != main_lcore_socket;
if (skip) {
RTE_LOG(DEBUG, EAL, "Will not preallocate memory on socket %u\n",
diff --git a/lib/librte_eal/linux/eal_thread.c b/lib/librte_eal/linux/eal_thread.c
index 068de2559555..83c2034b93d5 100644
--- a/lib/librte_eal/linux/eal_thread.c
+++ b/lib/librte_eal/linux/eal_thread.c
@@ -26,35 +26,35 @@
#include "eal_thread.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
+rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned int worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
int rc = -EBUSY;
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
goto finish;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
+ n = write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = read(s2m, &c, 1);
+ n = read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -62,7 +62,7 @@ rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
rc = 0;
finish:
- rte_eal_trace_thread_remote_launch(f, arg, slave_id, rc);
+ rte_eal_trace_thread_remote_launch(f, arg, worker_id, rc);
return rc;
}
@@ -74,21 +74,21 @@ eal_thread_loop(__rte_unused void *arg)
int n, ret;
unsigned lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -104,7 +104,7 @@ eal_thread_loop(__rte_unused void *arg)
/* wait command */
do {
- n = read(m2s, &c, 1);
+ n = read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -115,7 +115,7 @@ eal_thread_loop(__rte_unused void *arg)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(s2m, &c, 1);
+ n = write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index a93dea9fe616..33ee2748ede0 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -74,7 +74,7 @@ DPDK_21 {
rte_free;
rte_get_hpet_cycles;
rte_get_hpet_hz;
- rte_get_master_lcore;
+ rte_get_main_lcore;
rte_get_next_lcore;
rte_get_tsc_hz;
rte_hexdump;
diff --git a/lib/librte_eal/windows/eal.c b/lib/librte_eal/windows/eal.c
index bc48f27ab39a..cbca20956210 100644
--- a/lib/librte_eal/windows/eal.c
+++ b/lib/librte_eal/windows/eal.c
@@ -350,8 +350,8 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
bscan = rte_bus_scan();
if (bscan < 0) {
@@ -360,16 +360,16 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (_pipe(lcore_config[i].pipe_master2slave,
+ if (_pipe(lcore_config[i].pipe_main2worker,
sizeof(char), _O_BINARY) < 0)
rte_panic("Cannot create pipe\n");
- if (_pipe(lcore_config[i].pipe_slave2master,
+ if (_pipe(lcore_config[i].pipe_worker2main,
sizeof(char), _O_BINARY) < 0)
rte_panic("Cannot create pipe\n");
@@ -394,10 +394,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
return fctret;
}
diff --git a/lib/librte_eal/windows/eal_thread.c b/lib/librte_eal/windows/eal_thread.c
index 20889b6196c9..908e726d16cc 100644
--- a/lib/librte_eal/windows/eal_thread.c
+++ b/lib/librte_eal/windows/eal_thread.c
@@ -17,34 +17,34 @@
#include "eal_windows.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned int slave_id)
+rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned int worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
return -EBUSY;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = _write(m2s, &c, 1);
+ n = _write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = _read(s2m, &c, 1);
+ n = _read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -61,21 +61,21 @@ eal_thread_loop(void *arg __rte_unused)
int n, ret;
unsigned int lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -88,7 +88,7 @@ eal_thread_loop(void *arg __rte_unused)
/* wait command */
do {
- n = _read(m2s, &c, 1);
+ n = _read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -99,7 +99,7 @@ eal_thread_loop(void *arg __rte_unused)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = _write(s2m, &c, 1);
+ n = _write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
--
2.27.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 19:48 0% ` Michel Machado
@ 2020-10-14 13:10 0% ` Medvedkin, Vladimir
2020-10-14 23:57 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Medvedkin, Vladimir @ 2020-10-14 13:10 UTC (permalink / raw)
To: Michel Machado, Kevin Traynor, Ruifeng Wang, Bruce Richardson,
Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, Honnappa Nagarahalli, nd
On 13/10/2020 20:48, Michel Machado wrote:
> On 10/13/20 3:06 PM, Medvedkin, Vladimir wrote:
>>
>>
>> On 13/10/2020 18:46, Michel Machado wrote:
>>> On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
>>>> Hi Michel,
>>>>
>>>> Could you please describe a condition when LPM gets inconsistent? As
>>>> I can see if there is no free tbl8 it will return -ENOSPC.
>>>
>>> Consider this simple example, we need to add the following two
>>> prefixes with different next hops: 10.99.0.0/16, 18.99.99.128/25. If
>>> the LPM table is out of tbl8s, the second prefix is not added and
>>> Gatekeeper will make decisions in violation of the policy. The data
>>> structure of the LPM table is consistent, but its content
>>> inconsistent with the policy.
>>
>> Aha, thanks. So do I understand correctly that you need to add a set
>> of routes atomically (either the entire set is installed or nothing)?
>
> Yes.
>
>> If so, then I would suggest having 2 lpm and switching them atomically
>> after a successful addition. As for now, even if you have enough
>> tbl8's, routes are installed non atomically, i.e. there will be a time
>> gap between adding two routes, so in this time interval the table will
>> be inconsistent with the policy.
>> Also, if new lpm algorithms are added to the DPDK, they won't have
>> such a thing as tbl8.
>
> Our code already deals with synchronization.
OK, so my suggestion here would be to add new routes to the shadow copy
of the lpm, and if it returns -ENOSPC, than create a new LPM with double
amount of tbl8's and add all the routes to it. Then switch the
active-shadow LPM pointers. In this case you'll always add a bulk of
routes atomically.
>
>>> We minimize the need of replacing a LPM table by allocating LPM
>>> tables with the double of what we need (see example here
>>> https://github.com/AltraMayor/gatekeeper/blob/95d1d6e8201861a0d0c698bfd06ad606674f1e07/lua/examples/policy.lua#L172-L183),
>>> but the code must be ready for unexpected needs that may arise in
>>> production.
>>>
>>
>> Usually, the table is initialized with a large enough number of
>> entries, enough to add a possible number of routes. One tbl8 group
>> takes up 1Kb of memory which is nothing comparing to the size of tbl24
>> which is 64Mb.
>
> When the prefixes come from BGP, initializing a large enough table
> is fine. But when prefixes come from threat intelligence, the number of
> prefixes can vary wildly and the number of prefixes above 24 bits are
> way more common.
>
>> P.S. consider using rte_fib library, it has a number of advantages
>> over LPM. You can replace the loop in __lookup_fib_bulk() with a bulk
>> lookup call and this will probably increase the speed.
>
> I'm not aware of the rte_fib library. The only documentation that I
> found on Google was https://doc.dpdk.org/api/rte__fib_8h.html and it
> just says "FIB (Forwarding information base) implementation for IPv4
> Longest Prefix Match".
That's true, I'm going to add programmer's guide soon.
Although the fib API is very similar to existing LPM.
>
>>>>
>>>> On 13/10/2020 15:58, Michel Machado wrote:
>>>>> Hi Kevin,
>>>>>
>>>>> We do need fields max_rules and number_tbl8s of struct rte_lpm,
>>>>> so the removal would force us to have another patch to our local
>>>>> copy of DPDK. We'd rather avoid this new local patch because we
>>>>> wish to eventually be in sync with the stock DPDK.
>>>>>
>>>>> Those fields are needed in Gatekeeper because we found a
>>>>> condition in an ongoing deployment in which the entries of some LPM
>>>>> tables may suddenly change a lot to reflect policy changes. To
>>>>> avoid getting into a state in which the LPM table is inconsistent
>>>>> because it cannot fit all the new entries, we compute the needed
>>>>> parameters to support the new entries, and compare with the current
>>>>> parameters. If the current table doesn't fit everything, we have to
>>>>> replace it with a new LPM table.
>>>>>
>>>>> If there were a way to obtain the struct rte_lpm_config of a
>>>>> given LPM table, it would cleanly address our need. We have the
>>>>> same need in IPv6 and have a local patch to work around it (see
>>>>> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
>>>>> Thus, an IPv4 and IPv6 solution would be best.
>>>>>
>>>>> PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to
>>>>> this disscussion.
>>>>>
>>>>> [ ]'s
>>>>> Michel Machado
>>>>>
>>>>> On 10/13/20 9:53 AM, Kevin Traynor wrote:
>>>>>> Hi Gatekeeper maintainers (I think),
>>>>>>
>>>>>> fyi - there is a proposal to remove some members of a struct in
>>>>>> DPDK LPM
>>>>>> API that Gatekeeper is using [1]. It would be only from DPDK 20.11
>>>>>> but
>>>>>> as it's an LTS I guess it would probably hit Debian in a few months.
>>>>>>
>>>>>> The full thread is here:
>>>>>> http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
>>>>>>
>>>>>>
>>>>>> Maybe you can take a look and tell us if they are needed in
>>>>>> Gatekeeper
>>>>>> or you can workaround it?
>>>>>>
>>>>>> thanks,
>>>>>> Kevin.
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
>>>>>>
>>>>>>
>>>>>> On 09/10/2020 07:54, Ruifeng Wang wrote:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Kevin Traynor <ktraynor@redhat.com>
>>>>>>>> Sent: Wednesday, September 30, 2020 4:46 PM
>>>>>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>>>>>>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>>>>>>>> <bruce.richardson@intel.com>
>>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>>>>>>>
>>>>>>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>>>>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>>>>>>>> <Ruifeng.Wang@arm.com>
>>>>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>>>>>>>
>>>>>>>>>> Hi Ruifeng,
>>>>>>>>>>
>>>>>>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>>>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no
>>>>>>>>>>>> need to
>>>>>>>>>>>> be exposed to the user.
>>>>>>>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>>>>>>>> maintainability.
>>>>>>>>>>>>
>>>>>>>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>>>>>>>> +++++++++++++++++++++++---------------
>>>>>>>>>> -
>>>>>>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>> <snip>
>>>>>>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>>> b/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>>> index 03da2d37e..112d96f37 100644
>>>>>>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>>>>>>>
>>>>>>>>>>>> /** @internal LPM structure. */
>>>>>>>>>>>> struct rte_lpm {
>>>>>>>>>>>> - /* LPM metadata. */
>>>>>>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the
>>>>>>>>>>>> lpm. */
>>>>>>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>>>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH];
>>>>>>>>>>>> /**<
>>>>>>>>>> Rule info table. */
>>>>>>>>>>>> -
>>>>>>>>>>>> /* LPM Tables. */
>>>>>>>>>>>> struct rte_lpm_tbl_entry
>>>>>>>>>>>> tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>>>>>>>
>>>>>>>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>>>>>>>> different, and that return value could be used by
>>>>>>>>>>> rte_lpm_lookup()
>>>>>>>>>>> which as a static inline function will be in the binary and
>>>>>>>>>>> using
>>>>>>>>>>> the old structure offsets.]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>>>>>>>> without prior notice.
>>>>>>>>>>
>>>>>>>>> So if the change wants to happen in 20.11, a deprecation notice
>>>>>>>>> should
>>>>>>>>> have been added in 20.08.
>>>>>>>>> I should have added a deprecation notice. This change will have
>>>>>>>>> to wait for
>>>>>>>> next ABI update window.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Do you plan to extend? or is this just speculative?
>>>>>>> It is speculative.
>>>>>>>
>>>>>>>>
>>>>>>>> A quick scan and there seems to be several projects using some
>>>>>>>> of these
>>>>>>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>>>>>>>> gatekeeper. I didn't look at the details to see if they are
>>>>>>>> really needed.
>>>>>>>>
>>>>>>>> Not sure how much notice they'd need or if they update DPDK
>>>>>>>> much, but I
>>>>>>>> think it's worth having a closer look as to how they use lpm and
>>>>>>>> what the
>>>>>>>> impact to them is.
>>>>>>> Checked the projects listed above. BESS, NFF-Go and DPVS don't
>>>>>>> access the members to be hided.
>>>>>>> They will not be impacted by this patch.
>>>>>>> But Gatekeeper accesses the rte_lpm internal members that to be
>>>>>>> hided. Its compilation will be broken with this patch.
>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>> Ruifeng
>>>>>>>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>>>>>>>> --
>>>>>>>>>>>> 2.17.1
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>> Vladimir
>>>>>>>
>>>>>>
>>>>
>>
--
Regards,
Vladimir
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 4/4] doc: test-meson-builds.sh doc updates
2020-10-14 10:41 10% ` [dpdk-dev] [PATCH v7 " Conor Walsh
` (2 preceding siblings ...)
2020-10-14 10:41 15% ` [dpdk-dev] [PATCH v7 3/4] devtools: change not found to warning check-abi.sh Conor Walsh
@ 2020-10-14 10:41 18% ` Conor Walsh
[not found] ` <7206c209-ed4a-2aeb-12d8-ee162ef92596@ashroe.eu>
4 siblings, 0 replies; 200+ results
From: Conor Walsh @ 2020-10-14 10:41 UTC (permalink / raw)
To: mdr, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev, Conor Walsh
Updates to the Checking Compilation and Checking ABI compatibility
sections of the patches part of the contribution guide
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/patches.rst | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 9ff60944c..e11d63bb0 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -470,10 +470,9 @@ The script internally checks for dependencies, then builds for several
combinations of compilation configuration.
By default, each build will be put in a subfolder of the current working directory.
However, if it is preferred to place the builds in a different location,
-the environment variable ``DPDK_BUILD_TEST_DIR`` can be set to that desired location.
-For example, setting ``DPDK_BUILD_TEST_DIR=__builds`` will put all builds
-in a single subfolder called "__builds" created in the current directory.
-Setting ``DPDK_BUILD_TEST_DIR`` to an absolute directory path e.g. ``/tmp`` is also supported.
+the environment variable ``DPDK_BUILD_TEST_DIR`` or the command line argument ``-b``
+can be set to that desired location.
+Environmental variables can also be specified in ``.config/dpdk/devel.config``.
.. _integrated_abi_check:
@@ -483,14 +482,17 @@ Checking ABI compatibility
By default, ABI compatibility checks are disabled.
-To enable them, a reference version must be selected via the environment
-variable ``DPDK_ABI_REF_VERSION``.
-
-The ``devtools/test-build.sh`` and ``devtools/test-meson-builds.sh`` scripts
-then build this reference version in a temporary directory and store the
-results in a subfolder of the current working directory.
-The environment variable ``DPDK_ABI_REF_DIR`` can be set so that the results go
-to a different location.
+To enable ABI checks the required reference version must be set using either the
+environment variable ``DPDK_ABI_REF_VERSION`` or the command line argument ``-a``.
+The tag ``latest`` is supported, which will select the latest quarterly release.
+e.g. ``./devtools/test-meson-builds.sh -a latest``.
+
+The ``devtools/test-meson-builds.sh`` script will then either build this reference version
+or download a cached version when available in a temporary directory and store the results
+in a subfolder of the current working directory.
+The environment variable ``DPDK_ABI_REF_DIR`` or the argument ``-d`` can be set so that
+the results go to a different location.
+Environmental variables can also be specified in ``.config/dpdk/devel.config``.
Sending Patches
--
2.25.1
^ permalink raw reply [relevance 18%]
* [dpdk-dev] [PATCH v7 3/4] devtools: change not found to warning check-abi.sh
2020-10-14 10:41 10% ` [dpdk-dev] [PATCH v7 " Conor Walsh
2020-10-14 10:41 21% ` [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives Conor Walsh
2020-10-14 10:41 26% ` [dpdk-dev] [PATCH v7 2/4] devtools: abi and UX changes for test-meson-builds.sh Conor Walsh
@ 2020-10-14 10:41 15% ` Conor Walsh
2020-10-14 10:41 18% ` [dpdk-dev] [PATCH v7 4/4] doc: test-meson-builds.sh doc updates Conor Walsh
[not found] ` <7206c209-ed4a-2aeb-12d8-ee162ef92596@ashroe.eu>
4 siblings, 0 replies; 200+ results
From: Conor Walsh @ 2020-10-14 10:41 UTC (permalink / raw)
To: mdr, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev, Conor Walsh
Change dump file not found from an error to a warning to make check-abi.sh
compatible with the changes to test-meson-builds.sh needed to use
prebuilt references.
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
---
devtools/check-abi.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index ab6748cfb..60d88777e 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -46,8 +46,7 @@ for dump in $(find $refdir -name "*.dump"); do
fi
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
- echo "Error: can't find $name in $newdir"
- error=1
+ echo "WARNING: can't find $name in $newdir, are you building with all dependencies?"
continue
fi
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
--
2.25.1
^ permalink raw reply [relevance 15%]
* [dpdk-dev] [PATCH v7 2/4] devtools: abi and UX changes for test-meson-builds.sh
2020-10-14 10:41 10% ` [dpdk-dev] [PATCH v7 " Conor Walsh
2020-10-14 10:41 21% ` [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives Conor Walsh
@ 2020-10-14 10:41 26% ` Conor Walsh
2020-10-15 10:16 4% ` Kinsella, Ray
2020-10-14 10:41 15% ` [dpdk-dev] [PATCH v7 3/4] devtools: change not found to warning check-abi.sh Conor Walsh
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Conor Walsh @ 2020-10-14 10:41 UTC (permalink / raw)
To: mdr, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev, Conor Walsh
The core reason for this patch is to reduce the amount of time needed to
run abi checks. The number of abi checks being run has been reduced to
only 2 (1 x86_64 and 1 arm). The script can now also take adavtage of
prebuilt abi references.
Invoke using "./test-meson-builds.sh [-b <build directory>]
[-a <dpdk tag or latest for abi check>] [-u <uri for abi references>]
[-d <directory for abi references>]"
- <build directory>: directory to store builds (relative or absolute)
- <dpdk tag or latest for abi check>: dpdk tag e.g. "v20.11" or "latest"
- <uri for abi references>: http location or directory to get prebuilt
abi references from
- <directory for abi references>: directory to store abi references
(relative or absolute)
e.g. "./test-meson-builds.sh -a latest"
If no flags are specified test-meson-builds.sh will run the standard
meson tests with default options unless environmental variables are
specified.
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
---
devtools/test-meson-builds.sh | 171 +++++++++++++++++++++++++++-------
1 file changed, 139 insertions(+), 32 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a87de635a..6b959eb63 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -1,12 +1,74 @@
#! /bin/sh -e
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2018 Intel Corporation
+# Copyright(c) 2018-2020 Intel Corporation
# Run meson to auto-configure the various builds.
# * all builds get put in a directory whose name starts with "build-"
# * if a build-directory already exists we assume it was properly configured
# Run ninja after configuration is done.
+# Get arguments
+usage()
+{
+ echo "Usage: $0
+ [-b <build directory>]
+ [-a <dpdk tag or latest for abi check>]
+ [-u <uri for abi references>]
+ [-d <directory for abi references>]" 1>&2; exit 1;
+}
+
+# Placeholder default uri
+DPDK_ABI_DEFAULT_URI="http://abi-ref.dpdk.org"
+
+while getopts "a:u:d:b:h" arg; do
+ case $arg in
+ a)
+ if [ -n "$DPDK_ABI_REF_VERSION" ]; then
+ echo "DPDK_ABI_REF_VERSION and -a cannot both be set"
+ exit 1
+ fi
+ DPDK_ABI_REF_VERSION=${OPTARG} ;;
+ u)
+ if [ -n "$DPDK_ABI_TAR_URI" ]; then
+ echo "DPDK_ABI_TAR_URI and -u cannot both be set"
+ exit 1
+ fi
+ DPDK_ABI_TAR_URI=${OPTARG} ;;
+ d)
+ if [ -n "$DPDK_ABI_REF_DIR" ]; then
+ echo "DPDK_ABI_REF_DIR and -d cannot both be set"
+ exit 1
+ fi
+ DPDK_ABI_REF_DIR=${OPTARG} ;;
+ b)
+ if [ -n "$DPDK_BUILD_TEST_DIR" ]; then
+ echo "DPDK_BUILD_TEST_DIR and -a cannot both be set"
+ exit 1
+ fi
+ DPDK_BUILD_TEST_DIR=${OPTARG} ;;
+ h)
+ usage ;;
+ *)
+ usage ;;
+ esac
+done
+
+if [ -n "$DPDK_ABI_REF_VERSION" ] ; then
+ if [ "$DPDK_ABI_REF_VERSION" = "latest" ] ; then
+ DPDK_ABI_REF_VERSION=$(git ls-remote --tags http://dpdk.org/git/dpdk |
+ sed "s/.*\///" | grep -v "r\|{}" |
+ grep '^[^.]*.[^.]*$' | tail -n 1)
+ elif [ -z "$(git ls-remote http://dpdk.org/git/dpdk refs/tags/$DPDK_ABI_REF_VERSION)" ] ; then
+ echo "$DPDK_ABI_REF_VERSION is not a valid DPDK tag"
+ exit 1
+ fi
+fi
+if [ -z $DPDK_ABI_TAR_URI ] ; then
+ DPDK_ABI_TAR_URI=$DPDK_ABI_DEFAULT_URI
+fi
+# allow the generation script to override value with env var
+abi_checks_done=${DPDK_ABI_GEN_REF:-0}
+
# set pipefail option if possible
PIPEFAIL=""
set -o | grep -q pipefail && set -o pipefail && PIPEFAIL=1
@@ -16,7 +78,11 @@ srcdir=$(dirname $(readlink -f $0))/..
MESON=${MESON:-meson}
use_shared="--default-library=shared"
-builds_dir=${DPDK_BUILD_TEST_DIR:-.}
+builds_dir=${DPDK_BUILD_TEST_DIR:-$srcdir/builds}
+# ensure path is absolute meson returns error when some paths are relative
+if echo "$builds_dir" | grep -qv '^/'; then
+ builds_dir=$srcdir/$builds_dir
+fi
if command -v gmake >/dev/null 2>&1 ; then
MAKE=gmake
@@ -123,39 +189,49 @@ install_target () # <builddir> <installdir>
fi
}
-build () # <directory> <target compiler | cross file> <meson options>
+abi_gen_check () # no options
{
- targetdir=$1
- shift
- crossfile=
- [ -r $1 ] && crossfile=$1 || targetcc=$1
- shift
- # skip build if compiler not available
- command -v ${CC##* } >/dev/null 2>&1 || return 0
- if [ -n "$crossfile" ] ; then
- cross="--cross-file $crossfile"
- targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
- $crossfile | tr -d "'" | tr -d '"')
- else
- cross=
+ abirefdir=${DPDK_ABI_REF_DIR:-$builds_dir/__reference}/$DPDK_ABI_REF_VERSION
+ mkdir -p $abirefdir
+ # ensure path is absolute meson returns error when some are relative
+ if echo "$abirefdir" | grep -qv '^/'; then
+ abirefdir=$srcdir/$abirefdir
fi
- load_env $targetcc || return 0
- config $srcdir $builds_dir/$targetdir $cross --werror $*
- compile $builds_dir/$targetdir
- if [ -n "$DPDK_ABI_REF_VERSION" ]; then
- abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
- if [ ! -d $abirefdir/$targetdir ]; then
+ if [ ! -d $abirefdir/$targetdir ]; then
+
+ # try to get abi reference
+ if echo "$DPDK_ABI_TAR_URI" | grep -q '^http'; then
+ if [ $abi_checks_done -gt -1 ]; then
+ if curl --head --fail --silent \
+ "$DPDK_ABI_TAR_URI/$DPDK_ABI_REF_VERSION/$targetdir.tar.gz" \
+ >/dev/null; then
+ curl -o $abirefdir/$targetdir.tar.gz \
+ $DPDK_ABI_TAR_URI/$DPDK_ABI_REF_VERSION/$targetdir.tar.gz
+ fi
+ fi
+ elif [ $abi_checks_done -gt -1 ]; then
+ if [ -f "$DPDK_ABI_TAR_URI/$targetdir.tar.gz" ]; then
+ cp $DPDK_ABI_TAR_URI/$targetdir.tar.gz \
+ $abirefdir/
+ fi
+ fi
+ if [ -f "$abirefdir/$targetdir.tar.gz" ]; then
+ tar -xf $abirefdir/$targetdir.tar.gz \
+ -C $abirefdir >/dev/null
+ rm -rf $abirefdir/$targetdir.tar.gz
+ # if no reference can be found then generate one
+ else
# clone current sources
if [ ! -d $abirefdir/src ]; then
git clone --local --no-hardlinks \
- --single-branch \
- -b $DPDK_ABI_REF_VERSION \
- $srcdir $abirefdir/src
+ --single-branch \
+ -b $DPDK_ABI_REF_VERSION \
+ $srcdir $abirefdir/src
fi
rm -rf $abirefdir/build
config $abirefdir/src $abirefdir/build $cross \
- -Dexamples= $*
+ -Dexamples= $*
compile $abirefdir/build
install_target $abirefdir/build $abirefdir/$targetdir
$srcdir/devtools/gen-abi.sh $abirefdir/$targetdir
@@ -164,17 +240,46 @@ build () # <directory> <target compiler | cross file> <meson options>
find $abirefdir/$targetdir/usr/local -name '*.a' -delete
rm -rf $abirefdir/$targetdir/usr/local/bin
rm -rf $abirefdir/$targetdir/usr/local/share
+ rm -rf $abirefdir/$targetdir/usr/local/lib
fi
+ fi
- install_target $builds_dir/$targetdir \
- $(readlink -f $builds_dir/$targetdir/install)
- $srcdir/devtools/gen-abi.sh \
- $(readlink -f $builds_dir/$targetdir/install)
+ install_target $builds_dir/$targetdir \
+ $(readlink -f $builds_dir/$targetdir/install)
+ $srcdir/devtools/gen-abi.sh \
+ $(readlink -f $builds_dir/$targetdir/install)
+ # check abi if not generating references
+ if [ -z $DPDK_ABI_GEN_REF ] ; then
$srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
$(readlink -f $builds_dir/$targetdir/install)
fi
}
+build () # <directory> <target compiler | cross file> <meson options>
+{
+ targetdir=$1
+ shift
+ crossfile=
+ [ -r $1 ] && crossfile=$1 || targetcc=$1
+ shift
+ # skip build if compiler not available
+ command -v ${CC##* } >/dev/null 2>&1 || return 0
+ if [ -n "$crossfile" ] ; then
+ cross="--cross-file $crossfile"
+ targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
+ $crossfile | tr -d "'" | tr -d '"')
+ else
+ cross=
+ fi
+ load_env $targetcc || return 0
+ config $srcdir $builds_dir/$targetdir $cross --werror $*
+ compile $builds_dir/$targetdir
+ if [ -n "$DPDK_ABI_REF_VERSION" ] && [ $abi_checks_done -lt 1 ] ; then
+ abi_gen_check
+ abi_checks_done=$((abi_checks_done+1))
+ fi
+}
+
if [ "$1" = "-vv" ] ; then
TEST_MESON_BUILD_VERY_VERBOSE=1
elif [ "$1" = "-v" ] ; then
@@ -189,7 +294,7 @@ fi
# shared and static linked builds with gcc and clang
for c in gcc clang ; do
command -v $c >/dev/null 2>&1 || continue
- for s in static shared ; do
+ for s in shared static ; do
export CC="$CCACHE $c"
build build-$c-$s $c --default-library=$s
unset CC
@@ -211,6 +316,8 @@ build build-x86-mingw $srcdir/config/x86/cross-mingw -Dexamples=helloworld
# generic armv8a with clang as host compiler
f=$srcdir/config/arm/arm64_armv8_linux_gcc
+# run abi checks with 1 arm build
+abi_checks_done=$((abi_checks_done-1))
export CC="clang"
build build-arm64-host-clang $f $use_shared
unset CC
@@ -231,7 +338,7 @@ done
build_path=$(readlink -f $builds_dir/build-x86-default)
export DESTDIR=$build_path/install
# No need to reinstall if ABI checks are enabled
-if [ -z "$DPDK_ABI_REF_VERSION" ]; then
+if [ -z "$DPDK_ABI_REF_VERSION" ] ; then
install_target $build_path $DESTDIR
fi
--
2.25.1
^ permalink raw reply [relevance 26%]
* [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives
2020-10-14 10:41 10% ` [dpdk-dev] [PATCH v7 " Conor Walsh
@ 2020-10-14 10:41 21% ` Conor Walsh
2020-10-15 10:15 4% ` Kinsella, Ray
2020-10-14 10:41 26% ` [dpdk-dev] [PATCH v7 2/4] devtools: abi and UX changes for test-meson-builds.sh Conor Walsh
` (3 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Conor Walsh @ 2020-10-14 10:41 UTC (permalink / raw)
To: mdr, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev, Conor Walsh
This patch adds a script that generates compressed archives
containing .dump files which can be used to perform abi
breakage checking in test-meson-build.sh.
Invoke using "./gen-abi-tarballs.sh [-v <dpdk tag>]"
- <dpdk tag>: dpdk tag e.g. "v20.11" or "latest"
e.g. "./gen-abi-tarballs.sh -v latest"
If no tag is specified, the script will default to "latest"
Using these parameters the script will produce several *.tar.gz
archives containing .dump files required to do abi breakage checking
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
---
devtools/gen-abi-tarballs.sh | 48 ++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100755 devtools/gen-abi-tarballs.sh
diff --git a/devtools/gen-abi-tarballs.sh b/devtools/gen-abi-tarballs.sh
new file mode 100755
index 000000000..bcc1beac5
--- /dev/null
+++ b/devtools/gen-abi-tarballs.sh
@@ -0,0 +1,48 @@
+#! /bin/sh -e
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2020 Intel Corporation
+
+# Generate the required prebuilt ABI references for test-meson-build.sh
+
+# Get arguments
+usage() { echo "Usage: $0 [-v <dpdk tag or latest>]" 1>&2; exit 1; }
+abi_tag=
+while getopts "v:h" arg; do
+ case $arg in
+ v)
+ if [ -n "$DPDK_ABI_REF_VERSION" ]; then
+ echo "DPDK_ABI_REF_VERSION and -v cannot both be set"
+ exit 1
+ fi
+ DPDK_ABI_REF_VERSION=${OPTARG} ;;
+ h)
+ usage ;;
+ *)
+ usage ;;
+ esac
+done
+
+if [ -z $DPDK_ABI_REF_VERSION ] ; then
+ DPDK_ABI_REF_VERSION="latest"
+fi
+
+srcdir=$(dirname $(readlink -f $0))/..
+
+DPDK_ABI_GEN_REF=-20
+DPDK_ABI_REF_DIR=$srcdir/__abitarballs
+
+. $srcdir/devtools/test-meson-builds.sh
+
+abirefdir=$DPDK_ABI_REF_DIR/$DPDK_ABI_REF_VERSION
+
+rm -rf $abirefdir/build-*.tar.gz
+cd $abirefdir
+for f in build-* ; do
+ tar -czf $f.tar.gz $f
+done
+cp *.tar.gz ../
+rm -rf *
+mv ../*.tar.gz .
+rm -rf build-x86-default.tar.gz
+
+echo "The references for $DPDK_ABI_REF_VERSION are now available in $abirefdir"
--
2.25.1
^ permalink raw reply [relevance 21%]
* [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks
` (4 preceding siblings ...)
2020-10-14 9:37 4% ` [dpdk-dev] [PATCH v6 0/4] devtools: abi breakage checks Kinsella, Ray
@ 2020-10-14 10:41 10% ` Conor Walsh
2020-10-14 10:41 21% ` [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives Conor Walsh
` (4 more replies)
5 siblings, 5 replies; 200+ results
From: Conor Walsh @ 2020-10-14 10:41 UTC (permalink / raw)
To: mdr, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev, Conor Walsh
This patchset introduces changes to test-meson-builds.sh, check-abi.sh and
adds a new script gen-abi-tarballs.sh. The changes to test-meson-builds.sh
include UX improvements such as adding command line arguments and allowing
the use of relative paths. Reduced the number of abi checks to just two,
one for both x86_64 and ARM, the references for these tests can now be
prebuilt and downloaded by test-meson-builds.sh, these changes will allow
the tests to run much faster. check-abi.sh is updated to use the prebuilt
references. gen-abi-tarballs.sh is a new script to generate the prebuilt
abi references used by test-meson-builds.sh, these compressed archives can
be retrieved from either a local directory or a remote http location.
---
v7: Changes resulting from list feedback
v6: Corrected a mistake in the doc patch
v5:
- Patchset has been completely reworked following feedback
- Patchset is now part of test-meson-builds.sh not the meson build
system
v4:
- Reworked both Python scripts to use more native Python functions
and modules.
- Python scripts are now in line with how other Python scripts in
DPDK are structured.
v3:
- Fix for bug which now allows meson < 0.48.0 to be used
- Various coding style changes throughout
- Minor bug fixes to the various meson.build files
v2: Spelling mistake, corrected spelling of environmental
Conor Walsh (4):
devtools: add generation of compressed abi dump archives
devtools: abi and UX changes for test-meson-builds.sh
devtools: change dump file not found to warning in check-abi.sh
doc: test-meson-builds.sh doc updates
devtools/check-abi.sh | 3 +-
devtools/gen-abi-tarballs.sh | 48 ++++++++
devtools/test-meson-builds.sh | 171 ++++++++++++++++++++++------
doc/guides/contributing/patches.rst | 26 +++--
4 files changed, 202 insertions(+), 46 deletions(-)
create mode 100755 devtools/gen-abi-tarballs.sh
--
2.25.1
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [PATCH v6 0/4] devtools: abi breakage checks
2020-10-14 9:37 4% ` [dpdk-dev] [PATCH v6 0/4] devtools: abi breakage checks Kinsella, Ray
@ 2020-10-14 10:33 4% ` Walsh, Conor
0 siblings, 0 replies; 200+ results
From: Walsh, Conor @ 2020-10-14 10:33 UTC (permalink / raw)
To: Kinsella, Ray, nhorman, Richardson, Bruce, thomas, david.marchand; +Cc: dev
Thanks for your feedback Ray,
V7 with your suggested changes for the patchset is on its way.
/Conor
> -----Original Message-----
> From: Kinsella, Ray <mdr@ashroe.eu>
> Sent: Wednesday 14 October 2020 10:37
> To: Walsh, Conor <conor.walsh@intel.com>; nhorman@tuxdriver.com;
> Richardson, Bruce <bruce.richardson@intel.com>; thomas@monjalon.net;
> david.marchand@redhat.com
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v6 0/4] devtools: abi breakage checks
>
>
>
> On 12/10/2020 14:03, Conor Walsh wrote:
> > This patchset will help developers discover abi breakages more easily
> > before upstreaming their code. Currently checking that the DPDK ABI
> > has not changed before up-streaming code is not intuitive and the
> > process is time consuming. Currently contributors must use the
> > test-meson-builds.sh tool, alongside some environmental variables to
> > test their changes. Contributors in many cases are either unaware or
> > unable to do this themselves, leading to a potentially serious situation
> > where they are unknowingly up-streaming code that breaks the ABI. These
> > breakages are caught by Travis, but it would be more efficient if they
> > were caught locally before up-streaming.
>
> I would remove everything in the git log text before this line...
>
> > This patchset introduces changes
> > to test-meson-builds.sh, check-abi.sh and adds a new script
> > gen-abi-tarballs.sh. The changes to test-meson-builds.sh include UX
>
> UX changes = improvements
>
> > changes such as adding command line arguments and allowing the use of
> > relative paths. Reduced the number of abi checks to just two, one for both
> > x86_64 and ARM, the references for these tests can now be prebuilt and
> > downloaded by test-meson-builds.sh, these changes will allow the tests to
> > run much faster. check-abi.sh is updated to use the prebuilt references.
> > gen-abi-tarballs.sh is a new script to generate the prebuilt abi
> > references used by test-meson-builds.sh, these compressed archives can
> be
> > retrieved from either a local directory or a remote http location.
> >
> > ---
> > v6: Corrected a mistake in the doc patch
> >
> > v5:
> > - Patchset has been completely reworked following feedback
> > - Patchset is now part of test-meson-builds.sh not the meson build system
> >
> > v4:
> > - Reworked both Python scripts to use more native Python functions
> > and modules.
> > - Python scripts are now in line with how other Python scripts in
> > DPDK are structured.
> >
> > v3:
> > - Fix for bug which now allows meson < 0.48.0 to be used
> > - Various coding style changes throughout
> > - Minor bug fixes to the various meson.build files
> >
> > v2: Spelling mistake, corrected spelling of environmental
> >
> > Conor Walsh (4):
> > devtools: add generation of compressed abi dump archives
> > devtools: abi and UX changes for test-meson-builds.sh
> > devtools: change dump file not found to warning in check-abi.sh
> > doc: test-meson-builds.sh doc updates
> >
> > devtools/check-abi.sh | 3 +-
> > devtools/gen-abi-tarballs.sh | 48 ++++++++
> > devtools/test-meson-builds.sh | 170 ++++++++++++++++++++++------
> > doc/guides/contributing/patches.rst | 26 +++--
> > 4 files changed, 201 insertions(+), 46 deletions(-)
> > create mode 100755 devtools/gen-abi-tarballs.sh
> >
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 4/4] doc: test-meson-builds.sh doc updates
@ 2020-10-14 9:46 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-14 9:46 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 12/10/2020 14:03, Conor Walsh wrote:
> Updates to the Checking Compilation and Checking ABI compatibility
> sections of the patches part of the contribution guide
>
> Signed-off-by: Conor Walsh <conor.walsh@intel.com>
>
> ---
> doc/guides/contributing/patches.rst | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index 9ff60944c..e11d63bb0 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -470,10 +470,9 @@ The script internally checks for dependencies, then builds for several
> combinations of compilation configuration.
> By default, each build will be put in a subfolder of the current working directory.
> However, if it is preferred to place the builds in a different location,
> -the environment variable ``DPDK_BUILD_TEST_DIR`` can be set to that desired location.
> -For example, setting ``DPDK_BUILD_TEST_DIR=__builds`` will put all builds
> -in a single subfolder called "__builds" created in the current directory.
> -Setting ``DPDK_BUILD_TEST_DIR`` to an absolute directory path e.g. ``/tmp`` is also supported.
> +the environment variable ``DPDK_BUILD_TEST_DIR`` or the command line argument ``-b``
> +can be set to that desired location.
> +Environmental variables can also be specified in ``.config/dpdk/devel.config``.
>
>
> .. _integrated_abi_check:
> @@ -483,14 +482,17 @@ Checking ABI compatibility
>
> By default, ABI compatibility checks are disabled.
>
> -To enable them, a reference version must be selected via the environment
> -variable ``DPDK_ABI_REF_VERSION``.
> -
> -The ``devtools/test-build.sh`` and ``devtools/test-meson-builds.sh`` scripts
> -then build this reference version in a temporary directory and store the
> -results in a subfolder of the current working directory.
> -The environment variable ``DPDK_ABI_REF_DIR`` can be set so that the results go
> -to a different location.
> +To enable ABI checks the required reference version must be set using either the
> +environment variable ``DPDK_ABI_REF_VERSION`` or the command line argument ``-a``.
> +The tag ``latest`` is supported, which will select the latest quarterly release.
> +e.g. ``./devtools/test-meson-builds.sh -a latest``.
> +
> +The ``devtools/test-meson-builds.sh`` script will then either build this reference version
> +or download a cached version when available in a temporary directory and store the results
> +in a subfolder of the current working directory.
> +The environment variable ``DPDK_ABI_REF_DIR`` or the argument ``-d`` can be set so that
> +the results go to a different location.
> +Environmental variables can also be specified in ``.config/dpdk/devel.config``.
>
>
> Sending Patches
>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 3/4] devtools: change dump file not found to warning in check-abi.sh
@ 2020-10-14 9:44 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-14 9:44 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 12/10/2020 14:03, Conor Walsh wrote:
> Change dump file not found from an error to a warning to make check-abi.sh
> compatible with the changes to test-meson-builds.sh needed to use
> prebuilt references.
>
> Signed-off-by: Conor Walsh <conor.walsh@intel.com>
>
> ---
> devtools/check-abi.sh | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index ab6748cfb..60d88777e 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -46,8 +46,7 @@ for dump in $(find $refdir -name "*.dump"); do
> fi
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> - echo "Error: can't find $name in $newdir"
> - error=1
> + echo "WARNING: can't find $name in $newdir, are you building with all dependencies?"
> continue
> fi
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 2/4] devtools: abi and UX changes for test-meson-builds.sh
@ 2020-10-14 9:43 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-14 9:43 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 12/10/2020 14:03, Conor Walsh wrote:
> This patch adds new features to test-meson-builds.sh that help to make
> the process of using the script easier, the patch also includes
> changes to make the abi breakage checks more performant.
Avoid commentary such as the above.
I reduce the following list of bullets to a single paragraph describing the change.
The core of this change is to improve build times.
So describe reducing the number of build to 2 and using the pre-build references, and thats it.
> Changes/Additions:
> - Command line arguments added, the changes are fully backwards
> compatible and all previous environmental variables are still supported
> - All paths supplied by user are converted to absolute paths if they
> are relative as meson has a bug that can sometimes error if a
> relative path is supplied to it.
> - abi check/generation code moved to function to improve readability
> - Only 2 abi checks will now be completed:
> - 1 x86_64 gcc or clang check
> - 1 ARM gcc or clang check
> It is not necessary to check abi breakages in every build
> - abi checks can now make use of prebuilt abi references from a http
> or local source, it is hoped these would be hosted on dpdk.org in
> the future.
<new line to aid reading>
> Invoke using "./test-meson-builds.sh [-b <build directory>]
> [-a <dpdk tag or latest for abi check>] [-u <uri for abi references>]
> [-d <directory for abi references>]"
> - <build directory>: directory to store builds (relative or absolute)
> - <dpdk tag or latest for abi check>: dpdk tag e.g. "v20.11" or "latest"
> - <uri for abi references>: http location or directory to get prebuilt
> abi references from
> - <directory for abi references>: directory to store abi references
> (relative or absolute)
> e.g. "./test-meson-builds.sh -a latest"
> If no flags are specified test-meson-builds.sh will run the standard
> meson tests with default options unless environmental variables are
> specified.
>
> Signed-off-by: Conor Walsh <conor.walsh@intel.com>
>
> ---
> devtools/test-meson-builds.sh | 170 +++++++++++++++++++++++++++-------
> 1 file changed, 138 insertions(+), 32 deletions(-)
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index a87de635a..b45506fb0 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -1,12 +1,73 @@
> #! /bin/sh -e
> # SPDX-License-Identifier: BSD-3-Clause
> -# Copyright(c) 2018 Intel Corporation
> +# Copyright(c) 2018-2020 Intel Corporation
>
> # Run meson to auto-configure the various builds.
> # * all builds get put in a directory whose name starts with "build-"
> # * if a build-directory already exists we assume it was properly configured
> # Run ninja after configuration is done.
>
> +# Get arguments
> +usage()
> +{
> + echo "Usage: $0
> + [-b <build directory>]
> + [-a <dpdk tag or latest for abi check>]
> + [-u <uri for abi references>]
> + [-d <directory for abi references>]" 1>&2; exit 1;
> +}
> +
> +DPDK_ABI_DEFAULT_URI="http://dpdk.org/abi-refs"
> +
> +while getopts "a:u:d:b:h" arg; do
> + case $arg in
> + a)
> + if [ -n "$DPDK_ABI_REF_VERSION" ]; then
> + echo "DPDK_ABI_REF_VERSION and -a cannot both be set"
> + exit 1
> + fi
> + DPDK_ABI_REF_VERSION=${OPTARG} ;;
> + u)
> + if [ -n "$DPDK_ABI_TAR_URI" ]; then
> + echo "DPDK_ABI_TAR_URI and -u cannot both be set"
> + exit 1
> + fi
> + DPDK_ABI_TAR_URI=${OPTARG} ;;
> + d)
> + if [ -n "$DPDK_ABI_REF_DIR" ]; then
> + echo "DPDK_ABI_REF_DIR and -d cannot both be set"
> + exit 1
> + fi
> + DPDK_ABI_REF_DIR=${OPTARG} ;;
> + b)
> + if [ -n "$DPDK_BUILD_TEST_DIR" ]; then
> + echo "DPDK_BUILD_TEST_DIR and -a cannot both be set"
> + exit 1
> + fi
> + DPDK_BUILD_TEST_DIR=${OPTARG} ;;
> + h)
> + usage ;;
> + *)
> + usage ;;
> + esac
> +done
> +
> +if [ -n "$DPDK_ABI_REF_VERSION" ] ; then
> + if [ "$DPDK_ABI_REF_VERSION" = "latest" ] ; then
> + DPDK_ABI_REF_VERSION=$(git ls-remote --tags http://dpdk.org/git/dpdk |
> + sed "s/.*\///" | grep -v "r\|{}" |
> + grep '^[^.]*.[^.]*$' | tail -n 1)
> + elif [ -z "$(git ls-remote http://dpdk.org/git/dpdk refs/tags/$DPDK_ABI_REF_VERSION)" ] ; then
> + echo "$DPDK_ABI_REF_VERSION is not a valid DPDK tag"
> + exit 1
> + fi
> +fi
> +if [ -z $DPDK_ABI_TAR_URI ] ; then
> + DPDK_ABI_TAR_URI=$DPDK_ABI_DEFAULT_URI
> +fi
> +# allow the generation script to override value with env var
> +abi_checks_done=${DPDK_ABI_GEN_REF:-0}
> +
> # set pipefail option if possible
> PIPEFAIL=""
> set -o | grep -q pipefail && set -o pipefail && PIPEFAIL=1
> @@ -16,7 +77,11 @@ srcdir=$(dirname $(readlink -f $0))/..
>
> MESON=${MESON:-meson}
> use_shared="--default-library=shared"
> -builds_dir=${DPDK_BUILD_TEST_DIR:-.}
> +builds_dir=${DPDK_BUILD_TEST_DIR:-$srcdir/builds}
> +# ensure path is absolute meson returns error when some paths are relative
> +if echo "$builds_dir" | grep -qv '^/'; then
> + builds_dir=$srcdir/$builds_dir
> +fi
>
> if command -v gmake >/dev/null 2>&1 ; then
> MAKE=gmake
> @@ -123,39 +188,49 @@ install_target () # <builddir> <installdir>
> fi
> }
>
> -build () # <directory> <target compiler | cross file> <meson options>
> +abi_gen_check () # no options
> {
> - targetdir=$1
> - shift
> - crossfile=
> - [ -r $1 ] && crossfile=$1 || targetcc=$1
> - shift
> - # skip build if compiler not available
> - command -v ${CC##* } >/dev/null 2>&1 || return 0
> - if [ -n "$crossfile" ] ; then
> - cross="--cross-file $crossfile"
> - targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
> - $crossfile | tr -d "'" | tr -d '"')
> - else
> - cross=
> + abirefdir=${DPDK_ABI_REF_DIR:-$builds_dir/__reference}/$DPDK_ABI_REF_VERSION
> + mkdir -p $abirefdir
> + # ensure path is absolute meson returns error when some are relative
> + if echo "$abirefdir" | grep -qv '^/'; then
> + abirefdir=$srcdir/$abirefdir
> fi
> - load_env $targetcc || return 0
> - config $srcdir $builds_dir/$targetdir $cross --werror $*
> - compile $builds_dir/$targetdir
> - if [ -n "$DPDK_ABI_REF_VERSION" ]; then
> - abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
> - if [ ! -d $abirefdir/$targetdir ]; then
> + if [ ! -d $abirefdir/$targetdir ]; then
> +
> + # try to get abi reference
> + if echo "$DPDK_ABI_TAR_URI" | grep -q '^http'; then
> + if [ $abi_checks_done -gt -1 ]; then
> + if curl --head --fail --silent \
> + "$DPDK_ABI_TAR_URI/$DPDK_ABI_REF_VERSION/$targetdir.tar.gz" \
> + >/dev/null; then
> + curl -o $abirefdir/$targetdir.tar.gz \
> + $DPDK_ABI_TAR_URI/$DPDK_ABI_REF_VERSION/$targetdir.tar.gz
> + fi
> + fi
> + elif [ $abi_checks_done -gt -1 ]; then
> + if [ -f "$DPDK_ABI_TAR_URI/$targetdir.tar.gz" ]; then
> + cp $DPDK_ABI_TAR_URI/$targetdir.tar.gz \
> + $abirefdir/
> + fi
> + fi
> + if [ -f "$abirefdir/$targetdir.tar.gz" ]; then
> + tar -xf $abirefdir/$targetdir.tar.gz \
> + -C $abirefdir >/dev/null
> + rm -rf $abirefdir/$targetdir.tar.gz
> + # if no reference can be found then generate one
> + else
> # clone current sources
> if [ ! -d $abirefdir/src ]; then
> git clone --local --no-hardlinks \
> - --single-branch \
> - -b $DPDK_ABI_REF_VERSION \
> - $srcdir $abirefdir/src
> + --single-branch \
> + -b $DPDK_ABI_REF_VERSION \
> + $srcdir $abirefdir/src
> fi
>
> rm -rf $abirefdir/build
> config $abirefdir/src $abirefdir/build $cross \
> - -Dexamples= $*
> + -Dexamples= $*
> compile $abirefdir/build
> install_target $abirefdir/build $abirefdir/$targetdir
> $srcdir/devtools/gen-abi.sh $abirefdir/$targetdir
> @@ -164,17 +239,46 @@ build () # <directory> <target compiler | cross file> <meson options>
> find $abirefdir/$targetdir/usr/local -name '*.a' -delete
> rm -rf $abirefdir/$targetdir/usr/local/bin
> rm -rf $abirefdir/$targetdir/usr/local/share
> + rm -rf $abirefdir/$targetdir/usr/local/lib
> fi
> + fi
>
> - install_target $builds_dir/$targetdir \
> - $(readlink -f $builds_dir/$targetdir/install)
> - $srcdir/devtools/gen-abi.sh \
> - $(readlink -f $builds_dir/$targetdir/install)
> + install_target $builds_dir/$targetdir \
> + $(readlink -f $builds_dir/$targetdir/install)
> + $srcdir/devtools/gen-abi.sh \
> + $(readlink -f $builds_dir/$targetdir/install)
> + # check abi if not generating references
> + if [ -z $DPDK_ABI_GEN_REF ] ; then
> $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
> $(readlink -f $builds_dir/$targetdir/install)
> fi
> }
>
> +build () # <directory> <target compiler | cross file> <meson options>
> +{
> + targetdir=$1
> + shift
> + crossfile=
> + [ -r $1 ] && crossfile=$1 || targetcc=$1
> + shift
> + # skip build if compiler not available
> + command -v ${CC##* } >/dev/null 2>&1 || return 0
> + if [ -n "$crossfile" ] ; then
> + cross="--cross-file $crossfile"
> + targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
> + $crossfile | tr -d "'" | tr -d '"')
> + else
> + cross=
> + fi
> + load_env $targetcc || return 0
> + config $srcdir $builds_dir/$targetdir $cross --werror $*
> + compile $builds_dir/$targetdir
> + if [ -n "$DPDK_ABI_REF_VERSION" ] && [ $abi_checks_done -lt 1 ] ; then
> + abi_gen_check
> + abi_checks_done=$((abi_checks_done+1))
> + fi
> +}
> +
> if [ "$1" = "-vv" ] ; then
> TEST_MESON_BUILD_VERY_VERBOSE=1
> elif [ "$1" = "-v" ] ; then
> @@ -189,7 +293,7 @@ fi
> # shared and static linked builds with gcc and clang
> for c in gcc clang ; do
> command -v $c >/dev/null 2>&1 || continue
> - for s in static shared ; do
> + for s in shared static ; do
> export CC="$CCACHE $c"
> build build-$c-$s $c --default-library=$s
> unset CC
> @@ -211,6 +315,8 @@ build build-x86-mingw $srcdir/config/x86/cross-mingw -Dexamples=helloworld
>
> # generic armv8a with clang as host compiler
> f=$srcdir/config/arm/arm64_armv8_linux_gcc
> +# run abi checks with 1 arm build
> +abi_checks_done=$((abi_checks_done-1))
> export CC="clang"
> build build-arm64-host-clang $f $use_shared
> unset CC
> @@ -231,7 +337,7 @@ done
> build_path=$(readlink -f $builds_dir/build-x86-default)
> export DESTDIR=$build_path/install
> # No need to reinstall if ABI checks are enabled
> -if [ -z "$DPDK_ABI_REF_VERSION" ]; then
> +if [ -z "$DPDK_ABI_REF_VERSION" ] ; then
> install_target $build_path $DESTDIR
> fi
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 1/4] devtools: add generation of compressed abi dump archives
@ 2020-10-14 9:38 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-14 9:38 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 12/10/2020 14:03, Conor Walsh wrote:
> This patch adds a script that generates compressed archives
> containing .dump files which can be used to perform abi
> breakage checking in test-meson-build.sh.
<new line to aid reading>
> Invoke using "./gen-abi-tarballs.sh [-v <dpdk tag>]"
> - <dpdk tag>: dpdk tag e.g. "v20.11" or "latest"
> e.g. "./gen-abi-tarballs.sh -v latest"
<new line to aid reading>
> If no tag is specified, the script will default to "latest"
> Using these parameters the script will produce several *.tar.gz
> archives containing .dump files required to do abi breakage checking
>
> Signed-off-by: Conor Walsh <conor.walsh@intel.com>
>
> ---
> devtools/gen-abi-tarballs.sh | 48 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100755 devtools/gen-abi-tarballs.sh
>
> diff --git a/devtools/gen-abi-tarballs.sh b/devtools/gen-abi-tarballs.sh
> new file mode 100755
> index 000000000..bcc1beac5
> --- /dev/null
> +++ b/devtools/gen-abi-tarballs.sh
> @@ -0,0 +1,48 @@
> +#! /bin/sh -e
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2020 Intel Corporation
> +
> +# Generate the required prebuilt ABI references for test-meson-build.sh
> +
> +# Get arguments
> +usage() { echo "Usage: $0 [-v <dpdk tag or latest>]" 1>&2; exit 1; }
> +abi_tag=
> +while getopts "v:h" arg; do
> + case $arg in
> + v)
> + if [ -n "$DPDK_ABI_REF_VERSION" ]; then
> + echo "DPDK_ABI_REF_VERSION and -v cannot both be set"
> + exit 1
> + fi
> + DPDK_ABI_REF_VERSION=${OPTARG} ;;
> + h)
> + usage ;;
> + *)
> + usage ;;
> + esac
> +done
> +
> +if [ -z $DPDK_ABI_REF_VERSION ] ; then
> + DPDK_ABI_REF_VERSION="latest"
> +fi
> +
> +srcdir=$(dirname $(readlink -f $0))/..
> +
> +DPDK_ABI_GEN_REF=-20
> +DPDK_ABI_REF_DIR=$srcdir/__abitarballs
> +
> +. $srcdir/devtools/test-meson-builds.sh
> +
> +abirefdir=$DPDK_ABI_REF_DIR/$DPDK_ABI_REF_VERSION
> +
> +rm -rf $abirefdir/build-*.tar.gz
> +cd $abirefdir
> +for f in build-* ; do
> + tar -czf $f.tar.gz $f
> +done
> +cp *.tar.gz ../
> +rm -rf *
> +mv ../*.tar.gz .
> +rm -rf build-x86-default.tar.gz
> +
> +echo "The references for $DPDK_ABI_REF_VERSION are now available in $abirefdir"
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 0/4] devtools: abi breakage checks
` (3 preceding siblings ...)
@ 2020-10-14 9:37 4% ` Kinsella, Ray
2020-10-14 10:33 4% ` Walsh, Conor
2020-10-14 10:41 10% ` [dpdk-dev] [PATCH v7 " Conor Walsh
5 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2020-10-14 9:37 UTC (permalink / raw)
To: Conor Walsh, nhorman, bruce.richardson, thomas, david.marchand; +Cc: dev
On 12/10/2020 14:03, Conor Walsh wrote:
> This patchset will help developers discover abi breakages more easily
> before upstreaming their code. Currently checking that the DPDK ABI
> has not changed before up-streaming code is not intuitive and the
> process is time consuming. Currently contributors must use the
> test-meson-builds.sh tool, alongside some environmental variables to
> test their changes. Contributors in many cases are either unaware or
> unable to do this themselves, leading to a potentially serious situation
> where they are unknowingly up-streaming code that breaks the ABI. These
> breakages are caught by Travis, but it would be more efficient if they
> were caught locally before up-streaming.
I would remove everything in the git log text before this line...
> This patchset introduces changes
> to test-meson-builds.sh, check-abi.sh and adds a new script
> gen-abi-tarballs.sh. The changes to test-meson-builds.sh include UX
UX changes = improvements
> changes such as adding command line arguments and allowing the use of
> relative paths. Reduced the number of abi checks to just two, one for both
> x86_64 and ARM, the references for these tests can now be prebuilt and
> downloaded by test-meson-builds.sh, these changes will allow the tests to
> run much faster. check-abi.sh is updated to use the prebuilt references.
> gen-abi-tarballs.sh is a new script to generate the prebuilt abi
> references used by test-meson-builds.sh, these compressed archives can be
> retrieved from either a local directory or a remote http location.
>
> ---
> v6: Corrected a mistake in the doc patch
>
> v5:
> - Patchset has been completely reworked following feedback
> - Patchset is now part of test-meson-builds.sh not the meson build system
>
> v4:
> - Reworked both Python scripts to use more native Python functions
> and modules.
> - Python scripts are now in line with how other Python scripts in
> DPDK are structured.
>
> v3:
> - Fix for bug which now allows meson < 0.48.0 to be used
> - Various coding style changes throughout
> - Minor bug fixes to the various meson.build files
>
> v2: Spelling mistake, corrected spelling of environmental
>
> Conor Walsh (4):
> devtools: add generation of compressed abi dump archives
> devtools: abi and UX changes for test-meson-builds.sh
> devtools: change dump file not found to warning in check-abi.sh
> doc: test-meson-builds.sh doc updates
>
> devtools/check-abi.sh | 3 +-
> devtools/gen-abi-tarballs.sh | 48 ++++++++
> devtools/test-meson-builds.sh | 170 ++++++++++++++++++++++------
> doc/guides/contributing/patches.rst | 26 +++--
> 4 files changed, 201 insertions(+), 46 deletions(-)
> create mode 100755 devtools/gen-abi-tarballs.sh
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 00/14] acl: introduce AVX512 classify methods
@ 2020-10-14 9:23 4% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2020-10-14 9:23 UTC (permalink / raw)
To: Ananyev, Konstantin, David Marchand
Cc: dev, Jerin Jacob Kollanukkaran,
Ruifeng Wang (Arm Technology China),
Medvedkin, Vladimir, Thomas Monjalon, Richardson, Bruce
On 06/10/2020 17:07, Ananyev, Konstantin wrote:
>
>>
>> On Mon, Oct 5, 2020 at 9:44 PM Konstantin Ananyev
>> <konstantin.ananyev@intel.com> wrote:
>>>
>>> These patch series introduce support of AVX512 specific classify
>>> implementation for ACL library.
>>> It adds two new algorithms:
>>> - RTE_ACL_CLASSIFY_AVX512X16 - can process up to 16 flows in parallel.
>>> It uses 256-bit width instructions/registers only
>>> (to avoid frequency level change).
>>> On my SKX box test-acl shows ~15-30% improvement
>>> (depending on rule-set and input burst size)
>>> when switching from AVX2 to AVX512X16 classify algorithms.
>>> - RTE_ACL_CLASSIFY_AVX512X32 - can process up to 32 flows in parallel.
>>> It uses 512-bit width instructions/registers and provides higher
>>> performance then AVX512X16, but can cause frequency level change.
>>> On my SKX box test-acl shows ~50-70% improvement
>>> (depending on rule-set and input burst size)
>>> when switching from AVX2 to AVX512X32 classify algorithms.
>>> ICX and CLX testing showed similar level of speedup.
>>>
>>> Current AVX512 classify implementation is only supported on x86_64.
>>> Note that this series introduce a formal ABI incompatibility
>>
>> The only API change I can see is in rte_acl_classify_alg() new error
>> code but I don't think we need an announcement for this.
>> As for ABI, we are breaking it in this release, so I see no pb.
>
> Cool, I just wanted to underline that patch #3:
> https://patches.dpdk.org/patch/79786/
> is a formal ABI breakage.
As David said, this is an ABI breaking release - so there is no requirement to maintain compatibility.
https://doc.dpdk.org/guides/contributing/abi_policy.html
However the following requirements remain:-
* The acknowledgment of the maintainer of the component is mandatory, or if no maintainer is available for the component, the tree/sub-tree maintainer for that component must acknowledge the ABI change instead.
* The acknowledgment of three members of the technical board, as delegates of the technical board acknowledging the need for the ABI change, is also mandatory.
I guess you are the maintainer in this case, so that requirement is satisfied.
>
>>
>>
>>> with previous versions of ACL library.
>>>
>>> v2 -> v3:
>>> Fix checkpatch warnings
>>> Split AVX512 algorithm into two and deduplicate common code
>>
>> Patch 7 still references a RTE_MACHINE_CPUFLAG flag.
>> Can you rework now that those flags have been dropped?
>>
>
> Should be fixed in v4:
> https://patches.dpdk.org/project/dpdk/list/?series=12721
>
> One more thing to mention - this series has a dependency on Vladimir's patch:
> https://patches.dpdk.org/patch/79310/ ("eal/x86: introduce AVX 512-bit type"),
> so CI/travis would still report an error.
>
> Thanks
> Konstantin
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 19:06 0% ` Medvedkin, Vladimir
@ 2020-10-13 19:48 0% ` Michel Machado
2020-10-14 13:10 0% ` Medvedkin, Vladimir
0 siblings, 1 reply; 200+ results
From: Michel Machado @ 2020-10-13 19:48 UTC (permalink / raw)
To: Medvedkin, Vladimir, Kevin Traynor, Ruifeng Wang,
Bruce Richardson, Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, Honnappa Nagarahalli, nd
On 10/13/20 3:06 PM, Medvedkin, Vladimir wrote:
>
>
> On 13/10/2020 18:46, Michel Machado wrote:
>> On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
>>> Hi Michel,
>>>
>>> Could you please describe a condition when LPM gets inconsistent? As
>>> I can see if there is no free tbl8 it will return -ENOSPC.
>>
>> Consider this simple example, we need to add the following two
>> prefixes with different next hops: 10.99.0.0/16, 18.99.99.128/25. If
>> the LPM table is out of tbl8s, the second prefix is not added and
>> Gatekeeper will make decisions in violation of the policy. The data
>> structure of the LPM table is consistent, but its content inconsistent
>> with the policy.
>
> Aha, thanks. So do I understand correctly that you need to add a set of
> routes atomically (either the entire set is installed or nothing)?
Yes.
> If so, then I would suggest having 2 lpm and switching them atomically
> after a successful addition. As for now, even if you have enough tbl8's,
> routes are installed non atomically, i.e. there will be a time gap
> between adding two routes, so in this time interval the table will be
> inconsistent with the policy.
> Also, if new lpm algorithms are added to the DPDK, they won't have such
> a thing as tbl8.
Our code already deals with synchronization.
>> We minimize the need of replacing a LPM table by allocating LPM
>> tables with the double of what we need (see example here
>> https://github.com/AltraMayor/gatekeeper/blob/95d1d6e8201861a0d0c698bfd06ad606674f1e07/lua/examples/policy.lua#L172-L183),
>> but the code must be ready for unexpected needs that may arise in
>> production.
>>
>
> Usually, the table is initialized with a large enough number of entries,
> enough to add a possible number of routes. One tbl8 group takes up 1Kb
> of memory which is nothing comparing to the size of tbl24 which is 64Mb.
When the prefixes come from BGP, initializing a large enough table
is fine. But when prefixes come from threat intelligence, the number of
prefixes can vary wildly and the number of prefixes above 24 bits are
way more common.
> P.S. consider using rte_fib library, it has a number of advantages over
> LPM. You can replace the loop in __lookup_fib_bulk() with a bulk lookup
> call and this will probably increase the speed.
I'm not aware of the rte_fib library. The only documentation that I
found on Google was https://doc.dpdk.org/api/rte__fib_8h.html and it
just says "FIB (Forwarding information base) implementation for IPv4
Longest Prefix Match".
>>>
>>> On 13/10/2020 15:58, Michel Machado wrote:
>>>> Hi Kevin,
>>>>
>>>> We do need fields max_rules and number_tbl8s of struct rte_lpm,
>>>> so the removal would force us to have another patch to our local
>>>> copy of DPDK. We'd rather avoid this new local patch because we wish
>>>> to eventually be in sync with the stock DPDK.
>>>>
>>>> Those fields are needed in Gatekeeper because we found a
>>>> condition in an ongoing deployment in which the entries of some LPM
>>>> tables may suddenly change a lot to reflect policy changes. To avoid
>>>> getting into a state in which the LPM table is inconsistent because
>>>> it cannot fit all the new entries, we compute the needed parameters
>>>> to support the new entries, and compare with the current parameters.
>>>> If the current table doesn't fit everything, we have to replace it
>>>> with a new LPM table.
>>>>
>>>> If there were a way to obtain the struct rte_lpm_config of a
>>>> given LPM table, it would cleanly address our need. We have the same
>>>> need in IPv6 and have a local patch to work around it (see
>>>> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
>>>> Thus, an IPv4 and IPv6 solution would be best.
>>>>
>>>> PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to
>>>> this disscussion.
>>>>
>>>> [ ]'s
>>>> Michel Machado
>>>>
>>>> On 10/13/20 9:53 AM, Kevin Traynor wrote:
>>>>> Hi Gatekeeper maintainers (I think),
>>>>>
>>>>> fyi - there is a proposal to remove some members of a struct in
>>>>> DPDK LPM
>>>>> API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but
>>>>> as it's an LTS I guess it would probably hit Debian in a few months.
>>>>>
>>>>> The full thread is here:
>>>>> http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
>>>>>
>>>>> Maybe you can take a look and tell us if they are needed in Gatekeeper
>>>>> or you can workaround it?
>>>>>
>>>>> thanks,
>>>>> Kevin.
>>>>>
>>>>> [1]
>>>>> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
>>>>>
>>>>>
>>>>> On 09/10/2020 07:54, Ruifeng Wang wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Kevin Traynor <ktraynor@redhat.com>
>>>>>>> Sent: Wednesday, September 30, 2020 4:46 PM
>>>>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>>>>>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>>>>>>> <bruce.richardson@intel.com>
>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>>>>>>
>>>>>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>>>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>>>>>>> <Ruifeng.Wang@arm.com>
>>>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>>>>>>
>>>>>>>>> Hi Ruifeng,
>>>>>>>>>
>>>>>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no
>>>>>>>>>>> need to
>>>>>>>>>>> be exposed to the user.
>>>>>>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>>>>>>> maintainability.
>>>>>>>>>>>
>>>>>>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>>>>>>> ---
>>>>>>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>>>>>>> +++++++++++++++++++++++---------------
>>>>>>>>> -
>>>>>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>> index 03da2d37e..112d96f37 100644
>>>>>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>>>>>>
>>>>>>>>>>> /** @internal LPM structure. */
>>>>>>>>>>> struct rte_lpm {
>>>>>>>>>>> - /* LPM metadata. */
>>>>>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the
>>>>>>>>>>> lpm. */
>>>>>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**<
>>>>>>>>> Rule info table. */
>>>>>>>>>>> -
>>>>>>>>>>> /* LPM Tables. */
>>>>>>>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>>>>>>
>>>>>>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>>>>>>> different, and that return value could be used by
>>>>>>>>>> rte_lpm_lookup()
>>>>>>>>>> which as a static inline function will be in the binary and using
>>>>>>>>>> the old structure offsets.]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>>>>>>> without prior notice.
>>>>>>>>>
>>>>>>>> So if the change wants to happen in 20.11, a deprecation notice
>>>>>>>> should
>>>>>>>> have been added in 20.08.
>>>>>>>> I should have added a deprecation notice. This change will have
>>>>>>>> to wait for
>>>>>>> next ABI update window.
>>>>>>>>
>>>>>>>
>>>>>>> Do you plan to extend? or is this just speculative?
>>>>>> It is speculative.
>>>>>>
>>>>>>>
>>>>>>> A quick scan and there seems to be several projects using some of
>>>>>>> these
>>>>>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>>>>>>> gatekeeper. I didn't look at the details to see if they are
>>>>>>> really needed.
>>>>>>>
>>>>>>> Not sure how much notice they'd need or if they update DPDK much,
>>>>>>> but I
>>>>>>> think it's worth having a closer look as to how they use lpm and
>>>>>>> what the
>>>>>>> impact to them is.
>>>>>> Checked the projects listed above. BESS, NFF-Go and DPVS don't
>>>>>> access the members to be hided.
>>>>>> They will not be impacted by this patch.
>>>>>> But Gatekeeper accesses the rte_lpm internal members that to be
>>>>>> hided. Its compilation will be broken with this patch.
>>>>>>
>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Ruifeng
>>>>>>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>>>>>>> --
>>>>>>>>>>> 2.17.1
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Vladimir
>>>>>>
>>>>>
>>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 15:41 0% ` Medvedkin, Vladimir
@ 2020-10-13 17:46 0% ` Michel Machado
2020-10-13 19:06 0% ` Medvedkin, Vladimir
0 siblings, 1 reply; 200+ results
From: Michel Machado @ 2020-10-13 17:46 UTC (permalink / raw)
To: Medvedkin, Vladimir, Kevin Traynor, Ruifeng Wang,
Bruce Richardson, Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, Honnappa Nagarahalli, nd
On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
> Hi Michel,
>
> Could you please describe a condition when LPM gets inconsistent? As I
> can see if there is no free tbl8 it will return -ENOSPC.
Consider this simple example, we need to add the following two
prefixes with different next hops: 10.99.0.0/16, 18.99.99.128/25. If the
LPM table is out of tbl8s, the second prefix is not added and Gatekeeper
will make decisions in violation of the policy. The data structure of
the LPM table is consistent, but its content inconsistent with the policy.
We minimize the need of replacing a LPM table by allocating LPM
tables with the double of what we need (see example here
https://github.com/AltraMayor/gatekeeper/blob/95d1d6e8201861a0d0c698bfd06ad606674f1e07/lua/examples/policy.lua#L172-L183),
but the code must be ready for unexpected needs that may arise in
production.
>
> On 13/10/2020 15:58, Michel Machado wrote:
>> Hi Kevin,
>>
>> We do need fields max_rules and number_tbl8s of struct rte_lpm, so
>> the removal would force us to have another patch to our local copy of
>> DPDK. We'd rather avoid this new local patch because we wish to
>> eventually be in sync with the stock DPDK.
>>
>> Those fields are needed in Gatekeeper because we found a condition
>> in an ongoing deployment in which the entries of some LPM tables may
>> suddenly change a lot to reflect policy changes. To avoid getting into
>> a state in which the LPM table is inconsistent because it cannot fit
>> all the new entries, we compute the needed parameters to support the
>> new entries, and compare with the current parameters. If the current
>> table doesn't fit everything, we have to replace it with a new LPM table.
>>
>> If there were a way to obtain the struct rte_lpm_config of a given
>> LPM table, it would cleanly address our need. We have the same need in
>> IPv6 and have a local patch to work around it (see
>> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
>> Thus, an IPv4 and IPv6 solution would be best.
>>
>> PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to this
>> disscussion.
>>
>> [ ]'s
>> Michel Machado
>>
>> On 10/13/20 9:53 AM, Kevin Traynor wrote:
>>> Hi Gatekeeper maintainers (I think),
>>>
>>> fyi - there is a proposal to remove some members of a struct in DPDK LPM
>>> API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but
>>> as it's an LTS I guess it would probably hit Debian in a few months.
>>>
>>> The full thread is here:
>>> http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
>>>
>>> Maybe you can take a look and tell us if they are needed in Gatekeeper
>>> or you can workaround it?
>>>
>>> thanks,
>>> Kevin.
>>>
>>> [1]
>>> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
>>>
>>>
>>> On 09/10/2020 07:54, Ruifeng Wang wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Kevin Traynor <ktraynor@redhat.com>
>>>>> Sent: Wednesday, September 30, 2020 4:46 PM
>>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>>>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>>>>> <bruce.richardson@intel.com>
>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>>>>
>>>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>>>>> <Ruifeng.Wang@arm.com>
>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>>>>
>>>>>>> Hi Ruifeng,
>>>>>>>
>>>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to
>>>>>>>>> be exposed to the user.
>>>>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>>>>> maintainability.
>>>>>>>>>
>>>>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>>>>> ---
>>>>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>>>>> +++++++++++++++++++++++---------------
>>>>>>> -
>>>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>>>>>>>>> index 03da2d37e..112d96f37 100644
>>>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>>>>
>>>>>>>>> /** @internal LPM structure. */
>>>>>>>>> struct rte_lpm {
>>>>>>>>> - /* LPM metadata. */
>>>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
>>>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**<
>>>>>>> Rule info table. */
>>>>>>>>> -
>>>>>>>>> /* LPM Tables. */
>>>>>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>>>>
>>>>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>>>>> different, and that return value could be used by rte_lpm_lookup()
>>>>>>>> which as a static inline function will be in the binary and using
>>>>>>>> the old structure offsets.]
>>>>>>>>
>>>>>>>
>>>>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>>>>> without prior notice.
>>>>>>>
>>>>>> So if the change wants to happen in 20.11, a deprecation notice
>>>>>> should
>>>>>> have been added in 20.08.
>>>>>> I should have added a deprecation notice. This change will have to
>>>>>> wait for
>>>>> next ABI update window.
>>>>>>
>>>>>
>>>>> Do you plan to extend? or is this just speculative?
>>>> It is speculative.
>>>>
>>>>>
>>>>> A quick scan and there seems to be several projects using some of
>>>>> these
>>>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>>>>> gatekeeper. I didn't look at the details to see if they are really
>>>>> needed.
>>>>>
>>>>> Not sure how much notice they'd need or if they update DPDK much,
>>>>> but I
>>>>> think it's worth having a closer look as to how they use lpm and
>>>>> what the
>>>>> impact to them is.
>>>> Checked the projects listed above. BESS, NFF-Go and DPVS don't
>>>> access the members to be hided.
>>>> They will not be impacted by this patch.
>>>> But Gatekeeper accesses the rte_lpm internal members that to be
>>>> hided. Its compilation will be broken with this patch.
>>>>
>>>>>
>>>>>> Thanks.
>>>>>> Ruifeng
>>>>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>>>>> --
>>>>>>>>> 2.17.1
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Vladimir
>>>>
>>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 13:53 0% ` Kevin Traynor
@ 2020-10-13 14:58 0% ` Michel Machado
2020-10-13 15:41 0% ` Medvedkin, Vladimir
0 siblings, 1 reply; 200+ results
From: Michel Machado @ 2020-10-13 14:58 UTC (permalink / raw)
To: Kevin Traynor, Ruifeng Wang, Medvedkin, Vladimir,
Bruce Richardson, Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, Honnappa Nagarahalli, nd
Hi Kevin,
We do need fields max_rules and number_tbl8s of struct rte_lpm, so
the removal would force us to have another patch to our local copy of
DPDK. We'd rather avoid this new local patch because we wish to
eventually be in sync with the stock DPDK.
Those fields are needed in Gatekeeper because we found a condition
in an ongoing deployment in which the entries of some LPM tables may
suddenly change a lot to reflect policy changes. To avoid getting into a
state in which the LPM table is inconsistent because it cannot fit all
the new entries, we compute the needed parameters to support the new
entries, and compare with the current parameters. If the current table
doesn't fit everything, we have to replace it with a new LPM table.
If there were a way to obtain the struct rte_lpm_config of a given
LPM table, it would cleanly address our need. We have the same need in
IPv6 and have a local patch to work around it (see
https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
Thus, an IPv4 and IPv6 solution would be best.
PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to this
disscussion.
[ ]'s
Michel Machado
On 10/13/20 9:53 AM, Kevin Traynor wrote:
> Hi Gatekeeper maintainers (I think),
>
> fyi - there is a proposal to remove some members of a struct in DPDK LPM
> API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but
> as it's an LTS I guess it would probably hit Debian in a few months.
>
> The full thread is here:
> http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
>
> Maybe you can take a look and tell us if they are needed in Gatekeeper
> or you can workaround it?
>
> thanks,
> Kevin.
>
> [1]
> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
>
> On 09/10/2020 07:54, Ruifeng Wang wrote:
>>
>>> -----Original Message-----
>>> From: Kevin Traynor <ktraynor@redhat.com>
>>> Sent: Wednesday, September 30, 2020 4:46 PM
>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>>> <bruce.richardson@intel.com>
>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>>
>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>>> <Ruifeng.Wang@arm.com>
>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>>
>>>>> Hi Ruifeng,
>>>>>
>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to
>>>>>>> be exposed to the user.
>>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>>> maintainability.
>>>>>>>
>>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>>> ---
>>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>>> +++++++++++++++++++++++---------------
>>>>> -
>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>>
>>>>>> <snip>
>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>>>>>>> index 03da2d37e..112d96f37 100644
>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>>
>>>>>>> /** @internal LPM structure. */
>>>>>>> struct rte_lpm {
>>>>>>> - /* LPM metadata. */
>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**<
>>>>> Rule info table. */
>>>>>>> -
>>>>>>> /* LPM Tables. */
>>>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>>
>>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>>> different, and that return value could be used by rte_lpm_lookup()
>>>>>> which as a static inline function will be in the binary and using
>>>>>> the old structure offsets.]
>>>>>>
>>>>>
>>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>>> without prior notice.
>>>>>
>>>> So if the change wants to happen in 20.11, a deprecation notice should
>>>> have been added in 20.08.
>>>> I should have added a deprecation notice. This change will have to wait for
>>> next ABI update window.
>>>>
>>>
>>> Do you plan to extend? or is this just speculative?
>> It is speculative.
>>
>>>
>>> A quick scan and there seems to be several projects using some of these
>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>>> gatekeeper. I didn't look at the details to see if they are really needed.
>>>
>>> Not sure how much notice they'd need or if they update DPDK much, but I
>>> think it's worth having a closer look as to how they use lpm and what the
>>> impact to them is.
>> Checked the projects listed above. BESS, NFF-Go and DPVS don't access the members to be hided.
>> They will not be impacted by this patch.
>> But Gatekeeper accesses the rte_lpm internal members that to be hided. Its compilation will be broken with this patch.
>>
>>>
>>>> Thanks.
>>>> Ruifeng
>>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>>> --
>>>>>>> 2.17.1
>>>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Vladimir
>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/2] eventdev: update app and examples for new eventdev ABI
2020-10-12 19:09 4% ` Pavan Nikhilesh Bhagavatula
@ 2020-10-13 19:20 4% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2020-10-13 19:20 UTC (permalink / raw)
To: Pavan Nikhilesh Bhagavatula
Cc: Van Haaren, Harry, McDaniel, Timothy, Jerin Jacob Kollanukkaran,
Kovacevic, Marko, Ori Kam, Richardson, Bruce, Nicolau, Radu,
Akhil Goyal, Kantecki, Tomasz, Sunil Kumar Kori, dev, Carrillo,
Erik G, Eads, Gage, hemant.agrawal
On Tue, Oct 13, 2020 at 12:39 AM Pavan Nikhilesh Bhagavatula
<pbhagavatula@marvell.com> wrote:
>
> >> Subject: [PATCH v2 2/2] eventdev: update app and examples for new
> >eventdev ABI
> >>
> >> Several data structures and constants changed, or were added,
> >> in the previous patch. This commit updates the dependent
> >> apps and examples to use the new ABI.
> >>
> >> Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
>
> With fixes to trace framework
> Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
@McDaniel, Timothy ,
The series has apply issues[1], Could you send the final version with
Ack of Harry and Pavan.
I will merge this series for RC1 and Let's move DLB PMD driver updates to RC2.
[1]
[for-main]dell[dpdk-next-eventdev] $ date &&
/home/jerin/config/scripts/build_each_patch.sh /tmp/r/ && date
Wed Oct 14 12:41:19 AM IST 2020
HEAD is now at b7a8eea2c app/eventdev: enable fast free offload
meson build test
Applying: eventdev: eventdev: express DLB/DLB2 PMD constraints
Using index info to reconstruct a base tree...
M drivers/event/dpaa2/dpaa2_eventdev.c
M drivers/event/octeontx/ssovf_evdev.c
M drivers/event/octeontx2/otx2_evdev.c
M lib/librte_eventdev/rte_event_eth_tx_adapter.c
M lib/librte_eventdev/rte_eventdev.c
Falling back to patching base and 3-way merge...
Auto-merging lib/librte_eventdev/rte_eventdev.c
CONFLICT (content): Merge conflict in lib/librte_eventdev/rte_eventdev.c
Auto-merging lib/librte_eventdev/rte_event_eth_tx_adapter.c
Auto-merging drivers/event/octeontx2/otx2_evdev.c
Auto-merging drivers/event/octeontx/ssovf_evdev.c
Auto-merging drivers/event/dpaa2/dpaa2_eventdev.c
Recorded preimage for 'lib/librte_eventdev/rte_eventdev.c'
error: Failed to merge in the changes.
Patch failed at 0001 eventdev: eventdev: express DLB/DLB2 PMD constraints
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
git am failed /tmp/r//v2-1-2-eventdev-eventdev-express-DLB-DLB2-PMD-constraints
HEAD is now at b7a8eea2c app/eventdev: enable fast free offload
Wed Oct 14 12:41:19 AM IST 2020
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 17:46 0% ` Michel Machado
@ 2020-10-13 19:06 0% ` Medvedkin, Vladimir
2020-10-13 19:48 0% ` Michel Machado
0 siblings, 1 reply; 200+ results
From: Medvedkin, Vladimir @ 2020-10-13 19:06 UTC (permalink / raw)
To: Michel Machado, Kevin Traynor, Ruifeng Wang, Bruce Richardson,
Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, Honnappa Nagarahalli, nd
On 13/10/2020 18:46, Michel Machado wrote:
> On 10/13/20 11:41 AM, Medvedkin, Vladimir wrote:
>> Hi Michel,
>>
>> Could you please describe a condition when LPM gets inconsistent? As I
>> can see if there is no free tbl8 it will return -ENOSPC.
>
> Consider this simple example, we need to add the following two
> prefixes with different next hops: 10.99.0.0/16, 18.99.99.128/25. If the
> LPM table is out of tbl8s, the second prefix is not added and Gatekeeper
> will make decisions in violation of the policy. The data structure of
> the LPM table is consistent, but its content inconsistent with the policy.
Aha, thanks. So do I understand correctly that you need to add a set of
routes atomically (either the entire set is installed or nothing)?
If so, then I would suggest having 2 lpm and switching them atomically
after a successful addition. As for now, even if you have enough tbl8's,
routes are installed non atomically, i.e. there will be a time gap
between adding two routes, so in this time interval the table will be
inconsistent with the policy.
Also, if new lpm algorithms are added to the DPDK, they won't have such
a thing as tbl8.
>
> We minimize the need of replacing a LPM table by allocating LPM
> tables with the double of what we need (see example here
> https://github.com/AltraMayor/gatekeeper/blob/95d1d6e8201861a0d0c698bfd06ad606674f1e07/lua/examples/policy.lua#L172-L183),
> but the code must be ready for unexpected needs that may arise in
> production.
>
Usually, the table is initialized with a large enough number of entries,
enough to add a possible number of routes. One tbl8 group takes up 1Kb
of memory which is nothing comparing to the size of tbl24 which is 64Mb.
P.S. consider using rte_fib library, it has a number of advantages over
LPM. You can replace the loop in __lookup_fib_bulk() with a bulk lookup
call and this will probably increase the speed.
>>
>> On 13/10/2020 15:58, Michel Machado wrote:
>>> Hi Kevin,
>>>
>>> We do need fields max_rules and number_tbl8s of struct rte_lpm,
>>> so the removal would force us to have another patch to our local copy
>>> of DPDK. We'd rather avoid this new local patch because we wish to
>>> eventually be in sync with the stock DPDK.
>>>
>>> Those fields are needed in Gatekeeper because we found a
>>> condition in an ongoing deployment in which the entries of some LPM
>>> tables may suddenly change a lot to reflect policy changes. To avoid
>>> getting into a state in which the LPM table is inconsistent because
>>> it cannot fit all the new entries, we compute the needed parameters
>>> to support the new entries, and compare with the current parameters.
>>> If the current table doesn't fit everything, we have to replace it
>>> with a new LPM table.
>>>
>>> If there were a way to obtain the struct rte_lpm_config of a
>>> given LPM table, it would cleanly address our need. We have the same
>>> need in IPv6 and have a local patch to work around it (see
>>> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
>>> Thus, an IPv4 and IPv6 solution would be best.
>>>
>>> PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to this
>>> disscussion.
>>>
>>> [ ]'s
>>> Michel Machado
>>>
>>> On 10/13/20 9:53 AM, Kevin Traynor wrote:
>>>> Hi Gatekeeper maintainers (I think),
>>>>
>>>> fyi - there is a proposal to remove some members of a struct in DPDK
>>>> LPM
>>>> API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but
>>>> as it's an LTS I guess it would probably hit Debian in a few months.
>>>>
>>>> The full thread is here:
>>>> http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
>>>>
>>>> Maybe you can take a look and tell us if they are needed in Gatekeeper
>>>> or you can workaround it?
>>>>
>>>> thanks,
>>>> Kevin.
>>>>
>>>> [1]
>>>> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
>>>>
>>>>
>>>> On 09/10/2020 07:54, Ruifeng Wang wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Kevin Traynor <ktraynor@redhat.com>
>>>>>> Sent: Wednesday, September 30, 2020 4:46 PM
>>>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>>>>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>>>>>> <bruce.richardson@intel.com>
>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>>>>>
>>>>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>>>>>> <Ruifeng.Wang@arm.com>
>>>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>>>>>
>>>>>>>> Hi Ruifeng,
>>>>>>>>
>>>>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to
>>>>>>>>>> be exposed to the user.
>>>>>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>>>>>> maintainability.
>>>>>>>>>>
>>>>>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>>>>>> ---
>>>>>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>>>>>> +++++++++++++++++++++++---------------
>>>>>>>> -
>>>>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>>>>>>>>>> index 03da2d37e..112d96f37 100644
>>>>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>>>>>
>>>>>>>>>> /** @internal LPM structure. */
>>>>>>>>>> struct rte_lpm {
>>>>>>>>>> - /* LPM metadata. */
>>>>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
>>>>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**<
>>>>>>>> Rule info table. */
>>>>>>>>>> -
>>>>>>>>>> /* LPM Tables. */
>>>>>>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>>>>>
>>>>>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>>>>>> different, and that return value could be used by rte_lpm_lookup()
>>>>>>>>> which as a static inline function will be in the binary and using
>>>>>>>>> the old structure offsets.]
>>>>>>>>>
>>>>>>>>
>>>>>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>>>>>> without prior notice.
>>>>>>>>
>>>>>>> So if the change wants to happen in 20.11, a deprecation notice
>>>>>>> should
>>>>>>> have been added in 20.08.
>>>>>>> I should have added a deprecation notice. This change will have
>>>>>>> to wait for
>>>>>> next ABI update window.
>>>>>>>
>>>>>>
>>>>>> Do you plan to extend? or is this just speculative?
>>>>> It is speculative.
>>>>>
>>>>>>
>>>>>> A quick scan and there seems to be several projects using some of
>>>>>> these
>>>>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>>>>>> gatekeeper. I didn't look at the details to see if they are really
>>>>>> needed.
>>>>>>
>>>>>> Not sure how much notice they'd need or if they update DPDK much,
>>>>>> but I
>>>>>> think it's worth having a closer look as to how they use lpm and
>>>>>> what the
>>>>>> impact to them is.
>>>>> Checked the projects listed above. BESS, NFF-Go and DPVS don't
>>>>> access the members to be hided.
>>>>> They will not be impacted by this patch.
>>>>> But Gatekeeper accesses the rte_lpm internal members that to be
>>>>> hided. Its compilation will be broken with this patch.
>>>>>
>>>>>>
>>>>>>> Thanks.
>>>>>>> Ruifeng
>>>>>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>>>>>> --
>>>>>>>>>> 2.17.1
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Vladimir
>>>>>
>>>>
>>
--
Regards,
Vladimir
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 2/5] ethdev: add new attributes to hairpin config
@ 2020-10-13 16:19 4% ` Bing Zhao
0 siblings, 0 replies; 200+ results
From: Bing Zhao @ 2020-10-13 16:19 UTC (permalink / raw)
To: thomas, orika, ferruh.yigit, arybchenko, mdr, nhorman,
bernard.iremonger, beilei.xing, wenzhuo.lu
Cc: dev
To support two ports hairpin mode and keep the backward compatibility
for the application, two new attribute members of the hairpin queue
configuration structure will be added.
`tx_explicit` means if the application itself will insert the TX part
flow rules. If not set, PMD will insert the rules implicitly.
`manual_bind` means if the hairpin TX queue and peer RX queue will be
bound automatically during the device start stage.
Different TX and RX queue pairs could have different values, but it
is highly recommended that all paired queues between one egress and
its peer ingress ports have the same values, in order not to bring
any chaos to the system. The actual support of these attribute
parameters will be checked and decided by the PMD drivers.
In the single port hairpin, if both are zero without any setting, the
behavior will remain the same as before. It means that no bind API
needs to be called and no TX flow rules need to be inserted manually
by the application.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
v4: squash document update and more info for the two new attributes
v2: optimize the structure and remove unused macros
---
doc/guides/prog_guide/rte_flow.rst | 3 +++
doc/guides/rel_notes/release_20_11.rst | 6 ++++++
lib/librte_ethdev/rte_ethdev.c | 8 ++++----
lib/librte_ethdev/rte_ethdev.h | 27 ++++++++++++++++++++++++++-
4 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 119b128..bb54d67 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2592,6 +2592,9 @@ set, unpredictable value will be seen depending on driver implementation. For
loopback/hairpin packet, metadata set on Rx/Tx may or may not be propagated to
the other path depending on HW capability.
+In hairpin case with TX explicit flow mode, metadata could (not mandatory) be
+used to connect the RX and TX flows if it can be propagated from RX to TX path.
+
.. _table_rte_flow_action_set_meta:
.. table:: SET_META
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index 6b3d223..a1e20a6 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -63,6 +63,7 @@ New Features
* **Updated the ethdev library to support hairpin between two ports.**
New APIs are introduced to support binding / unbinding 2 ports hairpin.
+ Hairpin TX part flow rules can be inserted explicitly.
* **Updated Broadcom bnxt driver.**
@@ -318,6 +319,11 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+ * ``struct rte_eth_hairpin_conf`` has two new members:
+
+ * ``uint32_t tx_explicit:1;``
+ * ``uint32_t manual_bind:1;``
+
Known Issues
------------
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index b6371fb..14b9f3a 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1954,13 +1954,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_rx_2_tx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Rx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_rx_2_tx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Rx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
@@ -2125,13 +2125,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_tx_2_rx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Tx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_tx_2_rx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Tx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 5106098..938df08 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1045,7 +1045,32 @@ struct rte_eth_hairpin_peer {
* A structure used to configure hairpin binding.
*/
struct rte_eth_hairpin_conf {
- uint16_t peer_count; /**< The number of peers. */
+ uint32_t peer_count:16; /**< The number of peers. */
+
+ /**
+ * Explicit TX flow rule mode. One hairpin pair of queues should have
+ * the same attribute. The actual support depends on the PMD.
+ *
+ * - When set, the user should be responsible for inserting the hairpin
+ * TX part flows and removing them.
+ * - When clear, the PMD will try to handle the TX part of the flows,
+ * e.g., by splitting one flow into two parts.
+ */
+ uint32_t tx_explicit:1;
+
+ /**
+ * Manually bind hairpin queues. One hairpin pair of queues should have
+ * the same attribute. The actual support depends on the PMD.
+ *
+ * - When set, to enable hairpin, the user should call the hairpin bind
+ * API after all the queues are set up properly and the ports are
+ * started. Also, the hairpin unbind API should be called accordingly
+ * before stopping a port that with hairpin configured.
+ * - When clear, the PMD will try to enable the hairpin with the queues
+ * configured automatically during port start.
+ */
+ uint32_t manual_bind:1;
+ uint32_t reserved:14; /**< Reserved bits. */
struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
};
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
2020-10-13 14:58 0% ` Michel Machado
@ 2020-10-13 15:41 0% ` Medvedkin, Vladimir
2020-10-13 17:46 0% ` Michel Machado
0 siblings, 1 reply; 200+ results
From: Medvedkin, Vladimir @ 2020-10-13 15:41 UTC (permalink / raw)
To: Michel Machado, Kevin Traynor, Ruifeng Wang, Bruce Richardson,
Cody Doucette, Andre Nathan, Qiaobin Fu
Cc: dev, Honnappa Nagarahalli, nd
Hi Michel,
Could you please describe a condition when LPM gets inconsistent? As I
can see if there is no free tbl8 it will return -ENOSPC.
On 13/10/2020 15:58, Michel Machado wrote:
> Hi Kevin,
>
> We do need fields max_rules and number_tbl8s of struct rte_lpm, so
> the removal would force us to have another patch to our local copy of
> DPDK. We'd rather avoid this new local patch because we wish to
> eventually be in sync with the stock DPDK.
>
> Those fields are needed in Gatekeeper because we found a condition
> in an ongoing deployment in which the entries of some LPM tables may
> suddenly change a lot to reflect policy changes. To avoid getting into a
> state in which the LPM table is inconsistent because it cannot fit all
> the new entries, we compute the needed parameters to support the new
> entries, and compare with the current parameters. If the current table
> doesn't fit everything, we have to replace it with a new LPM table.
>
> If there were a way to obtain the struct rte_lpm_config of a given
> LPM table, it would cleanly address our need. We have the same need in
> IPv6 and have a local patch to work around it (see
> https://github.com/cjdoucette/dpdk/commit/3eaf124a781349b8ec8cd880db26a78115cb8c8f).
> Thus, an IPv4 and IPv6 solution would be best.
>
> PS: I've added Qiaobin Fu, another Gatekeeper maintainer, to this
> disscussion.
>
> [ ]'s
> Michel Machado
>
> On 10/13/20 9:53 AM, Kevin Traynor wrote:
>> Hi Gatekeeper maintainers (I think),
>>
>> fyi - there is a proposal to remove some members of a struct in DPDK LPM
>> API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but
>> as it's an LTS I guess it would probably hit Debian in a few months.
>>
>> The full thread is here:
>> http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
>>
>> Maybe you can take a look and tell us if they are needed in Gatekeeper
>> or you can workaround it?
>>
>> thanks,
>> Kevin.
>>
>> [1]
>> https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
>>
>>
>> On 09/10/2020 07:54, Ruifeng Wang wrote:
>>>
>>>> -----Original Message-----
>>>> From: Kevin Traynor <ktraynor@redhat.com>
>>>> Sent: Wednesday, September 30, 2020 4:46 PM
>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>>>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>>>> <bruce.richardson@intel.com>
>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>>>
>>>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>>>> <Ruifeng.Wang@arm.com>
>>>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>>>
>>>>>> Hi Ruifeng,
>>>>>>
>>>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to
>>>>>>>> be exposed to the user.
>>>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>>>> maintainability.
>>>>>>>>
>>>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>>>> ---
>>>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>>>> +++++++++++++++++++++++---------------
>>>>>> -
>>>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>>>
>>>>>>> <snip>
>>>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>>>>>>>> index 03da2d37e..112d96f37 100644
>>>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>>>
>>>>>>>> /** @internal LPM structure. */
>>>>>>>> struct rte_lpm {
>>>>>>>> - /* LPM metadata. */
>>>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
>>>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**<
>>>>>> Rule info table. */
>>>>>>>> -
>>>>>>>> /* LPM Tables. */
>>>>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>>>
>>>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>>>> different, and that return value could be used by rte_lpm_lookup()
>>>>>>> which as a static inline function will be in the binary and using
>>>>>>> the old structure offsets.]
>>>>>>>
>>>>>>
>>>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>>>> without prior notice.
>>>>>>
>>>>> So if the change wants to happen in 20.11, a deprecation notice should
>>>>> have been added in 20.08.
>>>>> I should have added a deprecation notice. This change will have to
>>>>> wait for
>>>> next ABI update window.
>>>>>
>>>>
>>>> Do you plan to extend? or is this just speculative?
>>> It is speculative.
>>>
>>>>
>>>> A quick scan and there seems to be several projects using some of these
>>>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>>>> gatekeeper. I didn't look at the details to see if they are really
>>>> needed.
>>>>
>>>> Not sure how much notice they'd need or if they update DPDK much, but I
>>>> think it's worth having a closer look as to how they use lpm and
>>>> what the
>>>> impact to them is.
>>> Checked the projects listed above. BESS, NFF-Go and DPVS don't access
>>> the members to be hided.
>>> They will not be impacted by this patch.
>>> But Gatekeeper accesses the rte_lpm internal members that to be
>>> hided. Its compilation will be broken with this patch.
>>>
>>>>
>>>>> Thanks.
>>>>> Ruifeng
>>>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>>>> --
>>>>>>>> 2.17.1
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Vladimir
>>>
>>
--
Regards,
Vladimir
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 03/18] eal: rename lcore word choices
@ 2020-10-13 15:25 1% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2020-10-13 15:25 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Anatoly Burakov, Ray Kinsella, Neil Horman,
Mattias Rönnblom, Harry van Haaren, Bruce Richardson,
Dmitry Kozlyuk, Narcisa Ana Maria Vasile, Dmitry Malloy,
Pallavi Kadam
Replace master lcore with main lcore and
replace slave lcore with worker lcore.
Keep the old functions and macros but mark them as deprecated
for this release.
The "--master-lcore" command line option is also deprecated
and any usage will print a warning and use "--main-lcore"
as replacement.
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 19 -------
doc/guides/rel_notes/release_20_11.rst | 11 ++++
lib/librte_eal/common/eal_common_dynmem.c | 10 ++--
lib/librte_eal/common/eal_common_launch.c | 36 ++++++------
lib/librte_eal/common/eal_common_lcore.c | 8 +--
lib/librte_eal/common/eal_common_options.c | 64 ++++++++++++----------
lib/librte_eal/common/eal_options.h | 2 +
lib/librte_eal/common/eal_private.h | 6 +-
lib/librte_eal/common/rte_random.c | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
lib/librte_eal/freebsd/eal.c | 28 +++++-----
lib/librte_eal/freebsd/eal_thread.c | 32 +++++------
lib/librte_eal/include/rte_eal.h | 4 +-
lib/librte_eal/include/rte_eal_trace.h | 4 +-
lib/librte_eal/include/rte_launch.h | 60 ++++++++++----------
lib/librte_eal/include/rte_lcore.h | 35 ++++++++----
lib/librte_eal/linux/eal.c | 28 +++++-----
lib/librte_eal/linux/eal_memory.c | 10 ++--
lib/librte_eal/linux/eal_thread.c | 32 +++++------
lib/librte_eal/rte_eal_version.map | 2 +-
lib/librte_eal/windows/eal.c | 16 +++---
lib/librte_eal/windows/eal_thread.c | 30 +++++-----
22 files changed, 230 insertions(+), 211 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 584e72087934..7271e9ca4d39 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,25 +20,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: To be more inclusive in choice of naming, the DPDK project
- will replace uses of master/slave in the API's and command line arguments.
-
- References to master/slave in relation to lcore will be renamed
- to initial/worker. The function ``rte_get_master_lcore()``
- will be renamed to ``rte_get_initial_lcore()``.
- For the 20.11 release, both names will be present and the
- old function will be marked with the deprecated tag.
- The old function will be removed in a future version.
-
- The iterator for worker lcores will also change:
- ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
- ``RTE_LCORE_FOREACH_WORKER``.
-
- The ``master-lcore`` argument to testpmd will be replaced
- with ``initial-lcore``. The old ``master-lcore`` argument
- will produce a runtime notification in 20.11 release, and
- be removed completely in a future release.
-
* 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 as well as macros.
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index b7881f2e9d5a..8fa0605ad6cb 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -292,6 +292,17 @@ API Changes
* bpf: ``RTE_BPF_XTYPE_NUM`` has been dropped from ``rte_bpf_xtype``.
+* eal: Changed the function ``rte_get_master_lcore()`` is
+ replaced to ``rte_get_main_lcore()``. The old function is deprecated.
+
+ The iterator for worker lcores will also change:
+ ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
+ ``RTE_LCORE_FOREACH_WORKER``.
+
+ The ``master-lcore`` argument to testpmd will be replaced
+ with ``main-lcore``. The old ``master-lcore`` argument
+ will produce a runtime notification in 20.11 release, and
+ be removed completely in a future release.
ABI Changes
-----------
diff --git a/lib/librte_eal/common/eal_common_dynmem.c b/lib/librte_eal/common/eal_common_dynmem.c
index 614648d8a4de..1cefe52443c4 100644
--- a/lib/librte_eal/common/eal_common_dynmem.c
+++ b/lib/librte_eal/common/eal_common_dynmem.c
@@ -427,19 +427,19 @@ eal_dynmem_calc_num_pages_per_socket(
total_size -= default_size;
}
#else
- /* in 32-bit mode, allocate all of the memory only on master
+ /* in 32-bit mode, allocate all of the memory only on main
* lcore socket
*/
total_size = internal_conf->memory;
for (socket = 0; socket < RTE_MAX_NUMA_NODES && total_size != 0;
socket++) {
struct rte_config *cfg = rte_eal_get_configuration();
- unsigned int master_lcore_socket;
+ unsigned int main_lcore_socket;
- master_lcore_socket =
- rte_lcore_to_socket_id(cfg->master_lcore);
+ main_lcore_socket =
+ rte_lcore_to_socket_id(cfg->main_lcore);
- if (master_lcore_socket != socket)
+ if (main_lcore_socket != socket)
continue;
/* Update sizes */
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index cf52d717f68e..34f854ad80c8 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -21,55 +21,55 @@
* Wait until a lcore finished its job.
*/
int
-rte_eal_wait_lcore(unsigned slave_id)
+rte_eal_wait_lcore(unsigned worker_id)
{
- if (lcore_config[slave_id].state == WAIT)
+ if (lcore_config[worker_id].state == WAIT)
return 0;
- while (lcore_config[slave_id].state != WAIT &&
- lcore_config[slave_id].state != FINISHED)
+ while (lcore_config[worker_id].state != WAIT &&
+ lcore_config[worker_id].state != FINISHED)
rte_pause();
rte_rmb();
/* we are in finished state, go to wait state */
- lcore_config[slave_id].state = WAIT;
- return lcore_config[slave_id].ret;
+ lcore_config[worker_id].state = WAIT;
+ return lcore_config[worker_id].ret;
}
/*
- * Check that every SLAVE lcores are in WAIT state, then call
- * rte_eal_remote_launch() for all of them. If call_master is true
- * (set to CALL_MASTER), also call the function on the master lcore.
+ * Check that every WORKER lcores are in WAIT state, then call
+ * rte_eal_remote_launch() for all of them. If call_main is true
+ * (set to CALL_MAIN), also call the function on the main lcore.
*/
int
rte_eal_mp_remote_launch(int (*f)(void *), void *arg,
- enum rte_rmt_call_master_t call_master)
+ enum rte_rmt_call_main_t call_main)
{
int lcore_id;
- int master = rte_get_master_lcore();
+ int main_lcore = rte_get_main_lcore();
/* check state of lcores */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (lcore_config[lcore_id].state != WAIT)
return -EBUSY;
}
/* send messages to cores */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_remote_launch(f, arg, lcore_id);
}
- if (call_master == CALL_MASTER) {
- lcore_config[master].ret = f(arg);
- lcore_config[master].state = FINISHED;
+ if (call_main == CALL_MAIN) {
+ lcore_config[main_lcore].ret = f(arg);
+ lcore_config[main_lcore].state = FINISHED;
}
return 0;
}
/*
- * Return the state of the lcore identified by slave_id.
+ * Return the state of the lcore identified by worker_id.
*/
enum rte_lcore_state_t
rte_eal_get_lcore_state(unsigned lcore_id)
@@ -86,7 +86,7 @@ rte_eal_mp_wait_lcore(void)
{
unsigned lcore_id;
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_wait_lcore(lcore_id);
}
}
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index d64569b3c758..66d6bad1a7d7 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -18,9 +18,9 @@
#include "eal_private.h"
#include "eal_thread.h"
-unsigned int rte_get_master_lcore(void)
+unsigned int rte_get_main_lcore(void)
{
- return rte_eal_get_configuration()->master_lcore;
+ return rte_eal_get_configuration()->main_lcore;
}
unsigned int rte_lcore_count(void)
@@ -93,7 +93,7 @@ int rte_lcore_is_enabled(unsigned int lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap)
+unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap)
{
i++;
if (wrap)
@@ -101,7 +101,7 @@ unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap)
while (i < RTE_MAX_LCORE) {
if (!rte_lcore_is_enabled(i) ||
- (skip_master && (i == rte_get_master_lcore()))) {
+ (skip_main && (i == rte_get_main_lcore()))) {
i++;
if (wrap)
i %= RTE_MAX_LCORE;
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index a5426e12346a..d221886eb22c 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -81,6 +81,7 @@ eal_long_options[] = {
{OPT_TRACE_BUF_SIZE, 1, NULL, OPT_TRACE_BUF_SIZE_NUM },
{OPT_TRACE_MODE, 1, NULL, OPT_TRACE_MODE_NUM },
{OPT_MASTER_LCORE, 1, NULL, OPT_MASTER_LCORE_NUM },
+ {OPT_MAIN_LCORE, 1, NULL, OPT_MAIN_LCORE_NUM },
{OPT_MBUF_POOL_OPS_NAME, 1, NULL, OPT_MBUF_POOL_OPS_NAME_NUM},
{OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
{OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
@@ -144,7 +145,7 @@ struct device_option {
static struct device_option_list devopt_list =
TAILQ_HEAD_INITIALIZER(devopt_list);
-static int master_lcore_parsed;
+static int main_lcore_parsed;
static int mem_parsed;
static int core_parsed;
@@ -575,12 +576,12 @@ eal_parse_service_coremask(const char *coremask)
for (j = 0; j < BITS_PER_HEX && idx < RTE_MAX_LCORE;
j++, idx++) {
if ((1 << j) & val) {
- /* handle master lcore already parsed */
+ /* handle main lcore already parsed */
uint32_t lcore = idx;
- if (master_lcore_parsed &&
- cfg->master_lcore == lcore) {
+ if (main_lcore_parsed &&
+ cfg->main_lcore == lcore) {
RTE_LOG(ERR, EAL,
- "lcore %u is master lcore, cannot use as service core\n",
+ "lcore %u is main lcore, cannot use as service core\n",
idx);
return -1;
}
@@ -748,12 +749,12 @@ eal_parse_service_corelist(const char *corelist)
min = idx;
for (idx = min; idx <= max; idx++) {
if (cfg->lcore_role[idx] != ROLE_SERVICE) {
- /* handle master lcore already parsed */
+ /* handle main lcore already parsed */
uint32_t lcore = idx;
- if (cfg->master_lcore == lcore &&
- master_lcore_parsed) {
+ if (cfg->main_lcore == lcore &&
+ main_lcore_parsed) {
RTE_LOG(ERR, EAL,
- "Error: lcore %u is master lcore, cannot use as service core\n",
+ "Error: lcore %u is main lcore, cannot use as service core\n",
idx);
return -1;
}
@@ -836,25 +837,25 @@ eal_parse_corelist(const char *corelist, int *cores)
return 0;
}
-/* Changes the lcore id of the master thread */
+/* Changes the lcore id of the main thread */
static int
-eal_parse_master_lcore(const char *arg)
+eal_parse_main_lcore(const char *arg)
{
char *parsing_end;
struct rte_config *cfg = rte_eal_get_configuration();
errno = 0;
- cfg->master_lcore = (uint32_t) strtol(arg, &parsing_end, 0);
+ cfg->main_lcore = (uint32_t) strtol(arg, &parsing_end, 0);
if (errno || parsing_end[0] != 0)
return -1;
- if (cfg->master_lcore >= RTE_MAX_LCORE)
+ if (cfg->main_lcore >= RTE_MAX_LCORE)
return -1;
- master_lcore_parsed = 1;
+ main_lcore_parsed = 1;
- /* ensure master core is not used as service core */
- if (lcore_config[cfg->master_lcore].core_role == ROLE_SERVICE) {
+ /* ensure main core is not used as service core */
+ if (lcore_config[cfg->main_lcore].core_role == ROLE_SERVICE) {
RTE_LOG(ERR, EAL,
- "Error: Master lcore is used as a service core\n");
+ "Error: Main lcore is used as a service core\n");
return -1;
}
@@ -1593,9 +1594,14 @@ eal_parse_common_option(int opt, const char *optarg,
break;
case OPT_MASTER_LCORE_NUM:
- if (eal_parse_master_lcore(optarg) < 0) {
+ fprintf(stderr,
+ "Option --" OPT_MASTER_LCORE
+ " is deprecated use " OPT_MAIN_LCORE "\n");
+ /* fallthrough */
+ case OPT_MAIN_LCORE_NUM:
+ if (eal_parse_main_lcore(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
- OPT_MASTER_LCORE "\n");
+ OPT_MAIN_LCORE "\n");
return -1;
}
break;
@@ -1763,9 +1769,9 @@ compute_ctrl_threads_cpuset(struct internal_config *internal_cfg)
RTE_CPU_AND(cpuset, cpuset, &default_set);
- /* if no remaining cpu, use master lcore cpu affinity */
+ /* if no remaining cpu, use main lcore cpu affinity */
if (!CPU_COUNT(cpuset)) {
- memcpy(cpuset, &lcore_config[rte_get_master_lcore()].cpuset,
+ memcpy(cpuset, &lcore_config[rte_get_main_lcore()].cpuset,
sizeof(*cpuset));
}
}
@@ -1797,12 +1803,12 @@ eal_adjust_config(struct internal_config *internal_cfg)
if (internal_conf->process_type == RTE_PROC_AUTO)
internal_conf->process_type = eal_proc_type_detect();
- /* default master lcore is the first one */
- if (!master_lcore_parsed) {
- cfg->master_lcore = rte_get_next_lcore(-1, 0, 0);
- if (cfg->master_lcore >= RTE_MAX_LCORE)
+ /* default main lcore is the first one */
+ if (!main_lcore_parsed) {
+ cfg->main_lcore = rte_get_next_lcore(-1, 0, 0);
+ if (cfg->main_lcore >= RTE_MAX_LCORE)
return -1;
- lcore_config[cfg->master_lcore].core_role = ROLE_RTE;
+ lcore_config[cfg->main_lcore].core_role = ROLE_RTE;
}
compute_ctrl_threads_cpuset(internal_cfg);
@@ -1822,8 +1828,8 @@ eal_check_common_options(struct internal_config *internal_cfg)
const struct internal_config *internal_conf =
eal_get_internal_configuration();
- if (cfg->lcore_role[cfg->master_lcore] != ROLE_RTE) {
- RTE_LOG(ERR, EAL, "Master lcore is not enabled for DPDK\n");
+ if (cfg->lcore_role[cfg->main_lcore] != ROLE_RTE) {
+ RTE_LOG(ERR, EAL, "Main lcore is not enabled for DPDK\n");
return -1;
}
@@ -1921,7 +1927,7 @@ eal_common_usage(void)
" '( )' can be omitted for single element group,\n"
" '@' can be omitted if cpus and lcores have the same value\n"
" -s SERVICE COREMASK Hexadecimal bitmask of cores to be used as service cores\n"
- " --"OPT_MASTER_LCORE" ID Core ID that is used as master\n"
+ " --"OPT_MAIN_LCORE" ID Core ID that is used as main\n"
" --"OPT_MBUF_POOL_OPS_NAME" Pool ops name for mbuf to use\n"
" -n CHANNELS Number of memory channels\n"
" -m MB Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index 89769d48b487..d363228a7a25 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -43,6 +43,8 @@ enum {
OPT_TRACE_BUF_SIZE_NUM,
#define OPT_TRACE_MODE "trace-mode"
OPT_TRACE_MODE_NUM,
+#define OPT_MAIN_LCORE "main-lcore"
+ OPT_MAIN_LCORE_NUM,
#define OPT_MASTER_LCORE "master-lcore"
OPT_MASTER_LCORE_NUM,
#define OPT_MBUF_POOL_OPS_NAME "mbuf-pool-ops-name"
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index a6a6381567f4..4684c4c7df19 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -20,8 +20,8 @@
*/
struct lcore_config {
pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
+ int pipe_main2worker[2]; /**< communication pipe with main */
+ int pipe_worker2main[2]; /**< communication pipe with main */
lcore_function_t * volatile f; /**< function to call */
void * volatile arg; /**< argument of function */
@@ -42,7 +42,7 @@ extern struct lcore_config lcore_config[RTE_MAX_LCORE];
* The global RTE configuration structure.
*/
struct rte_config {
- uint32_t master_lcore; /**< Id of the master lcore */
+ uint32_t main_lcore; /**< Id of the main lcore */
uint32_t lcore_count; /**< Number of available logical cores. */
uint32_t numa_node_count; /**< Number of detected NUMA nodes. */
uint32_t numa_nodes[RTE_MAX_NUMA_NODES]; /**< List of detected NUMA nodes. */
diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
index b2c5416b331d..ce21c2242a22 100644
--- a/lib/librte_eal/common/rte_random.c
+++ b/lib/librte_eal/common/rte_random.c
@@ -122,7 +122,7 @@ struct rte_rand_state *__rte_rand_get_state(void)
lcore_id = rte_lcore_id();
if (unlikely(lcore_id == LCORE_ID_ANY))
- lcore_id = rte_get_master_lcore();
+ lcore_id = rte_get_main_lcore();
return &rand_states[lcore_id];
}
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 98565bbef340..6c955d319ad4 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -107,7 +107,7 @@ rte_service_init(void)
struct rte_config *cfg = rte_eal_get_configuration();
for (i = 0; i < RTE_MAX_LCORE; i++) {
if (lcore_config[i].core_role == ROLE_SERVICE) {
- if ((unsigned int)i == cfg->master_lcore)
+ if ((unsigned int)i == cfg->main_lcore)
continue;
rte_service_lcore_add(i);
count++;
diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
index ccea60afe77b..d6ea02375025 100644
--- a/lib/librte_eal/freebsd/eal.c
+++ b/lib/librte_eal/freebsd/eal.c
@@ -625,10 +625,10 @@ eal_check_mem_on_local_socket(void)
int socket_id;
const struct rte_config *config = rte_eal_get_configuration();
- socket_id = rte_lcore_to_socket_id(config->master_lcore);
+ socket_id = rte_lcore_to_socket_id(config->main_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
- RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
+ RTE_LOG(WARNING, EAL, "WARNING: Main core has no memory on local socket!\n");
}
@@ -851,29 +851,29 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
if (pthread_setaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
- &lcore_config[config->master_lcore].cpuset) != 0) {
+ &lcore_config[config->main_lcore].cpuset) != 0) {
rte_eal_init_alert("Cannot set affinity");
rte_errno = EINVAL;
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%p;cpuset=[%s%s])\n",
- config->master_lcore, thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Main lcore %u is ready (tid=%p;cpuset=[%s%s])\n",
+ config->main_lcore, thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_main2worker) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_worker2main) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -886,7 +886,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-worker-%d", i);
rte_thread_setname(lcore_config[i].thread_id, thread_name);
ret = pthread_setaffinity_np(lcore_config[i].thread_id,
@@ -896,10 +896,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
/* initialize services so vdevs register service during bus_probe. */
diff --git a/lib/librte_eal/freebsd/eal_thread.c b/lib/librte_eal/freebsd/eal_thread.c
index 99b5fefc4c5b..1dce9b04f24a 100644
--- a/lib/librte_eal/freebsd/eal_thread.c
+++ b/lib/librte_eal/freebsd/eal_thread.c
@@ -26,35 +26,35 @@
#include "eal_thread.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
+rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
int rc = -EBUSY;
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
goto finish;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
+ n = write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = read(s2m, &c, 1);
+ n = read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -62,7 +62,7 @@ rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
rc = 0;
finish:
- rte_eal_trace_thread_remote_launch(f, arg, slave_id, rc);
+ rte_eal_trace_thread_remote_launch(f, arg, worker_id, rc);
return rc;
}
@@ -74,21 +74,21 @@ eal_thread_loop(__rte_unused void *arg)
int n, ret;
unsigned lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -104,7 +104,7 @@ eal_thread_loop(__rte_unused void *arg)
/* wait command */
do {
- n = read(m2s, &c, 1);
+ n = read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -115,7 +115,7 @@ eal_thread_loop(__rte_unused void *arg)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(s2m, &c, 1);
+ n = write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
diff --git a/lib/librte_eal/include/rte_eal.h b/lib/librte_eal/include/rte_eal.h
index e3c2ef185eed..0ae12cf4fbac 100644
--- a/lib/librte_eal/include/rte_eal.h
+++ b/lib/librte_eal/include/rte_eal.h
@@ -65,11 +65,11 @@ int rte_eal_iopl_init(void);
/**
* Initialize the Environment Abstraction Layer (EAL).
*
- * This function is to be executed on the MASTER lcore only, as soon
+ * This function is to be executed on the MAIN lcore only, as soon
* as possible in the application's main() function.
*
* The function finishes the initialization process before main() is called.
- * It puts the SLAVE lcores in the WAIT state.
+ * It puts the WORKER lcores in the WAIT state.
*
* When the multi-partition feature is supported, depending on the
* configuration (if CONFIG_RTE_EAL_MAIN_PARTITION is disabled), this
diff --git a/lib/librte_eal/include/rte_eal_trace.h b/lib/librte_eal/include/rte_eal_trace.h
index 19df549d29be..495ae1ee1d61 100644
--- a/lib/librte_eal/include/rte_eal_trace.h
+++ b/lib/librte_eal/include/rte_eal_trace.h
@@ -264,10 +264,10 @@ RTE_TRACE_POINT(
RTE_TRACE_POINT(
rte_eal_trace_thread_remote_launch,
RTE_TRACE_POINT_ARGS(int (*f)(void *), void *arg,
- unsigned int slave_id, int rc),
+ unsigned int worker_id, int rc),
rte_trace_point_emit_ptr(f);
rte_trace_point_emit_ptr(arg);
- rte_trace_point_emit_u32(slave_id);
+ rte_trace_point_emit_u32(worker_id);
rte_trace_point_emit_int(rc);
)
RTE_TRACE_POINT(
diff --git a/lib/librte_eal/include/rte_launch.h b/lib/librte_eal/include/rte_launch.h
index 06a671752ace..22a901ce62f6 100644
--- a/lib/librte_eal/include/rte_launch.h
+++ b/lib/librte_eal/include/rte_launch.h
@@ -32,12 +32,12 @@ typedef int (lcore_function_t)(void *);
/**
* Launch a function on another lcore.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * Sends a message to a slave lcore (identified by the slave_id) that
+ * Sends a message to a worker lcore (identified by the worker_id) that
* is in the WAIT state (this is true after the first call to
* rte_eal_init()). This can be checked by first calling
- * rte_eal_wait_lcore(slave_id).
+ * rte_eal_wait_lcore(worker_id).
*
* When the remote lcore receives the message, it switches to
* the RUNNING state, then calls the function f with argument arg. Once the
@@ -45,7 +45,7 @@ typedef int (lcore_function_t)(void *);
* the return value of f is stored in a local variable to be read using
* rte_eal_wait_lcore().
*
- * The MASTER lcore returns as soon as the message is sent and knows
+ * The MAIN lcore returns as soon as the message is sent and knows
* nothing about the completion of f.
*
* Note: This function is not designed to offer optimum
@@ -56,37 +56,41 @@ typedef int (lcore_function_t)(void *);
* The function to be called.
* @param arg
* The argument for the function.
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore on which the function should be executed.
* @return
* - 0: Success. Execution of function f started on the remote lcore.
* - (-EBUSY): The remote lcore is not in a WAIT state.
*/
-int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned slave_id);
+int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned worker_id);
/**
- * This enum indicates whether the master core must execute the handler
+ * This enum indicates whether the main core must execute the handler
* launched on all logical cores.
*/
-enum rte_rmt_call_master_t {
- SKIP_MASTER = 0, /**< lcore handler not executed by master core. */
- CALL_MASTER, /**< lcore handler executed by master core. */
+enum rte_rmt_call_main_t {
+ SKIP_MAIN = 0, /**< lcore handler not executed by main core. */
+ CALL_MAIN, /**< lcore handler executed by main core. */
};
+/* These legacy definitions will be removed in future release */
+#define SKIP_MASTER RTE_DEPRECATED(SKIP_MASTER) SKIP_MAIN
+#define CALL_MASTER RTE_DEPRECATED(CALL_MASTER) CALL_MAIN
+
/**
* Launch a function on all lcores.
*
- * Check that each SLAVE lcore is in a WAIT state, then call
+ * Check that each WORKER lcore is in a WAIT state, then call
* rte_eal_remote_launch() for each lcore.
*
* @param f
* The function to be called.
* @param arg
* The argument for the function.
- * @param call_master
- * If call_master set to SKIP_MASTER, the MASTER lcore does not call
- * the function. If call_master is set to CALL_MASTER, the function
- * is also called on master before returning. In any case, the master
+ * @param call_main
+ * If call_main set to SKIP_MAIN, the MAIN lcore does not call
+ * the function. If call_main is set to CALL_MAIN, the function
+ * is also called on main before returning. In any case, the main
* lcore returns as soon as it finished its job and knows nothing
* about the completion of f on the other lcores.
* @return
@@ -95,49 +99,49 @@ enum rte_rmt_call_master_t {
* case, no message is sent to any of the lcores.
*/
int rte_eal_mp_remote_launch(lcore_function_t *f, void *arg,
- enum rte_rmt_call_master_t call_master);
+ enum rte_rmt_call_main_t call_main);
/**
- * Get the state of the lcore identified by slave_id.
+ * Get the state of the lcore identified by worker_id.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore.
* @return
* The state of the lcore.
*/
-enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned slave_id);
+enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned int worker_id);
/**
* Wait until an lcore finishes its job.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the MAIN lcore only.
*
- * If the slave lcore identified by the slave_id is in a FINISHED state,
+ * If the worker lcore identified by the worker_id is in a FINISHED state,
* switch to the WAIT state. If the lcore is in RUNNING state, wait until
* the lcore finishes its job and moves to the FINISHED state.
*
- * @param slave_id
+ * @param worker_id
* The identifier of the lcore.
* @return
- * - 0: If the lcore identified by the slave_id is in a WAIT state.
+ * - 0: If the lcore identified by the worker_id is in a WAIT state.
* - The value that was returned by the previous remote launch
- * function call if the lcore identified by the slave_id was in a
+ * function call if the lcore identified by the worker_id was in a
* FINISHED or RUNNING state. In this case, it changes the state
* of the lcore to WAIT.
*/
-int rte_eal_wait_lcore(unsigned slave_id);
+int rte_eal_wait_lcore(unsigned worker_id);
/**
* Wait until all lcores finish their jobs.
*
- * To be executed on the MASTER lcore only. Issue an
+ * To be executed on the MAIN lcore only. Issue an
* rte_eal_wait_lcore() for every lcore. The return values are
* ignored.
*
* After a call to rte_eal_mp_wait_lcore(), the caller can assume
- * that all slave lcores are in a WAIT state.
+ * that all worker lcores are in a WAIT state.
*/
void rte_eal_mp_wait_lcore(void);
diff --git a/lib/librte_eal/include/rte_lcore.h b/lib/librte_eal/include/rte_lcore.h
index b8b64a625200..48b87e253afa 100644
--- a/lib/librte_eal/include/rte_lcore.h
+++ b/lib/librte_eal/include/rte_lcore.h
@@ -78,12 +78,24 @@ rte_lcore_id(void)
}
/**
- * Get the id of the master lcore
+ * Get the id of the main lcore
*
* @return
- * the id of the master lcore
+ * the id of the main lcore
*/
-unsigned int rte_get_master_lcore(void);
+unsigned int rte_get_main_lcore(void);
+
+/**
+ * Deprecated function the id of the main lcore
+ *
+ * @return
+ * the id of the main lcore
+ */
+__rte_deprecated
+static inline unsigned int rte_get_master_lcore(void)
+{
+ return rte_get_main_lcore();
+}
/**
* Return the number of execution units (lcores) on the system.
@@ -203,32 +215,35 @@ int rte_lcore_is_enabled(unsigned int lcore_id);
*
* @param i
* The current lcore (reference).
- * @param skip_master
- * If true, do not return the ID of the master lcore.
+ * @param skip_main
+ * If true, do not return the ID of the main lcore.
* @param wrap
* If true, go back to 0 when RTE_MAX_LCORE is reached; otherwise,
* return RTE_MAX_LCORE.
* @return
* The next lcore_id or RTE_MAX_LCORE if not found.
*/
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap);
+unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap);
/**
* Macro to browse all running lcores.
*/
#define RTE_LCORE_FOREACH(i) \
for (i = rte_get_next_lcore(-1, 0, 0); \
- i<RTE_MAX_LCORE; \
+ i < RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 0, 0))
/**
- * Macro to browse all running lcores except the master lcore.
+ * Macro to browse all running lcores except the main lcore.
*/
-#define RTE_LCORE_FOREACH_SLAVE(i) \
+#define RTE_LCORE_FOREACH_WORKER(i) \
for (i = rte_get_next_lcore(-1, 1, 0); \
- i<RTE_MAX_LCORE; \
+ i < RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 1, 0))
+#define RTE_LCORE_FOREACH_SLAVE(l) \
+ RTE_DEPRECATED(RTE_LCORE_FOREACH_SLAVE) RTE_LCORE_FOREACH_WORKER(l)
+
/**
* Callback prototype for initializing lcores.
*
diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
index 9cf0e2ec0137..1c9dd8db1e6a 100644
--- a/lib/librte_eal/linux/eal.c
+++ b/lib/librte_eal/linux/eal.c
@@ -883,10 +883,10 @@ eal_check_mem_on_local_socket(void)
int socket_id;
const struct rte_config *config = rte_eal_get_configuration();
- socket_id = rte_lcore_to_socket_id(config->master_lcore);
+ socket_id = rte_lcore_to_socket_id(config->main_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
- RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
+ RTE_LOG(WARNING, EAL, "WARNING: Main core has no memory on local socket!\n");
}
static int
@@ -1215,28 +1215,28 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
if (pthread_setaffinity_np(pthread_self(), sizeof(rte_cpuset_t),
- &lcore_config[config->master_lcore].cpuset) != 0) {
+ &lcore_config[config->main_lcore].cpuset) != 0) {
rte_eal_init_alert("Cannot set affinity");
rte_errno = EINVAL;
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
ret = eal_thread_dump_current_affinity(cpuset, sizeof(cpuset));
- RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
- config->master_lcore, (uintptr_t)thread_id, cpuset,
+ RTE_LOG(DEBUG, EAL, "Main lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
+ config->main_lcore, (uintptr_t)thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_main2worker) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_worker2main) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -1249,7 +1249,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-worker-%d", i);
ret = rte_thread_setname(lcore_config[i].thread_id,
thread_name);
if (ret != 0)
@@ -1263,10 +1263,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
/* initialize services so vdevs register service during bus_probe. */
diff --git a/lib/librte_eal/linux/eal_memory.c b/lib/librte_eal/linux/eal_memory.c
index 89725291b0ce..3e47efe58212 100644
--- a/lib/librte_eal/linux/eal_memory.c
+++ b/lib/librte_eal/linux/eal_memory.c
@@ -1737,7 +1737,7 @@ memseg_primary_init_32(void)
/* the allocation logic is a little bit convoluted, but here's how it
* works, in a nutshell:
* - if user hasn't specified on which sockets to allocate memory via
- * --socket-mem, we allocate all of our memory on master core socket.
+ * --socket-mem, we allocate all of our memory on main core socket.
* - if user has specified sockets to allocate memory on, there may be
* some "unused" memory left (e.g. if user has specified --socket-mem
* such that not all memory adds up to 2 gigabytes), so add it to all
@@ -1751,7 +1751,7 @@ memseg_primary_init_32(void)
for (i = 0; i < rte_socket_count(); i++) {
int hp_sizes = (int) internal_conf->num_hugepage_sizes;
uint64_t max_socket_mem, cur_socket_mem;
- unsigned int master_lcore_socket;
+ unsigned int main_lcore_socket;
struct rte_config *cfg = rte_eal_get_configuration();
bool skip;
@@ -1767,10 +1767,10 @@ memseg_primary_init_32(void)
skip = active_sockets != 0 &&
internal_conf->socket_mem[socket_id] == 0;
/* ...or if we didn't specifically request memory on *any*
- * socket, and this is not master lcore
+ * socket, and this is not main lcore
*/
- master_lcore_socket = rte_lcore_to_socket_id(cfg->master_lcore);
- skip |= active_sockets == 0 && socket_id != master_lcore_socket;
+ main_lcore_socket = rte_lcore_to_socket_id(cfg->main_lcore);
+ skip |= active_sockets == 0 && socket_id != main_lcore_socket;
if (skip) {
RTE_LOG(DEBUG, EAL, "Will not preallocate memory on socket %u\n",
diff --git a/lib/librte_eal/linux/eal_thread.c b/lib/librte_eal/linux/eal_thread.c
index 068de2559555..83c2034b93d5 100644
--- a/lib/librte_eal/linux/eal_thread.c
+++ b/lib/librte_eal/linux/eal_thread.c
@@ -26,35 +26,35 @@
#include "eal_thread.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
+rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned int worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
int rc = -EBUSY;
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
goto finish;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
+ n = write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = read(s2m, &c, 1);
+ n = read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -62,7 +62,7 @@ rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
rc = 0;
finish:
- rte_eal_trace_thread_remote_launch(f, arg, slave_id, rc);
+ rte_eal_trace_thread_remote_launch(f, arg, worker_id, rc);
return rc;
}
@@ -74,21 +74,21 @@ eal_thread_loop(__rte_unused void *arg)
int n, ret;
unsigned lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -104,7 +104,7 @@ eal_thread_loop(__rte_unused void *arg)
/* wait command */
do {
- n = read(m2s, &c, 1);
+ n = read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -115,7 +115,7 @@ eal_thread_loop(__rte_unused void *arg)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = write(s2m, &c, 1);
+ n = write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index a93dea9fe616..33ee2748ede0 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -74,7 +74,7 @@ DPDK_21 {
rte_free;
rte_get_hpet_cycles;
rte_get_hpet_hz;
- rte_get_master_lcore;
+ rte_get_main_lcore;
rte_get_next_lcore;
rte_get_tsc_hz;
rte_hexdump;
diff --git a/lib/librte_eal/windows/eal.c b/lib/librte_eal/windows/eal.c
index bc48f27ab39a..cbca20956210 100644
--- a/lib/librte_eal/windows/eal.c
+++ b/lib/librte_eal/windows/eal.c
@@ -350,8 +350,8 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- __rte_thread_init(config->master_lcore,
- &lcore_config[config->master_lcore].cpuset);
+ __rte_thread_init(config->main_lcore,
+ &lcore_config[config->main_lcore].cpuset);
bscan = rte_bus_scan();
if (bscan < 0) {
@@ -360,16 +360,16 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_WORKER(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between main thread
* and children
*/
- if (_pipe(lcore_config[i].pipe_master2slave,
+ if (_pipe(lcore_config[i].pipe_main2worker,
sizeof(char), _O_BINARY) < 0)
rte_panic("Cannot create pipe\n");
- if (_pipe(lcore_config[i].pipe_slave2master,
+ if (_pipe(lcore_config[i].pipe_worker2main,
sizeof(char), _O_BINARY) < 0)
rte_panic("Cannot create pipe\n");
@@ -394,10 +394,10 @@ rte_eal_init(int argc, char **argv)
}
/*
- * Launch a dummy function on all slave lcores, so that master lcore
+ * Launch a dummy function on all worker lcores, so that main lcore
* knows they are all ready when this function returns.
*/
- rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
+ rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MAIN);
rte_eal_mp_wait_lcore();
return fctret;
}
diff --git a/lib/librte_eal/windows/eal_thread.c b/lib/librte_eal/windows/eal_thread.c
index 20889b6196c9..908e726d16cc 100644
--- a/lib/librte_eal/windows/eal_thread.c
+++ b/lib/librte_eal/windows/eal_thread.c
@@ -17,34 +17,34 @@
#include "eal_windows.h"
/*
- * Send a message to a slave lcore identified by slave_id to call a
+ * Send a message to a worker lcore identified by worker_id to call a
* function f with argument arg. Once the execution is done, the
* remote lcore switch in FINISHED state.
*/
int
-rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned int slave_id)
+rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned int worker_id)
{
int n;
char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
+ int m2w = lcore_config[worker_id].pipe_main2worker[1];
+ int w2m = lcore_config[worker_id].pipe_worker2main[0];
- if (lcore_config[slave_id].state != WAIT)
+ if (lcore_config[worker_id].state != WAIT)
return -EBUSY;
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
+ lcore_config[worker_id].f = f;
+ lcore_config[worker_id].arg = arg;
/* send message */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = _write(m2s, &c, 1);
+ n = _write(m2w, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
/* wait ack */
do {
- n = _read(s2m, &c, 1);
+ n = _read(w2m, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -61,21 +61,21 @@ eal_thread_loop(void *arg __rte_unused)
int n, ret;
unsigned int lcore_id;
pthread_t thread_id;
- int m2s, s2m;
+ int m2w, w2m;
char cpuset[RTE_CPU_AFFINITY_STR_LEN];
thread_id = pthread_self();
/* retrieve our lcore_id from the configuration structure */
- RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+ RTE_LCORE_FOREACH_WORKER(lcore_id) {
if (thread_id == lcore_config[lcore_id].thread_id)
break;
}
if (lcore_id == RTE_MAX_LCORE)
rte_panic("cannot retrieve lcore id\n");
- m2s = lcore_config[lcore_id].pipe_master2slave[0];
- s2m = lcore_config[lcore_id].pipe_slave2master[1];
+ m2w = lcore_config[lcore_id].pipe_main2worker[0];
+ w2m = lcore_config[lcore_id].pipe_worker2main[1];
__rte_thread_init(lcore_id, &lcore_config[lcore_id].cpuset);
@@ -88,7 +88,7 @@ eal_thread_loop(void *arg __rte_unused)
/* wait command */
do {
- n = _read(m2s, &c, 1);
+ n = _read(m2w, &c, 1);
} while (n < 0 && errno == EINTR);
if (n <= 0)
@@ -99,7 +99,7 @@ eal_thread_loop(void *arg __rte_unused)
/* send ack */
n = 0;
while (n == 0 || (n < 0 && errno == EINTR))
- n = _write(s2m, &c, 1);
+ n = _write(w2m, &c, 1);
if (n < 0)
rte_panic("cannot write on configuration pipe\n");
--
2.27.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v9 0/8] Enable dynamic config of subport bandwidth
2020-10-12 23:08 0% ` Dharmappa, Savinay
@ 2020-10-13 13:56 0% ` Dharmappa, Savinay
0 siblings, 0 replies; 200+ results
From: Dharmappa, Savinay @ 2020-10-13 13:56 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Dumitrescu, Cristian, Singh, Jasvinder, dev
-----Original Message-----
From: Dharmappa, Savinay
Sent: Tuesday, October 13, 2020 4:39 AM
To: 'Thomas Monjalon' <thomas@monjalon.net>
Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Singh, Jasvinder <jasvinder.singh@intel.com>; 'dev@dpdk.org' <dev@dpdk.org>
Subject: RE: [dpdk-dev] [PATCH v9 0/8] Enable dynamic config of subport bandwidth
09/10/2020 14:39, Savinay Dharmappa:
> DPDK sched library allows runtime configuration of the pipe profiles
> to the pipes of the subport once scheduler hierarchy is constructed.
> However, to change the subport level bandwidth, existing hierarchy
> needs to be dismantled and whole process of building hierarchy under
> subport nodes needs to be repeated which might result in router
> downtime. Furthermore, due to lack of dynamic configuration of the
> subport bandwidth profile configuration (shaper and Traffic class
> rates), the user application is unable to dynamically re-distribute
> the excess-bandwidth of one subport among other subports in the
> scheduler hierarchy. Therefore, it is also not possible to adjust the
> subport bandwidth profile in sync with dynamic changes in pipe
> profiles of subscribers who want to consume higher bandwidth opportunistically.
>
> This patch series implements dynamic configuration of the subport
> bandwidth profile to overcome the runtime situation when group of
> subscribers are not using the allotted bandwidth and dynamic bandwidth
> re-distribution is needed the without making any structural changes in the hierarchy.
>
> The implementation work includes refactoring the existing api and data
> structures defined for port and subport level, new APIs for adding
> subport level bandwidth profiles that can be used in runtime.
>
> ---
> v8 -> v9
> - updated ABI section in release notes.
> - Addressed review comments from patch 8
> of v8.
I was asking a question in my reply to v8 but you didn't hit the "reply" button.
>> sorry for that. All the question raised by you were relevant so I addressed them and sent out v9.
One more question: why don't you keep the ack given by Cristian in v7?
>> I am carrying ack given Cristian in v9, but It is at the bottom of cover letter.
>> should I resend the patch placing ack just before version changes info?
Hi Thomas,
Could you please let me know regarding resending the patch ?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
@ 2020-10-13 13:53 0% ` Kevin Traynor
2020-10-13 14:58 0% ` Michel Machado
2020-10-19 17:53 0% ` Honnappa Nagarahalli
1 sibling, 1 reply; 200+ results
From: Kevin Traynor @ 2020-10-13 13:53 UTC (permalink / raw)
To: Ruifeng Wang, Medvedkin, Vladimir, Bruce Richardson,
Michel Machado, Cody Doucette, Andre Nathan
Cc: dev, Honnappa Nagarahalli, nd
Hi Gatekeeper maintainers (I think),
fyi - there is a proposal to remove some members of a struct in DPDK LPM
API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but
as it's an LTS I guess it would probably hit Debian in a few months.
The full thread is here:
http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/
Maybe you can take a look and tell us if they are needed in Gatekeeper
or you can workaround it?
thanks,
Kevin.
[1]
https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248
On 09/10/2020 07:54, Ruifeng Wang wrote:
>
>> -----Original Message-----
>> From: Kevin Traynor <ktraynor@redhat.com>
>> Sent: Wednesday, September 30, 2020 4:46 PM
>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Medvedkin, Vladimir
>> <vladimir.medvedkin@intel.com>; Bruce Richardson
>> <bruce.richardson@intel.com>
>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data
>>
>> On 16/09/2020 04:17, Ruifeng Wang wrote:
>>>
>>>> -----Original Message-----
>>>> From: Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
>>>> Sent: Wednesday, September 16, 2020 12:28 AM
>>>> To: Bruce Richardson <bruce.richardson@intel.com>; Ruifeng Wang
>>>> <Ruifeng.Wang@arm.com>
>>>> Cc: dev@dpdk.org; Honnappa Nagarahalli
>>>> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
>>>> Subject: Re: [PATCH 2/2] lpm: hide internal data
>>>>
>>>> Hi Ruifeng,
>>>>
>>>> On 15/09/2020 17:02, Bruce Richardson wrote:
>>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote:
>>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to
>>>>>> be exposed to the user.
>>>>>> Hide the unneeded exposure of structure fields for better ABI
>>>>>> maintainability.
>>>>>>
>>>>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>>>>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>>>>>> Reviewed-by: Phil Yang <phil.yang@arm.com>
>>>>>> ---
>>>>>> lib/librte_lpm/rte_lpm.c | 152
>>>>>> +++++++++++++++++++++++---------------
>>>> -
>>>>>> lib/librte_lpm/rte_lpm.h | 7 --
>>>>>> 2 files changed, 91 insertions(+), 68 deletions(-)
>>>>>>
>>>>> <snip>
>>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
>>>>>> index 03da2d37e..112d96f37 100644
>>>>>> --- a/lib/librte_lpm/rte_lpm.h
>>>>>> +++ b/lib/librte_lpm/rte_lpm.h
>>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info {
>>>>>>
>>>>>> /** @internal LPM structure. */
>>>>>> struct rte_lpm {
>>>>>> - /* LPM metadata. */
>>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */
>>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */
>>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */
>>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**<
>>>> Rule info table. */
>>>>>> -
>>>>>> /* LPM Tables. */
>>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES]
>>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */
>>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */
>>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */
>>>>>> };
>>>>>>
>>>>>
>>>>> Since this changes the ABI, does it not need advance notice?
>>>>>
>>>>> [Basically the return value point from rte_lpm_create() will be
>>>>> different, and that return value could be used by rte_lpm_lookup()
>>>>> which as a static inline function will be in the binary and using
>>>>> the old structure offsets.]
>>>>>
>>>>
>>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted
>>>> without prior notice.
>>>>
>>> So if the change wants to happen in 20.11, a deprecation notice should
>>> have been added in 20.08.
>>> I should have added a deprecation notice. This change will have to wait for
>> next ABI update window.
>>>
>>
>> Do you plan to extend? or is this just speculative?
> It is speculative.
>
>>
>> A quick scan and there seems to be several projects using some of these
>> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS,
>> gatekeeper. I didn't look at the details to see if they are really needed.
>>
>> Not sure how much notice they'd need or if they update DPDK much, but I
>> think it's worth having a closer look as to how they use lpm and what the
>> impact to them is.
> Checked the projects listed above. BESS, NFF-Go and DPVS don't access the members to be hided.
> They will not be impacted by this patch.
> But Gatekeeper accesses the rte_lpm internal members that to be hided. Its compilation will be broken with this patch.
>
>>
>>> Thanks.
>>> Ruifeng
>>>>>> /** LPM RCU QSBR configuration structure. */
>>>>>> --
>>>>>> 2.17.1
>>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Vladimir
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 1/5] ethdev: add extensions attributes to IPv6 item
2020-10-13 13:32 3% ` [dpdk-dev] [PATCH v6 0/5] support match on L3 fragmented packets Dekel Peled
@ 2020-10-13 13:32 4% ` Dekel Peled
0 siblings, 0 replies; 200+ results
From: Dekel Peled @ 2020-10-13 13:32 UTC (permalink / raw)
To: orika, thomas, ferruh.yigit, arybchenko, konstantin.ananyev,
olivier.matz, wenzhuo.lu, beilei.xing, bernard.iremonger, matan,
shahafs, viacheslavo
Cc: dev
Using the current implementation of DPDK, an application cannot match on
IPv6 packets, based on the existing extension headers, in a simple way.
Field 'Next Header' in IPv6 header indicates type of the first extension
header only. Following extension headers can't be identified by
inspecting the IPv6 header.
As a result, the existence or absence of specific extension headers
can't be used for packet matching.
For example, fragmented IPv6 packets contain a dedicated extension header
(which is implemented in a later patch of this series).
Non-fragmented packets don't contain the fragment extension header.
For an application to match on non-fragmented IPv6 packets, the current
implementation doesn't provide a suitable solution.
Matching on the Next Header field is not sufficient, since additional
extension headers might be present in the same packet.
To match on fragmented IPv6 packets, the same difficulty exists.
This patch implements the update as detailed in RFC [1].
A set of additional values will be added to IPv6 header struct.
These values will indicate the existence of every defined extension
header type, providing simple means for identification of existing
extensions in the packet header.
Continuing the above example, fragmented packets can be identified using
the specific value indicating existence of fragment extension header.
To match on non-fragmented IPv6 packets, need to use has_frag_ext 0.
To match on fragmented IPv6 packets, need to use has_frag_ext 1.
To match on any IPv6 packets, the has_frag_ext field should
not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Signed-off-by: Dekel Peled <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
---
doc/guides/prog_guide/rte_flow.rst | 20 +++++++++++++++++---
doc/guides/rel_notes/release_20_11.rst | 5 +++++
lib/librte_ethdev/rte_flow.h | 23 +++++++++++++++++++++--
3 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 119b128..e0d7f42 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -946,11 +946,25 @@ Item: ``IPV6``
Matches an IPv6 header.
-Note: IPv6 options are handled by dedicated pattern items, see `Item:
-IPV6_EXT`_.
+Dedicated flags indicate if header contains specific extension headers.
+To match on packets containing a specific extension header, an application
+should match on the dedicated flag set to 1.
+To match on packets not containing a specific extension header, an application
+should match on the dedicated flag clear to 0.
+In case application doesn't care about the existence of a specific extension
+header, it should not specify the dedicated flag for matching.
- ``hdr``: IPv6 header definition (``rte_ip.h``).
-- Default ``mask`` matches source and destination addresses only.
+- ``has_hop_ext``: header contains Hop-by-Hop Options extension header.
+- ``has_route_ext``: header contains Routing extension header.
+- ``has_frag_ext``: header contains Fragment extension header.
+- ``has_auth_ext``: header contains Authentication extension header.
+- ``has_esp_ext``: header contains Encapsulation Security Payload extension header.
+- ``has_dest_ext``: header contains Destination Options extension header.
+- ``has_mobil_ext``: header contains Mobility extension header.
+- ``has_hip_ext``: header contains Host Identity Protocol extension header.
+- ``has_shim6_ext``: header contains Shim6 Protocol extension header.
+- Default ``mask`` matches ``hdr`` source and destination addresses only.
Item: ``ICMP``
^^^^^^^^^^^^^^
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index bcc0fc2..a01552c 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -314,6 +314,11 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+ * Added extensions' attributes to struct ``rte_flow_item_ipv6``.
+ A set of additional values added to struct, indicating the existence of
+ every defined extension header type.
+ Applications should use the new values for identification of existing
+ extensions in the packet header.
Known Issues
------------
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index da8bfa5..33d2e8f 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -792,11 +792,30 @@ struct rte_flow_item_ipv4 {
*
* Matches an IPv6 header.
*
- * Note: IPv6 options are handled by dedicated pattern items, see
- * RTE_FLOW_ITEM_TYPE_IPV6_EXT.
+ * Dedicated flags indicate if header contains specific extension headers.
*/
struct rte_flow_item_ipv6 {
struct rte_ipv6_hdr hdr; /**< IPv6 header definition. */
+ uint32_t has_hop_ext:1;
+ /**< Header contains Hop-by-Hop Options extension header. */
+ uint32_t has_route_ext:1;
+ /**< Header contains Routing extension header. */
+ uint32_t has_frag_ext:1;
+ /**< Header contains Fragment extension header. */
+ uint32_t has_auth_ext:1;
+ /**< Header contains Authentication extension header. */
+ uint32_t has_esp_ext:1;
+ /**< Header contains Encapsulation Security Payload extension header. */
+ uint32_t has_dest_ext:1;
+ /**< Header contains Destination Options extension header. */
+ uint32_t has_mobil_ext:1;
+ /**< Header contains Mobility extension header. */
+ uint32_t has_hip_ext:1;
+ /**< Header contains Host Identity Protocol extension header. */
+ uint32_t has_shim6_ext:1;
+ /**< Header contains Shim6 Protocol extension header. */
+ uint32_t reserved:23;
+ /**< Reserved for future extension headers, must be zero. */
};
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 0/5] support match on L3 fragmented packets
@ 2020-10-13 13:32 3% ` Dekel Peled
2020-10-13 13:32 4% ` [dpdk-dev] [PATCH v6 1/5] ethdev: add extensions attributes to IPv6 item Dekel Peled
1 sibling, 1 reply; 200+ results
From: Dekel Peled @ 2020-10-13 13:32 UTC (permalink / raw)
To: orika, thomas, ferruh.yigit, arybchenko, konstantin.ananyev,
olivier.matz, wenzhuo.lu, beilei.xing, bernard.iremonger, matan,
shahafs, viacheslavo
Cc: dev
This series implements support of matching on packets based on the
fragmentation attribute of the packet, i.e. if packet is a fragment
of a larger packet, or the opposite - packet is not a fragment.
In ethdev, add API to support IPv6 extension headers, and specifically
the IPv6 fragment extension header item.
Testpmd CLI is updated accordingly.
Documentation is updated accordingly.
---
v2: add patch 'net/mlx5: enforce limitation on IPv6 next proto'
v3: update patch 'ethdev: add IPv6 fragment extension header item' to avoid ABI breakage.
v4: update rte_flow documentation to clarify use of IPv6 extension header flags.
v5: update following rebase on recent ICMP changes.
v6: - move MLX5 PMD patches to separate series.
- rename IPv6 extension flags for clarity (e.g. frag_ext_exist renamed to has_frag_ext).
---
*** BLURB HERE ***
Dekel Peled (5):
ethdev: add extensions attributes to IPv6 item
ethdev: add IPv6 fragment extension header item
app/testpmd: support IPv4 fragments
app/testpmd: support IPv6 fragments
app/testpmd: support IPv6 fragment extension item
app/test-pmd/cmdline_flow.c | 53 ++++++++++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 32 ++++++++++++++++++--
doc/guides/rel_notes/release_20_11.rst | 5 ++++
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 43 +++++++++++++++++++++++++--
lib/librte_ip_frag/rte_ip_frag.h | 26 ++---------------
lib/librte_net/rte_ip.h | 26 +++++++++++++++--
7 files changed, 155 insertions(+), 31 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/1] lib/ring: add scatter gather APIs
2020-10-12 22:31 4% ` Honnappa Nagarahalli
@ 2020-10-13 11:38 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2020-10-13 11:38 UTC (permalink / raw)
To: Honnappa Nagarahalli, dev; +Cc: olivier.matz, david.marchand, nd, nd
Hi Honnappa,
> Hi Konstantin,
> Appreciate your feedback.
>
> <snip>
>
> >
> >
> > > Add scatter gather APIs to avoid intermediate memcpy. Use cases that
> > > involve copying large amount of data to/from the ring can benefit from
> > > these APIs.
> > >
> > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > ---
> > > lib/librte_ring/meson.build | 3 +-
> > > lib/librte_ring/rte_ring_elem.h | 1 +
> > > lib/librte_ring/rte_ring_peek_sg.h | 552
> > > +++++++++++++++++++++++++++++
> > > 3 files changed, 555 insertions(+), 1 deletion(-) create mode 100644
> > > lib/librte_ring/rte_ring_peek_sg.h
> >
> > As a generic one - need to update ring UT both func and perf to
> > test/measure this new API.
> Yes, will add.
>
> >
> > >
> > > diff --git a/lib/librte_ring/meson.build b/lib/librte_ring/meson.build
> > > index 31c0b4649..377694713 100644
> > > --- a/lib/librte_ring/meson.build
> > > +++ b/lib/librte_ring/meson.build
> > > @@ -12,4 +12,5 @@ headers = files('rte_ring.h',
> > > 'rte_ring_peek.h',
> > > 'rte_ring_peek_c11_mem.h',
> > > 'rte_ring_rts.h',
> > > - 'rte_ring_rts_c11_mem.h')
> > > + 'rte_ring_rts_c11_mem.h',
> > > + 'rte_ring_peek_sg.h')
> > > diff --git a/lib/librte_ring/rte_ring_elem.h
> > > b/lib/librte_ring/rte_ring_elem.h index 938b398fc..7d3933f15 100644
> > > --- a/lib/librte_ring/rte_ring_elem.h
> > > +++ b/lib/librte_ring/rte_ring_elem.h
> > > @@ -1079,6 +1079,7 @@ rte_ring_dequeue_burst_elem(struct rte_ring *r,
> > > void *obj_table,
> > >
> > > #ifdef ALLOW_EXPERIMENTAL_API
> > > #include <rte_ring_peek.h>
> > > +#include <rte_ring_peek_sg.h>
> > > #endif
> > >
> > > #include <rte_ring.h>
> > > diff --git a/lib/librte_ring/rte_ring_peek_sg.h
> > > b/lib/librte_ring/rte_ring_peek_sg.h
> > > new file mode 100644
> > > index 000000000..97d5764a6
> > > --- /dev/null
> > > +++ b/lib/librte_ring/rte_ring_peek_sg.h
> > > @@ -0,0 +1,552 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + *
> > > + * Copyright (c) 2020 Arm
> > > + * Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
> > > + * All rights reserved.
> > > + * Derived from FreeBSD's bufring.h
> > > + * Used as BSD-3 Licensed with permission from Kip Macy.
> > > + */
> > > +
> > > +#ifndef _RTE_RING_PEEK_SG_H_
> > > +#define _RTE_RING_PEEK_SG_H_
> > > +
> > > +/**
> > > + * @file
> > > + * @b EXPERIMENTAL: this API may change without prior notice
> > > + * It is not recommended to include this file directly.
> > > + * Please include <rte_ring_elem.h> instead.
> > > + *
> > > + * Ring Peek Scatter Gather APIs
> > > + * Introduction of rte_ring with scatter gather serialized
> > > +producer/consumer
> > > + * (HTS sync mode) makes it possible to split public enqueue/dequeue
> > > +API
> > > + * into 3 phases:
> > > + * - enqueue/dequeue start
> > > + * - copy data to/from the ring
> > > + * - enqueue/dequeue finish
> > > + * Along with the advantages of the peek APIs, these APIs provide the
> > > +ability
> > > + * to avoid copying of the data to temporary area.
> > > + *
> > > + * Note that right now this new API is available only for two sync modes:
> > > + * 1) Single Producer/Single Consumer (RTE_RING_SYNC_ST)
> > > + * 2) Serialized Producer/Serialized Consumer (RTE_RING_SYNC_MT_HTS).
> > > + * It is a user responsibility to create/init ring with appropriate
> > > +sync
> > > + * modes selected.
> > > + *
> > > + * Example usage:
> > > + * // read 1 elem from the ring:
> > > + * n = rte_ring_enqueue_sg_bulk_start(ring, 32, &sgd, NULL);
> > > + * if (n != 0) {
> > > + * //Copy objects in the ring
> > > + * memcpy (sgd->ptr1, obj, sgd->n1 * sizeof(uintptr_t));
> > > + * if (n != sgd->n1)
> > > + * //Second memcpy because of wrapround
> > > + * n2 = n - sgd->n1;
> > > + * memcpy (sgd->ptr2, obj[n2], n2 * sizeof(uintptr_t));
> > > + * rte_ring_dequeue_sg_finish(ring, n);
> >
> > It is not clear from the example above why do you need SG(ZC) API.
> > Existing peek API would be able to handle such situation (just copy will be
> > done internally). Probably better to use examples you provided in your last
> > reply to Olivier.
> Agree, not a good example, will change it.
>
> >
> > > + * }
> > > + *
> > > + * Note that between _start_ and _finish_ none other thread can
> > > + proceed
> > > + * with enqueue(/dequeue) operation till _finish_ completes.
> > > + */
> > > +
> > > +#ifdef __cplusplus
> > > +extern "C" {
> > > +#endif
> > > +
> > > +#include <rte_ring_peek_c11_mem.h>
> > > +
> > > +/* Rock that needs to be passed between reserve and commit APIs */
> > > +struct rte_ring_sg_data {
> > > + /* Pointer to the first space in the ring */
> > > + void **ptr1;
> > > + /* Pointer to the second space in the ring if there is wrap-around */
> > > + void **ptr2;
> > > + /* Number of elements in the first pointer. If this is equal to
> > > + * the number of elements requested, then ptr2 is NULL.
> > > + * Otherwise, subtracting n1 from number of elements requested
> > > + * will give the number of elements available at ptr2.
> > > + */
> > > + unsigned int n1;
> > > +};
> >
> > I wonder what is the primary goal of that API?
> > The reason I am asking: from what I understand with this patch ZC API will
> > work only for ST and HTS modes (same as peek API).
> > Though, I think it is possible to make it work for any sync model, by changing
> Agree, the functionality can be extended to other modes as well. I added these 2 modes as I found the use cases for these.
>
> > API a bit: instead of returning sg_data to the user, force him to provide
> > function to read/write elems from/to the ring.
> > Just a schematic one, to illustrate the idea:
> >
> > typedef void (*write_ring_func_t)(void *elem, /*pointer to first elem to
> > update inside the ring*/
> > uint32_t num, /* number of elems to update
> > */
> > uint32_t esize,
> > void *udata /* caller provide data */);
> >
> > rte_ring_enqueue_zc_bulk_elem(struct rte_ring *r, unsigned int esize,
> > unsigned int n, unsigned int *free_space, write_ring_func_t wf, void
> > *udata) {
> > struct rte_ring_sg_data sgd;
> > .....
> > n = move_head_tail(r, ...);
> >
> > /* get sgd data based on n */
> > get_elem_addr(r, ..., &sgd);
> >
> > /* call user defined function to fill reserved elems */
> > wf(sgd.p1, sgd.n1, esize, udata);
> > if (n != n1)
> > wf(sgd.p2, sgd.n2, esize, udata);
> >
> > ....
> > return n;
> > }
> >
> I think the call back function makes it difficult to use the API. The call back function would be a wrapper around another function or API
> which will have its own arguments. Now all those parameters have to passed using the 'udata'. For ex: in the 2nd example that I provided
> earlier, the user has to create a wrapper around 'rte_eth_rx_burst' API and then provide the parameters to 'rte_eth_rx_burst' through
> 'udata'. 'udata' would need a structure definition as well.
Yes, it would, though I don't see much problems with that.
Let say for eth_rx_burst(), user will need something like struct {uint16_t p, q;} udata = {.p = port_id, .q=queue_id,};
>
> > If we want ZC peek API also - some extra work need to be done with
> > introducing return value for write_ring_func() and checking it properly, but I
> > don't see any big problems here too.
> > That way ZC API can support all sync models, plus we don't need to expose
> > sg_data to the user directly.
> Other modes can be supported with the method used in this patch as well.
You mean via exposing to the user tail value (in sg_data or so)?
I am still a bit nervous about doing that.
> If you see a need, I can add them.
Not, really, I just thought callbacks will be a good idea here...
> IMO, only issue with exposing sg_data is ABI compatibility in the future. I think, we can align the 'struct rte_ring_sg_data' to cache line
> boundary and it should provide ability to extend it in the future without affecting the ABI compatibility.
As I understand sg_data is experimental struct (as the rest of API in that file).
So breaking it shouldn't be a problem for a while.
I suppose to summarize things - as I understand you think callback approach
is not a good choice.
From other hand, I am not really happy with idea to expose tail values updates
to the user.
Then I suggest we can just go ahead with that patch as it is:
sg_data approach, _ZC_ peek API only.
>
> > Also, in future, we probably can de-duplicate the code by making our non-ZC
> > API to use that one internally (pass ring_enqueue_elems()/ob_table as a
> > parameters).
> >
> > > +
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] security: update session create API
@ 2020-10-13 2:12 0% ` Lukasz Wojciechowski
2020-10-14 18:56 2% ` [dpdk-dev] [PATCH v3] " Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Lukasz Wojciechowski @ 2020-10-13 2:12 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, mdr, anoobj, hemant.agrawal, konstantin.ananyev,
declan.doherty, radu.nicolau, david.coyle,
"'Lukasz Wojciechowski'",
Hi Akhil,
comments inline
W dniu 11.10.2020 o 00:11, Akhil Goyal pisze:
> The API ``rte_security_session_create`` takes only single
> mempool for session and session private data. So the
> application need to create mempool for twice the number of
> sessions needed and will also lead to wastage of memory as
> session private data need more memory compared to session.
> Hence the API is modified to take two mempool pointers
> - one for session and one for private data.
> This is very similar to crypto based session create APIs.
>
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
>
> Changes in V2:
> incorporated comments from Lukasz and David.
>
> app/test-crypto-perf/cperf_ops.c | 4 +-
> app/test-crypto-perf/main.c | 12 +++--
> app/test/test_cryptodev.c | 18 ++++++--
> app/test/test_ipsec.c | 3 +-
> app/test/test_security.c | 61 ++++++++++++++++++++------
> doc/guides/prog_guide/rte_security.rst | 8 +++-
> doc/guides/rel_notes/deprecation.rst | 7 ---
> doc/guides/rel_notes/release_20_11.rst | 6 +++
> examples/ipsec-secgw/ipsec-secgw.c | 12 +----
> examples/ipsec-secgw/ipsec.c | 9 ++--
> lib/librte_security/rte_security.c | 7 ++-
> lib/librte_security/rte_security.h | 4 +-
> 12 files changed, 102 insertions(+), 49 deletions(-)
>
> diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
> index 3da835a9c..3a64a2c34 100644
> --- a/app/test-crypto-perf/cperf_ops.c
> +++ b/app/test-crypto-perf/cperf_ops.c
> @@ -621,7 +621,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
>
> /* Create security session */
> return (void *)rte_security_session_create(ctx,
> - &sess_conf, sess_mp);
> + &sess_conf, sess_mp, priv_mp);
> }
> if (options->op_type == CPERF_DOCSIS) {
> enum rte_security_docsis_direction direction;
> @@ -664,7 +664,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
>
> /* Create security session */
> return (void *)rte_security_session_create(ctx,
> - &sess_conf, priv_mp);
> + &sess_conf, sess_mp, priv_mp);
> }
> #endif
> sess = rte_cryptodev_sym_session_create(sess_mp);
> diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
> index 62ae6048b..53864ffdd 100644
> --- a/app/test-crypto-perf/main.c
> +++ b/app/test-crypto-perf/main.c
> @@ -156,7 +156,14 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
> if (sess_size > max_sess_size)
> max_sess_size = sess_size;
> }
> -
> +#ifdef RTE_LIBRTE_SECURITY
> + for (cdev_id = 0; cdev_id < rte_cryptodev_count(); cdev_id++) {
> + sess_size = rte_security_session_get_size(
> + rte_cryptodev_get_sec_ctx(cdev_id));
> + if (sess_size > max_sess_size)
> + max_sess_size = sess_size;
> + }
> +#endif
> /*
> * Calculate number of needed queue pairs, based on the amount
> * of available number of logical cores and crypto devices.
> @@ -247,8 +254,7 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
> opts->nb_qps * nb_slaves;
> #endif
> } else
> - sessions_needed = enabled_cdev_count *
> - opts->nb_qps * 2;
> + sessions_needed = enabled_cdev_count * opts->nb_qps;
>
> /*
> * A single session is required per queue pair
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> index ac2a36bc2..4bd9d8aff 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -553,9 +553,15 @@ testsuite_setup(void)
> unsigned int session_size =
> rte_cryptodev_sym_get_private_session_size(dev_id);
>
> +#ifdef RTE_LIBRTE_SECURITY
> + unsigned int security_session_size = rte_security_session_get_size(
> + rte_cryptodev_get_sec_ctx(dev_id));
> +
> + if (session_size < security_session_size)
> + session_size = security_session_size;
> +#endif
> /*
> - * Create mempool with maximum number of sessions * 2,
> - * to include the session headers
> + * Create mempool with maximum number of sessions.
> */
> if (info.sym.max_nb_sessions != 0 &&
> info.sym.max_nb_sessions < MAX_NB_SESSIONS) {
> @@ -7219,7 +7225,8 @@ test_pdcp_proto(int i, int oop,
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx,
> - &sess_conf, ts_params->session_priv_mpool);
> + &sess_conf, ts_params->session_mpool,
> + ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> printf("TestCase %s()-%d line %d failed %s: ",
> @@ -7479,7 +7486,8 @@ test_pdcp_proto_SGL(int i, int oop,
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx,
> - &sess_conf, ts_params->session_priv_mpool);
> + &sess_conf, ts_params->session_mpool,
> + ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> printf("TestCase %s()-%d line %d failed %s: ",
> @@ -7836,6 +7844,7 @@ test_docsis_proto_uplink(int i, struct docsis_test_data *d_td)
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
> + ts_params->session_mpool,
> ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> @@ -8011,6 +8020,7 @@ test_docsis_proto_downlink(int i, struct docsis_test_data *d_td)
>
> /* Create security session */
> ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
> + ts_params->session_mpool,
> ts_params->session_priv_mpool);
>
> if (!ut_params->sec_session) {
> diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
> index 79d00d7e0..9ad07a179 100644
> --- a/app/test/test_ipsec.c
> +++ b/app/test/test_ipsec.c
> @@ -632,7 +632,8 @@ create_dummy_sec_session(struct ipsec_unitest_params *ut,
> static struct rte_security_session_conf conf;
>
> ut->ss[j].security.ses = rte_security_session_create(&dummy_sec_ctx,
> - &conf, qp->mp_session_private);
> + &conf, qp->mp_session,
> + qp->mp_session_private);
>
> if (ut->ss[j].security.ses == NULL)
> return -ENOMEM;
> diff --git a/app/test/test_security.c b/app/test/test_security.c
> index 77fd5adc6..bf6a3e9de 100644
> --- a/app/test/test_security.c
> +++ b/app/test/test_security.c
> @@ -237,24 +237,25 @@ static struct mock_session_create_data {
> struct rte_security_session_conf *conf;
> struct rte_security_session *sess;
> struct rte_mempool *mp;
> + struct rte_mempool *priv_mp;
>
> int ret;
>
> int called;
> int failed;
> -} mock_session_create_exp = {NULL, NULL, NULL, NULL, 0, 0, 0};
> +} mock_session_create_exp = {NULL, NULL, NULL, NULL, NULL, 0, 0, 0};
>
> static int
> mock_session_create(void *device,
> struct rte_security_session_conf *conf,
> struct rte_security_session *sess,
> - struct rte_mempool *mp)
> + struct rte_mempool *priv_mp)
> {
> mock_session_create_exp.called++;
>
> MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, device);
> MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, conf);
> - MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, mp);
> + MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, priv_mp);
>
> mock_session_create_exp.sess = sess;
>
> @@ -502,6 +503,7 @@ struct rte_security_ops mock_ops = {
> */
> static struct security_testsuite_params {
> struct rte_mempool *session_mpool;
> + struct rte_mempool *session_priv_mpool;
> } testsuite_params = { NULL };
>
> /**
> @@ -524,7 +526,8 @@ static struct security_unittest_params {
> .sess = NULL,
> };
>
> -#define SECURITY_TEST_MEMPOOL_NAME "SecurityTestsMempoolName"
> +#define SECURITY_TEST_MEMPOOL_NAME "SecurityTestMp"
> +#define SECURITY_TEST_PRIV_MEMPOOL_NAME "SecurityTestPrivMp"
> #define SECURITY_TEST_MEMPOOL_SIZE 15
> #define SECURITY_TEST_SESSION_OBJECT_SIZE sizeof(struct rte_security_session)
>
> @@ -545,6 +548,22 @@ testsuite_setup(void)
> SOCKET_ID_ANY, 0);
> TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
> "Cannot create mempool %s\n", rte_strerror(rte_errno));
> +
> + ts_params->session_priv_mpool = rte_mempool_create(
> + SECURITY_TEST_PRIV_MEMPOOL_NAME,
> + SECURITY_TEST_MEMPOOL_SIZE,
> + rte_security_session_get_size(&unittest_params.ctx),
Call to rte_security_session_get_size() will cause a mockup function
mock_session_get_size() to be called, which will return 0.
Why do you call this function instead of defining some value for private
mempool element size?
> + 0, 0, NULL, NULL, NULL, NULL,
> + SOCKET_ID_ANY, 0);
> + if (ts_params->session_priv_mpool == NULL) {
> + printf("TestCase %s() line %d failed (null): "
> + "Cannot create priv mempool %s\n",
> + __func__, __LINE__, rte_strerror(rte_errno));
Instead of printf() use RTE_LOG(ERR, EAL,...). All other messages are
printed this way. It allows control of error messages if required.
> + rte_mempool_free(ts_params->session_mpool);
> + ts_params->session_mpool = NULL;
> + return TEST_FAILED;
> + }
> +
> return TEST_SUCCESS;
> }
>
> @@ -559,6 +578,10 @@ testsuite_teardown(void)
> rte_mempool_free(ts_params->session_mpool);
> ts_params->session_mpool = NULL;
> }
> + if (ts_params->session_priv_mpool) {
> + rte_mempool_free(ts_params->session_priv_mpool);
> + ts_params->session_priv_mpool = NULL;
> + }
> }
>
> /**
> @@ -659,7 +682,8 @@ ut_setup_with_session(void)
> mock_session_create_exp.ret = 0;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
> sess);
> TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
> @@ -701,7 +725,8 @@ test_session_create_inv_context(void)
> struct rte_security_session *sess;
>
> sess = rte_security_session_create(NULL, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> @@ -725,7 +750,8 @@ test_session_create_inv_context_ops(void)
> ut_params->ctx.ops = NULL;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> @@ -749,7 +775,8 @@ test_session_create_inv_context_ops_fun(void)
> ut_params->ctx.ops = &empty_ops;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> @@ -770,7 +797,8 @@ test_session_create_inv_configuration(void)
> struct rte_security_session *sess;
>
> sess = rte_security_session_create(&ut_params->ctx, NULL,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> @@ -781,7 +809,7 @@ test_session_create_inv_configuration(void)
> }
>
> /**
> - * Test execution of rte_security_session_create with NULL mp parameter
> + * Test execution of rte_security_session_create with NULL mempools
> */
> static int
> test_session_create_inv_mempool(void)
> @@ -790,7 +818,7 @@ test_session_create_inv_mempool(void)
> struct rte_security_session *sess;
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - NULL);
> + NULL, NULL);
It would be best to add a new testcase for verification of passing NULL
private mempool.
If you pass NULL as the primary mempool as in this testcase, the
verification of priv mempool (rte_securitry.c:37) won't ever happen
because rte_security_session_create() will return in line 36.
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> @@ -824,7 +852,8 @@ test_session_create_mempool_empty(void)
> TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
> @@ -853,10 +882,12 @@ test_session_create_ops_failure(void)
> mock_session_create_exp.device = NULL;
> mock_session_create_exp.conf = &ut_params->conf;
> mock_session_create_exp.mp = ts_params->session_mpool;
> + mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
> mock_session_create_exp.ret = -1; /* Return failure status. */
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
> sess, NULL, "%p");
> TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
> @@ -879,10 +910,12 @@ test_session_create_success(void)
> mock_session_create_exp.device = NULL;
> mock_session_create_exp.conf = &ut_params->conf;
> mock_session_create_exp.mp = ts_params->session_mpool;
> + mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
> mock_session_create_exp.ret = 0; /* Return success status. */
>
> sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
> - ts_params->session_mpool);
> + ts_params->session_mpool,
> + ts_params->session_priv_mpool);
> TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
> sess);
> TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
> diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
> index 127da2e4f..fdb469d5f 100644
> --- a/doc/guides/prog_guide/rte_security.rst
> +++ b/doc/guides/prog_guide/rte_security.rst
> @@ -533,8 +533,12 @@ and this allows further acceleration of the offload of Crypto workloads.
>
> The Security framework provides APIs to create and free sessions for crypto/ethernet
> devices, where sessions are mempool objects. It is the application's responsibility
> -to create and manage the session mempools. The mempool object size should be able to
> -accommodate the driver's private data of security session.
> +to create and manage two session mempools - one for session and other for session
> +private data. The private session data mempool object size should be able to
> +accommodate the driver's private data of security session. The application can get
> +the size of session private data using API ``rte_security_session_get_size``.
> +And the session mempool object size should be enough to accomodate
> +``rte_security_session``.
>
> Once the session mempools have been created, ``rte_security_session_create()``
> is used to allocate and initialize a session for the required crypto/ethernet device.
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 52f413e21..d956a76e7 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -164,13 +164,6 @@ Deprecation Notices
> following the IPv6 header, as proposed in RFC
> https://protect2.fireeye.com/v1/url?k=6c464261-31d8d98b-6c47c92e-0cc47a6cba04-7bff9381095a3baf&q=1&e=1d514a47-c7a4-4d29-b9af-8fe8863e27eb&u=https%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2020-August%2F177257.html.
>
> -* security: The API ``rte_security_session_create`` takes only single mempool
> - for session and session private data. So the application need to create
> - mempool for twice the number of sessions needed and will also lead to
> - wastage of memory as session private data need more memory compared to session.
> - Hence the API will be modified to take two mempool pointers - one for session
> - and one for private data.
> -
> * cryptodev: ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum rte_crypto_aead_algorithm``,
> ``RTE_CRYPTO_CIPHER_LIST_END`` from ``enum rte_crypto_cipher_algorithm`` and
> ``RTE_CRYPTO_AUTH_LIST_END`` from ``enum rte_crypto_auth_algorithm``
> diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
> index c34ab5493..68b82ae4e 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -307,6 +307,12 @@ API Changes
> ``rte_fpga_lte_fec_configure`` and structure ``fpga_lte_fec_conf`` to
> ``rte_fpga_lte_fec_conf``.
>
> +* security: The API ``rte_security_session_create`` is updated to take two
> + mempool objects one for session and other for session private data.
> + So the application need to create two mempools and get the size of session
> + private data using API ``rte_security_session_get_size`` for private session
> + mempool.
> +
>
> ABI Changes
> -----------
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> index 60132c4bd..2326089bb 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -2348,12 +2348,8 @@ session_pool_init(struct socket_ctx *ctx, int32_t socket_id, size_t sess_sz)
>
> snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
> "sess_mp_%u", socket_id);
> - /*
> - * Doubled due to rte_security_session_create() uses one mempool for
> - * session and for session private data.
> - */
> nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
> - rte_lcore_count()) * 2;
> + rte_lcore_count());
> sess_mp = rte_cryptodev_sym_session_pool_create(
> mp_name, nb_sess, sess_sz, CDEV_MP_CACHE_SZ, 0,
> socket_id);
> @@ -2376,12 +2372,8 @@ session_priv_pool_init(struct socket_ctx *ctx, int32_t socket_id,
>
> snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
> "sess_mp_priv_%u", socket_id);
> - /*
> - * Doubled due to rte_security_session_create() uses one mempool for
> - * session and for session private data.
> - */
> nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
> - rte_lcore_count()) * 2;
> + rte_lcore_count());
> sess_mp = rte_mempool_create(mp_name,
> nb_sess,
> sess_sz,
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 01faa7ac7..6baeeb342 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -117,7 +117,8 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
> set_ipsec_conf(sa, &(sess_conf.ipsec));
>
> ips->security.ses = rte_security_session_create(ctx,
> - &sess_conf, ipsec_ctx->session_priv_pool);
> + &sess_conf, ipsec_ctx->session_pool,
> + ipsec_ctx->session_priv_pool);
> if (ips->security.ses == NULL) {
> RTE_LOG(ERR, IPSEC,
> "SEC Session init failed: err: %d\n", ret);
> @@ -198,7 +199,8 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> }
>
> ips->security.ses = rte_security_session_create(sec_ctx,
> - &sess_conf, skt_ctx->session_pool);
> + &sess_conf, skt_ctx->session_pool,
> + skt_ctx->session_priv_pool);
> if (ips->security.ses == NULL) {
> RTE_LOG(ERR, IPSEC,
> "SEC Session init failed: err: %d\n", ret);
> @@ -378,7 +380,8 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
> sess_conf.userdata = (void *) sa;
>
> ips->security.ses = rte_security_session_create(sec_ctx,
> - &sess_conf, skt_ctx->session_pool);
> + &sess_conf, skt_ctx->session_pool,
> + skt_ctx->session_priv_pool);
> if (ips->security.ses == NULL) {
> RTE_LOG(ERR, IPSEC,
> "SEC Session init failed: err: %d\n", ret);
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 515c29e04..ee4666026 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -26,18 +26,21 @@
> struct rte_security_session *
> rte_security_session_create(struct rte_security_ctx *instance,
> struct rte_security_session_conf *conf,
> - struct rte_mempool *mp)
> + struct rte_mempool *mp,
> + struct rte_mempool *priv_mp)
> {
> struct rte_security_session *sess = NULL;
>
> RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_create, NULL, NULL);
> RTE_PTR_OR_ERR_RET(conf, NULL);
> RTE_PTR_OR_ERR_RET(mp, NULL);
> + RTE_PTR_OR_ERR_RET(priv_mp, NULL);
>
> if (rte_mempool_get(mp, (void **)&sess))
> return NULL;
>
> - if (instance->ops->session_create(instance->device, conf, sess, mp)) {
> + if (instance->ops->session_create(instance->device, conf,
> + sess, priv_mp)) {
> rte_mempool_put(mp, (void *)sess);
> return NULL;
> }
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 16839e539..1710cdd6a 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -386,6 +386,7 @@ struct rte_security_session {
> * @param instance security instance
> * @param conf session configuration parameters
> * @param mp mempool to allocate session objects from
> + * @param priv_mp mempool to allocate session private data objects from
> * @return
> * - On success, pointer to session
> * - On failure, NULL
> @@ -393,7 +394,8 @@ struct rte_security_session {
> struct rte_security_session *
> rte_security_session_create(struct rte_security_ctx *instance,
> struct rte_security_session_conf *conf,
> - struct rte_mempool *mp);
> + struct rte_mempool *mp,
> + struct rte_mempool *priv_mp);
>
> /**
> * Update security session as specified by the session configuration
Best regards
Lukasz
--
Lukasz Wojciechowski
Principal Software Engineer
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v9 0/8] Enable dynamic config of subport bandwidth
@ 2020-10-12 23:08 0% ` Dharmappa, Savinay
2020-10-13 13:56 0% ` Dharmappa, Savinay
0 siblings, 1 reply; 200+ results
From: Dharmappa, Savinay @ 2020-10-12 23:08 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Dumitrescu, Cristian, Singh, Jasvinder, dev
09/10/2020 14:39, Savinay Dharmappa:
> DPDK sched library allows runtime configuration of the pipe profiles
> to the pipes of the subport once scheduler hierarchy is constructed.
> However, to change the subport level bandwidth, existing hierarchy
> needs to be dismantled and whole process of building hierarchy under
> subport nodes needs to be repeated which might result in router
> downtime. Furthermore, due to lack of dynamic configuration of the
> subport bandwidth profile configuration (shaper and Traffic class
> rates), the user application is unable to dynamically re-distribute
> the excess-bandwidth of one subport among other subports in the
> scheduler hierarchy. Therefore, it is also not possible to adjust the
> subport bandwidth profile in sync with dynamic changes in pipe
> profiles of subscribers who want to consume higher bandwidth opportunistically.
>
> This patch series implements dynamic configuration of the subport
> bandwidth profile to overcome the runtime situation when group of
> subscribers are not using the allotted bandwidth and dynamic bandwidth
> re-distribution is needed the without making any structural changes in the hierarchy.
>
> The implementation work includes refactoring the existing api and data
> structures defined for port and subport level, new APIs for adding
> subport level bandwidth profiles that can be used in runtime.
>
> ---
> v8 -> v9
> - updated ABI section in release notes.
> - Addressed review comments from patch 8
> of v8.
I was asking a question in my reply to v8 but you didn't hit the "reply" button.
>> sorry for that. All the question raised by you were relevant so I addressed them and sent out v9.
One more question: why don't you keep the ack given by Cristian in v7?
>> I am carrying ack given Cristian in v9, but It is at the bottom of cover letter.
>> should I resend the patch placing ack just before version changes info?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/1] lib/ring: add scatter gather APIs
@ 2020-10-12 22:31 4% ` Honnappa Nagarahalli
2020-10-13 11:38 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2020-10-12 22:31 UTC (permalink / raw)
To: Ananyev, Konstantin, dev
Cc: olivier.matz, david.marchand, nd, Honnappa Nagarahalli, nd
Hi Konstantin,
Appreciate your feedback.
<snip>
>
>
> > Add scatter gather APIs to avoid intermediate memcpy. Use cases that
> > involve copying large amount of data to/from the ring can benefit from
> > these APIs.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > ---
> > lib/librte_ring/meson.build | 3 +-
> > lib/librte_ring/rte_ring_elem.h | 1 +
> > lib/librte_ring/rte_ring_peek_sg.h | 552
> > +++++++++++++++++++++++++++++
> > 3 files changed, 555 insertions(+), 1 deletion(-) create mode 100644
> > lib/librte_ring/rte_ring_peek_sg.h
>
> As a generic one - need to update ring UT both func and perf to
> test/measure this new API.
Yes, will add.
>
> >
> > diff --git a/lib/librte_ring/meson.build b/lib/librte_ring/meson.build
> > index 31c0b4649..377694713 100644
> > --- a/lib/librte_ring/meson.build
> > +++ b/lib/librte_ring/meson.build
> > @@ -12,4 +12,5 @@ headers = files('rte_ring.h',
> > 'rte_ring_peek.h',
> > 'rte_ring_peek_c11_mem.h',
> > 'rte_ring_rts.h',
> > - 'rte_ring_rts_c11_mem.h')
> > + 'rte_ring_rts_c11_mem.h',
> > + 'rte_ring_peek_sg.h')
> > diff --git a/lib/librte_ring/rte_ring_elem.h
> > b/lib/librte_ring/rte_ring_elem.h index 938b398fc..7d3933f15 100644
> > --- a/lib/librte_ring/rte_ring_elem.h
> > +++ b/lib/librte_ring/rte_ring_elem.h
> > @@ -1079,6 +1079,7 @@ rte_ring_dequeue_burst_elem(struct rte_ring *r,
> > void *obj_table,
> >
> > #ifdef ALLOW_EXPERIMENTAL_API
> > #include <rte_ring_peek.h>
> > +#include <rte_ring_peek_sg.h>
> > #endif
> >
> > #include <rte_ring.h>
> > diff --git a/lib/librte_ring/rte_ring_peek_sg.h
> > b/lib/librte_ring/rte_ring_peek_sg.h
> > new file mode 100644
> > index 000000000..97d5764a6
> > --- /dev/null
> > +++ b/lib/librte_ring/rte_ring_peek_sg.h
> > @@ -0,0 +1,552 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + *
> > + * Copyright (c) 2020 Arm
> > + * Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
> > + * All rights reserved.
> > + * Derived from FreeBSD's bufring.h
> > + * Used as BSD-3 Licensed with permission from Kip Macy.
> > + */
> > +
> > +#ifndef _RTE_RING_PEEK_SG_H_
> > +#define _RTE_RING_PEEK_SG_H_
> > +
> > +/**
> > + * @file
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + * It is not recommended to include this file directly.
> > + * Please include <rte_ring_elem.h> instead.
> > + *
> > + * Ring Peek Scatter Gather APIs
> > + * Introduction of rte_ring with scatter gather serialized
> > +producer/consumer
> > + * (HTS sync mode) makes it possible to split public enqueue/dequeue
> > +API
> > + * into 3 phases:
> > + * - enqueue/dequeue start
> > + * - copy data to/from the ring
> > + * - enqueue/dequeue finish
> > + * Along with the advantages of the peek APIs, these APIs provide the
> > +ability
> > + * to avoid copying of the data to temporary area.
> > + *
> > + * Note that right now this new API is available only for two sync modes:
> > + * 1) Single Producer/Single Consumer (RTE_RING_SYNC_ST)
> > + * 2) Serialized Producer/Serialized Consumer (RTE_RING_SYNC_MT_HTS).
> > + * It is a user responsibility to create/init ring with appropriate
> > +sync
> > + * modes selected.
> > + *
> > + * Example usage:
> > + * // read 1 elem from the ring:
> > + * n = rte_ring_enqueue_sg_bulk_start(ring, 32, &sgd, NULL);
> > + * if (n != 0) {
> > + * //Copy objects in the ring
> > + * memcpy (sgd->ptr1, obj, sgd->n1 * sizeof(uintptr_t));
> > + * if (n != sgd->n1)
> > + * //Second memcpy because of wrapround
> > + * n2 = n - sgd->n1;
> > + * memcpy (sgd->ptr2, obj[n2], n2 * sizeof(uintptr_t));
> > + * rte_ring_dequeue_sg_finish(ring, n);
>
> It is not clear from the example above why do you need SG(ZC) API.
> Existing peek API would be able to handle such situation (just copy will be
> done internally). Probably better to use examples you provided in your last
> reply to Olivier.
Agree, not a good example, will change it.
>
> > + * }
> > + *
> > + * Note that between _start_ and _finish_ none other thread can
> > + proceed
> > + * with enqueue(/dequeue) operation till _finish_ completes.
> > + */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include <rte_ring_peek_c11_mem.h>
> > +
> > +/* Rock that needs to be passed between reserve and commit APIs */
> > +struct rte_ring_sg_data {
> > + /* Pointer to the first space in the ring */
> > + void **ptr1;
> > + /* Pointer to the second space in the ring if there is wrap-around */
> > + void **ptr2;
> > + /* Number of elements in the first pointer. If this is equal to
> > + * the number of elements requested, then ptr2 is NULL.
> > + * Otherwise, subtracting n1 from number of elements requested
> > + * will give the number of elements available at ptr2.
> > + */
> > + unsigned int n1;
> > +};
>
> I wonder what is the primary goal of that API?
> The reason I am asking: from what I understand with this patch ZC API will
> work only for ST and HTS modes (same as peek API).
> Though, I think it is possible to make it work for any sync model, by changing
Agree, the functionality can be extended to other modes as well. I added these 2 modes as I found the use cases for these.
> API a bit: instead of returning sg_data to the user, force him to provide
> function to read/write elems from/to the ring.
> Just a schematic one, to illustrate the idea:
>
> typedef void (*write_ring_func_t)(void *elem, /*pointer to first elem to
> update inside the ring*/
> uint32_t num, /* number of elems to update
> */
> uint32_t esize,
> void *udata /* caller provide data */);
>
> rte_ring_enqueue_zc_bulk_elem(struct rte_ring *r, unsigned int esize,
> unsigned int n, unsigned int *free_space, write_ring_func_t wf, void
> *udata) {
> struct rte_ring_sg_data sgd;
> .....
> n = move_head_tail(r, ...);
>
> /* get sgd data based on n */
> get_elem_addr(r, ..., &sgd);
>
> /* call user defined function to fill reserved elems */
> wf(sgd.p1, sgd.n1, esize, udata);
> if (n != n1)
> wf(sgd.p2, sgd.n2, esize, udata);
>
> ....
> return n;
> }
>
I think the call back function makes it difficult to use the API. The call back function would be a wrapper around another function or API which will have its own arguments. Now all those parameters have to passed using the 'udata'. For ex: in the 2nd example that I provided earlier, the user has to create a wrapper around 'rte_eth_rx_burst' API and then provide the parameters to 'rte_eth_rx_burst' through 'udata'. 'udata' would need a structure definition as well.
> If we want ZC peek API also - some extra work need to be done with
> introducing return value for write_ring_func() and checking it properly, but I
> don't see any big problems here too.
> That way ZC API can support all sync models, plus we don't need to expose
> sg_data to the user directly.
Other modes can be supported with the method used in this patch as well. If you see a need, I can add them.
IMO, only issue with exposing sg_data is ABI compatibility in the future. I think, we can align the 'struct rte_ring_sg_data' to cache line boundary and it should provide ability to extend it in the future without affecting the ABI compatibility.
> Also, in future, we probably can de-duplicate the code by making our non-ZC
> API to use that one internally (pass ring_enqueue_elems()/ob_table as a
> parameters).
>
> > +
> > +static __rte_always_inline void
> > +__rte_ring_get_elem_addr_64(struct rte_ring *r, uint32_t head,
> > + uint32_t num, void **dst1, uint32_t *n1, void **dst2) {
> > + uint32_t idx = head & r->mask;
> > + uint64_t *ring = (uint64_t *)&r[1];
> > +
> > + *dst1 = ring + idx;
> > + *n1 = num;
> > +
> > + if (idx + num > r->size) {
> > + *n1 = num - (r->size - idx - 1);
> > + *dst2 = ring;
> > + }
> > +}
> > +
> > +static __rte_always_inline void
> > +__rte_ring_get_elem_addr_128(struct rte_ring *r, uint32_t head,
> > + uint32_t num, void **dst1, uint32_t *n1, void **dst2) {
> > + uint32_t idx = head & r->mask;
> > + rte_int128_t *ring = (rte_int128_t *)&r[1];
> > +
> > + *dst1 = ring + idx;
> > + *n1 = num;
> > +
> > + if (idx + num > r->size) {
> > + *n1 = num - (r->size - idx - 1);
> > + *dst2 = ring;
> > + }
> > +}
> > +
> > +static __rte_always_inline void
> > +__rte_ring_get_elem_addr(struct rte_ring *r, uint32_t head,
> > + uint32_t esize, uint32_t num, void **dst1, uint32_t *n1, void
> > +**dst2) {
> > + if (esize == 8)
> > + __rte_ring_get_elem_addr_64(r, head,
> > + num, dst1, n1, dst2);
> > + else if (esize == 16)
> > + __rte_ring_get_elem_addr_128(r, head,
> > + num, dst1, n1, dst2);
>
>
> I don't think we need that special handling for 8/16B sizes.
> In all functions esize is an input parameter.
> If user will specify is as a constant - compiler will be able to convert multiply
> to shift and add ops.
Ok, I will check this out.
>
> > + else {
> > + uint32_t idx, scale, nr_idx;
> > + uint32_t *ring = (uint32_t *)&r[1];
> > +
> > + /* Normalize to uint32_t */
> > + scale = esize / sizeof(uint32_t);
> > + idx = head & r->mask;
> > + nr_idx = idx * scale;
> > +
> > + *dst1 = ring + nr_idx;
> > + *n1 = num;
> > +
> > + if (idx + num > r->size) {
> > + *n1 = num - (r->size - idx - 1);
> > + *dst2 = ring;
> > + }
> > + }
> > +}
> > +
> > +/**
> > + * @internal This function moves prod head value.
> > + */
> > +static __rte_always_inline unsigned int
> > +__rte_ring_do_enqueue_sg_elem_start(struct rte_ring *r, unsigned int
> esize,
> > + uint32_t n, enum rte_ring_queue_behavior behavior,
> > + struct rte_ring_sg_data *sgd, unsigned int *free_space) {
> > + uint32_t free, head, next;
> > +
> > + switch (r->prod.sync_type) {
> > + case RTE_RING_SYNC_ST:
> > + n = __rte_ring_move_prod_head(r, RTE_RING_SYNC_ST, n,
> > + behavior, &head, &next, &free);
> > + __rte_ring_get_elem_addr(r, head, esize, n, (void **)&sgd-
> >ptr1,
> > + &sgd->n1, (void **)&sgd->ptr2);
> > + break;
> > + case RTE_RING_SYNC_MT_HTS:
> > + n = __rte_ring_hts_move_prod_head(r, n, behavior, &head,
> &free);
> > + __rte_ring_get_elem_addr(r, head, esize, n, (void **)&sgd-
> >ptr1,
> > + &sgd->n1, (void **)&sgd->ptr2);
> > + break;
> > + case RTE_RING_SYNC_MT:
> > + case RTE_RING_SYNC_MT_RTS:
> > + default:
> > + /* unsupported mode, shouldn't be here */
> > + RTE_ASSERT(0);
> > + n = 0;
> > + free = 0;
> > + }
> > +
> > + if (free_space != NULL)
> > + *free_space = free - n;
> > + return n;
> > +}
> > +
> > +/**
> > + * Start to enqueue several objects on the ring.
> > + * Note that no actual objects are put in the queue by this function,
> > + * it just reserves space for the user on the ring.
> > + * User has to copy objects into the queue using the returned pointers.
> > + * User should call rte_ring_enqueue_sg_bulk_elem_finish to complete
> > +the
> > + * enqueue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param esize
> > + * The size of ring element, in bytes. It must be a multiple of 4.
> > + * @param n
> > + * The number of objects to add in the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param free_space
> > + * if non-NULL, returns the amount of space in the ring after the
> > + * reservation operation has finished.
> > + * @return
> > + * The number of objects that can be enqueued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_enqueue_sg_bulk_elem_start(struct rte_ring *r, unsigned int
> esize,
> > + unsigned int n, struct rte_ring_sg_data *sgd, unsigned int
> > +*free_space) {
> > + return __rte_ring_do_enqueue_sg_elem_start(r, esize, n,
> > + RTE_RING_QUEUE_FIXED, sgd, free_space); }
> > +
> > +/**
> > + * Start to enqueue several pointers to objects on the ring.
> > + * Note that no actual pointers are put in the queue by this
> > +function,
> > + * it just reserves space for the user on the ring.
> > + * User has to copy pointers to objects into the queue using the
> > + * returned pointers.
> > + * User should call rte_ring_enqueue_sg_bulk_finish to complete the
> > + * enqueue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to add in the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param free_space
> > + * if non-NULL, returns the amount of space in the ring after the
> > + * reservation operation has finished.
> > + * @return
> > + * The number of objects that can be enqueued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_enqueue_sg_bulk_start(struct rte_ring *r, unsigned int n,
> > + struct rte_ring_sg_data *sgd, unsigned int *free_space) {
> > + return rte_ring_enqueue_sg_bulk_elem_start(r, sizeof(uintptr_t), n,
> > + sgd, free_space);
> > +}
> > +/**
> > + * Start to enqueue several objects on the ring.
> > + * Note that no actual objects are put in the queue by this function,
> > + * it just reserves space for the user on the ring.
> > + * User has to copy objects into the queue using the returned pointers.
> > + * User should call rte_ring_enqueue_sg_bulk_elem_finish to complete
> > +the
> > + * enqueue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param esize
> > + * The size of ring element, in bytes. It must be a multiple of 4.
> > + * @param n
> > + * The number of objects to add in the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param free_space
> > + * if non-NULL, returns the amount of space in the ring after the
> > + * reservation operation has finished.
> > + * @return
> > + * The number of objects that can be enqueued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_enqueue_sg_burst_elem_start(struct rte_ring *r, unsigned int
> esize,
> > + unsigned int n, struct rte_ring_sg_data *sgd, unsigned int
> > +*free_space) {
> > + return __rte_ring_do_enqueue_sg_elem_start(r, esize, n,
> > + RTE_RING_QUEUE_VARIABLE, sgd, free_space); }
> > +
> > +/**
> > + * Start to enqueue several pointers to objects on the ring.
> > + * Note that no actual pointers are put in the queue by this
> > +function,
> > + * it just reserves space for the user on the ring.
> > + * User has to copy pointers to objects into the queue using the
> > + * returned pointers.
> > + * User should call rte_ring_enqueue_sg_bulk_finish to complete the
> > + * enqueue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to add in the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param free_space
> > + * if non-NULL, returns the amount of space in the ring after the
> > + * reservation operation has finished.
> > + * @return
> > + * The number of objects that can be enqueued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_enqueue_sg_burst_start(struct rte_ring *r, unsigned int n,
> > + struct rte_ring_sg_data *sgd, unsigned int *free_space) {
> > + return rte_ring_enqueue_sg_burst_elem_start(r, sizeof(uintptr_t),
> n,
> > + sgd, free_space);
> > +}
> > +
> > +/**
> > + * Complete enqueuing several objects on the ring.
> > + * Note that number of objects to enqueue should not exceed previous
> > + * enqueue_start return value.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to add to the ring.
> > + */
> > +__rte_experimental
> > +static __rte_always_inline void
> > +rte_ring_enqueue_sg_elem_finish(struct rte_ring *r, unsigned int n) {
> > + uint32_t tail;
> > +
> > + switch (r->prod.sync_type) {
> > + case RTE_RING_SYNC_ST:
> > + n = __rte_ring_st_get_tail(&r->prod, &tail, n);
> > + __rte_ring_st_set_head_tail(&r->prod, tail, n, 1);
> > + break;
> > + case RTE_RING_SYNC_MT_HTS:
> > + n = __rte_ring_hts_get_tail(&r->hts_prod, &tail, n);
> > + __rte_ring_hts_set_head_tail(&r->hts_prod, tail, n, 1);
> > + break;
> > + case RTE_RING_SYNC_MT:
> > + case RTE_RING_SYNC_MT_RTS:
> > + default:
> > + /* unsupported mode, shouldn't be here */
> > + RTE_ASSERT(0);
> > + }
> > +}
> > +
> > +/**
> > + * Complete enqueuing several pointers to objects on the ring.
> > + * Note that number of objects to enqueue should not exceed previous
> > + * enqueue_start return value.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of pointers to objects to add to the ring.
> > + */
> > +__rte_experimental
> > +static __rte_always_inline void
> > +rte_ring_enqueue_sg_finish(struct rte_ring *r, unsigned int n) {
> > + rte_ring_enqueue_sg_elem_finish(r, n); }
> > +
> > +/**
> > + * @internal This function moves cons head value and copies up to *n*
> > + * objects from the ring to the user provided obj_table.
> > + */
> > +static __rte_always_inline unsigned int
> > +__rte_ring_do_dequeue_sg_elem_start(struct rte_ring *r,
> > + uint32_t esize, uint32_t n, enum rte_ring_queue_behavior behavior,
> > + struct rte_ring_sg_data *sgd, unsigned int *available) {
> > + uint32_t avail, head, next;
> > +
> > + switch (r->cons.sync_type) {
> > + case RTE_RING_SYNC_ST:
> > + n = __rte_ring_move_cons_head(r, RTE_RING_SYNC_ST, n,
> > + behavior, &head, &next, &avail);
> > + __rte_ring_get_elem_addr(r, head, esize, n,
> > + sgd->ptr1, &sgd->n1, sgd->ptr2);
> > + break;
> > + case RTE_RING_SYNC_MT_HTS:
> > + n = __rte_ring_hts_move_cons_head(r, n, behavior,
> > + &head, &avail);
> > + __rte_ring_get_elem_addr(r, head, esize, n,
> > + sgd->ptr1, &sgd->n1, sgd->ptr2);
> > + break;
> > + case RTE_RING_SYNC_MT:
> > + case RTE_RING_SYNC_MT_RTS:
> > + default:
> > + /* unsupported mode, shouldn't be here */
> > + RTE_ASSERT(0);
> > + n = 0;
> > + avail = 0;
> > + }
> > +
> > + if (available != NULL)
> > + *available = avail - n;
> > + return n;
> > +}
> > +
> > +/**
> > + * Start to dequeue several objects from the ring.
> > + * Note that no actual objects are copied from the queue by this function.
> > + * User has to copy objects from the queue using the returned pointers.
> > + * User should call rte_ring_dequeue_sg_bulk_elem_finish to complete
> > +the
> > + * dequeue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param esize
> > + * The size of ring element, in bytes. It must be a multiple of 4.
> > + * @param n
> > + * The number of objects to remove from the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param available
> > + * If non-NULL, returns the number of remaining ring entries after the
> > + * dequeue has finished.
> > + * @return
> > + * The number of objects that can be dequeued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_dequeue_sg_bulk_elem_start(struct rte_ring *r, unsigned int
> esize,
> > + unsigned int n, struct rte_ring_sg_data *sgd, unsigned int
> > +*available) {
> > + return __rte_ring_do_dequeue_sg_elem_start(r, esize, n,
> > + RTE_RING_QUEUE_FIXED, sgd, available); }
> > +
> > +/**
> > + * Start to dequeue several pointers to objects from the ring.
> > + * Note that no actual pointers are removed from the queue by this
> function.
> > + * User has to copy pointers to objects from the queue using the
> > + * returned pointers.
> > + * User should call rte_ring_dequeue_sg_bulk_finish to complete the
> > + * dequeue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to remove from the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param available
> > + * If non-NULL, returns the number of remaining ring entries after the
> > + * dequeue has finished.
> > + * @return
> > + * The number of objects that can be dequeued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_dequeue_sg_bulk_start(struct rte_ring *r, unsigned int n,
> > + struct rte_ring_sg_data *sgd, unsigned int *available) {
> > + return rte_ring_dequeue_sg_bulk_elem_start(r, sizeof(uintptr_t),
> > + n, sgd, available);
> > +}
> > +
> > +/**
> > + * Start to dequeue several objects from the ring.
> > + * Note that no actual objects are copied from the queue by this function.
> > + * User has to copy objects from the queue using the returned pointers.
> > + * User should call rte_ring_dequeue_sg_burst_elem_finish to complete
> > +the
> > + * dequeue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param esize
> > + * The size of ring element, in bytes. It must be a multiple of 4.
> > + * This must be the same value used while creating the ring. Otherwise
> > + * the results are undefined.
> > + * @param n
> > + * The number of objects to dequeue from the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param available
> > + * If non-NULL, returns the number of remaining ring entries after the
> > + * dequeue has finished.
> > + * @return
> > + * The number of objects that can be dequeued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_dequeue_sg_burst_elem_start(struct rte_ring *r, unsigned int
> esize,
> > + unsigned int n, struct rte_ring_sg_data *sgd, unsigned int
> > +*available) {
> > + return __rte_ring_do_dequeue_sg_elem_start(r, esize, n,
> > + RTE_RING_QUEUE_VARIABLE, sgd, available); }
> > +
> > +/**
> > + * Start to dequeue several pointers to objects from the ring.
> > + * Note that no actual pointers are removed from the queue by this
> function.
> > + * User has to copy pointers to objects from the queue using the
> > + * returned pointers.
> > + * User should call rte_ring_dequeue_sg_burst_finish to complete the
> > + * dequeue operation.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to remove from the ring.
> > + * @param sgd
> > + * The scatter-gather data containing pointers for copying data.
> > + * @param available
> > + * If non-NULL, returns the number of remaining ring entries after the
> > + * dequeue has finished.
> > + * @return
> > + * The number of objects that can be dequeued, either 0 or n
> > + */
> > +__rte_experimental
> > +static __rte_always_inline unsigned int
> > +rte_ring_dequeue_sg_burst_start(struct rte_ring *r, unsigned int n,
> > + struct rte_ring_sg_data *sgd, unsigned int *available) {
> > + return rte_ring_dequeue_sg_burst_elem_start(r, sizeof(uintptr_t),
> n,
> > + sgd, available);
> > +}
> > +
> > +/**
> > + * Complete dequeuing several objects from the ring.
> > + * Note that number of objects to dequeued should not exceed previous
> > + * dequeue_start return value.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to remove from the ring.
> > + */
> > +__rte_experimental
> > +static __rte_always_inline void
> > +rte_ring_dequeue_sg_elem_finish(struct rte_ring *r, unsigned int n) {
> > + uint32_t tail;
> > +
> > + switch (r->cons.sync_type) {
> > + case RTE_RING_SYNC_ST:
> > + n = __rte_ring_st_get_tail(&r->cons, &tail, n);
> > + __rte_ring_st_set_head_tail(&r->cons, tail, n, 0);
> > + break;
> > + case RTE_RING_SYNC_MT_HTS:
> > + n = __rte_ring_hts_get_tail(&r->hts_cons, &tail, n);
> > + __rte_ring_hts_set_head_tail(&r->hts_cons, tail, n, 0);
> > + break;
> > + case RTE_RING_SYNC_MT:
> > + case RTE_RING_SYNC_MT_RTS:
> > + default:
> > + /* unsupported mode, shouldn't be here */
> > + RTE_ASSERT(0);
> > + }
> > +}
> > +
> > +/**
> > + * Complete dequeuing several objects from the ring.
> > + * Note that number of objects to dequeued should not exceed previous
> > + * dequeue_start return value.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param n
> > + * The number of objects to remove from the ring.
> > + */
> > +__rte_experimental
> > +static __rte_always_inline void
> > +rte_ring_dequeue_sg_finish(struct rte_ring *r, unsigned int n) {
> > + rte_ring_dequeue_elem_finish(r, n);
> > +}
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _RTE_RING_PEEK_SG_H_ */
> > --
> > 2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 10/11] doc: update release notes for MLX5 L3 frag support
@ 2020-10-12 19:29 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2020-10-12 19:29 UTC (permalink / raw)
To: Dekel Peled
Cc: orika, ferruh.yigit, arybchenko, konstantin.ananyev,
olivier.matz, wenzhuo.lu, beilei.xing, bernard.iremonger, matan,
shahafs, viacheslavo, dev
12/10/2020 12:43, Dekel Peled:
> This patch updates 20.11 release notes with the changes included in
> patches of this series:
> 1) MLX5 support of matching on IPv4/IPv6 fragmented/non-fragmented
> packets.
> 2) ABI change in ethdev struct rte_flow_item_ipv6.
>
> Signed-off-by: Dekel Peled <dekelp@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
Please merge the release notes changes with the code changes
in the appropriate patches.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 1/2] cryptodev: remove crypto list end enumerators
@ 2020-10-12 19:21 7% ` Arek Kusztal
0 siblings, 0 replies; 200+ results
From: Arek Kusztal @ 2020-10-12 19:21 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, fiona.trahe, Arek Kusztal
This patch removes enumerators RTE_CRYPTO_CIPHER_LIST_END,
RTE_CRYPTO_AUTH_LIST_END, RTE_CRYPTO_AEAD_LIST_END to prevent
some problems that may arise when adding new crypto algorithms.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
lib/librte_cryptodev/rte_crypto_sym.h | 36 ++++++++++++++++++---------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index f29c98051..84170e24e 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -87,7 +87,13 @@ union rte_crypto_sym_ofs {
} ofs;
};
-/** Symmetric Cipher Algorithms */
+/** Symmetric Cipher Algorithms
+ *
+ * Note, to avoid ABI breakage across releases
+ * - LIST_END should not be added to this enum
+ * - the order of enums should not be changed
+ * - new algorithms should only be added to the end
+ */
enum rte_crypto_cipher_algorithm {
RTE_CRYPTO_CIPHER_NULL = 1,
/**< NULL cipher algorithm. No mode applies to the NULL algorithm. */
@@ -132,15 +138,12 @@ enum rte_crypto_cipher_algorithm {
* for m_src and m_dst in the rte_crypto_sym_op must be NULL.
*/
- RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
+ RTE_CRYPTO_CIPHER_DES_DOCSISBPI
/**< DES algorithm using modes required by
* DOCSIS Baseline Privacy Plus Spec.
* Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
* for m_src and m_dst in the rte_crypto_sym_op must be NULL.
*/
-
- RTE_CRYPTO_CIPHER_LIST_END
-
};
/** Cipher algorithm name strings */
@@ -246,7 +249,13 @@ struct rte_crypto_cipher_xform {
} iv; /**< Initialisation vector parameters */
};
-/** Symmetric Authentication / Hash Algorithms */
+/** Symmetric Authentication / Hash Algorithms
+ *
+ * Note, to avoid ABI breakage across releases
+ * - LIST_END should not be added to this enum
+ * - the order of enums should not be changed
+ * - new algorithms should only be added to the end
+ */
enum rte_crypto_auth_algorithm {
RTE_CRYPTO_AUTH_NULL = 1,
/**< NULL hash algorithm. */
@@ -312,10 +321,8 @@ enum rte_crypto_auth_algorithm {
/**< HMAC using 384 bit SHA3 algorithm. */
RTE_CRYPTO_AUTH_SHA3_512,
/**< 512 bit SHA3 algorithm. */
- RTE_CRYPTO_AUTH_SHA3_512_HMAC,
+ RTE_CRYPTO_AUTH_SHA3_512_HMAC
/**< HMAC using 512 bit SHA3 algorithm. */
-
- RTE_CRYPTO_AUTH_LIST_END
};
/** Authentication algorithm name strings */
@@ -406,15 +413,20 @@ struct rte_crypto_auth_xform {
};
-/** Symmetric AEAD Algorithms */
+/** Symmetric AEAD Algorithms
+ *
+ * Note, to avoid ABI breakage across releases
+ * - LIST_END should not be added to this enum
+ * - the order of enums should not be changed
+ * - new algorithms should only be added to the end
+ */
enum rte_crypto_aead_algorithm {
RTE_CRYPTO_AEAD_AES_CCM = 1,
/**< AES algorithm in CCM mode. */
RTE_CRYPTO_AEAD_AES_GCM,
/**< AES algorithm in GCM mode. */
- RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
+ RTE_CRYPTO_AEAD_CHACHA20_POLY1305
/**< Chacha20 cipher with poly1305 authenticator */
- RTE_CRYPTO_AEAD_LIST_END
};
/** AEAD algorithm name strings */
--
2.17.1
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2 2/2] eventdev: update app and examples for new eventdev ABI
@ 2020-10-12 19:09 4% ` Pavan Nikhilesh Bhagavatula
2020-10-13 19:20 4% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Pavan Nikhilesh Bhagavatula @ 2020-10-12 19:09 UTC (permalink / raw)
To: Van Haaren, Harry, McDaniel, Timothy, Jerin Jacob Kollanukkaran,
Kovacevic, Marko, Ori Kam, Richardson, Bruce, Nicolau, Radu,
Akhil Goyal, Kantecki, Tomasz, Sunil Kumar Kori
Cc: dev, Carrillo, Erik G, Eads, Gage, hemant.agrawal
>> Subject: [PATCH v2 2/2] eventdev: update app and examples for new
>eventdev ABI
>>
>> Several data structures and constants changed, or were added,
>> in the previous patch. This commit updates the dependent
>> apps and examples to use the new ABI.
>>
>> Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
With fixes to trace framework
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>> ---
>
>With this patch applied, the compilation works fine, however runtime
>fails.
>Note that there is a dependency to the following fix which Timothy
>upstreamed:
>https://urldefense.proofpoint.com/v2/url?u=http-
>3A__patches.dpdk.org_patch_79713_&d=DwIFAg&c=nKjWec2b6R0mO
>yPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=mRL8gzBSQmAPRQfgNtiP_pu9ptgafRSt-
>dqHP8c6Q_A&s=84_EoTViUQXiFuIh4-
>YkcqBHP_PYsL73VmZzbczCTOI&e=
>
>The above linked patch increases the CTF trace size, and fixes the
>following error:
>./dpdk-test
>EAL: __rte_trace_point_emit_field():442 CTF field is too long
>EAL: __rte_trace_point_register():468 missing rte_trace_emit_header()
>in register fn
>
>
>> app/test-eventdev/evt_common.h | 11 ++++++++
>> app/test-eventdev/test_order_atq.c | 28 +++++++++++++++-
>-----
>> app/test-eventdev/test_order_common.c | 1 +
>> app/test-eventdev/test_order_queue.c | 29
>++++++++++++++++------
>> app/test/test_eventdev.c | 4 +--
>> .../eventdev_pipeline/pipeline_worker_generic.c | 6 +++--
>> examples/eventdev_pipeline/pipeline_worker_tx.c | 1 +
>> examples/l2fwd-event/l2fwd_event_generic.c | 7 ++++--
>> examples/l2fwd-event/l2fwd_event_internal_port.c | 6 +++--
>> examples/l3fwd/l3fwd_event_generic.c | 7 ++++--
>> examples/l3fwd/l3fwd_event_internal_port.c | 6 +++--
>> 11 files changed, 80 insertions(+), 26 deletions(-)
>>
>> diff --git a/app/test-eventdev/evt_common.h b/app/test-
>eventdev/evt_common.h
>> index f9d7378..a1da1cf 100644
>> --- a/app/test-eventdev/evt_common.h
>> +++ b/app/test-eventdev/evt_common.h
>> @@ -104,6 +104,16 @@ evt_has_all_types_queue(uint8_t dev_id)
>> true : false;
>> }
>>
>> +static inline bool
>> +evt_has_flow_id(uint8_t dev_id)
>> +{
>> + struct rte_event_dev_info dev_info;
>> +
>> + rte_event_dev_info_get(dev_id, &dev_info);
>> + return (dev_info.event_dev_cap &
>> RTE_EVENT_DEV_CAP_CARRY_FLOW_ID) ?
>> + true : false;
>> +}
>> +
>> static inline int
>> evt_service_setup(uint32_t service_id)
>> {
>> @@ -169,6 +179,7 @@ evt_configure_eventdev(struct evt_options
>*opt, uint8_t
>> nb_queues,
>> .dequeue_timeout_ns = opt->deq_tmo_nsec,
>> .nb_event_queues = nb_queues,
>> .nb_event_ports = nb_ports,
>> + .nb_single_link_event_port_queues = 0,
>> .nb_events_limit = info.max_num_events,
>> .nb_event_queue_flows = opt->nb_flows,
>> .nb_event_port_dequeue_depth =
>> diff --git a/app/test-eventdev/test_order_atq.c b/app/test-
>> eventdev/test_order_atq.c
>> index 3366cfc..cfcb1dc 100644
>> --- a/app/test-eventdev/test_order_atq.c
>> +++ b/app/test-eventdev/test_order_atq.c
>> @@ -19,7 +19,7 @@ order_atq_process_stage_0(struct rte_event
>*const ev)
>> }
>>
>> static int
>> -order_atq_worker(void *arg)
>> +order_atq_worker(void *arg, const bool flow_id_cap)
>> {
>> ORDER_WORKER_INIT;
>> struct rte_event ev;
>> @@ -34,6 +34,9 @@ order_atq_worker(void *arg)
>> continue;
>> }
>>
>> + if (!flow_id_cap)
>> + ev.flow_id = ev.mbuf->udata64;
>> +
>> if (ev.sub_event_type == 0) { /* stage 0 from producer
>*/
>> order_atq_process_stage_0(&ev);
>> while (rte_event_enqueue_burst(dev_id, port,
>&ev, 1)
>> @@ -50,7 +53,7 @@ order_atq_worker(void *arg)
>> }
>>
>> static int
>> -order_atq_worker_burst(void *arg)
>> +order_atq_worker_burst(void *arg, const bool flow_id_cap)
>> {
>> ORDER_WORKER_INIT;
>> struct rte_event ev[BURST_SIZE];
>> @@ -68,6 +71,9 @@ order_atq_worker_burst(void *arg)
>> }
>>
>> for (i = 0; i < nb_rx; i++) {
>> + if (!flow_id_cap)
>> + ev[i].flow_id = ev[i].mbuf->udata64;
>> +
>> if (ev[i].sub_event_type == 0) { /*stage 0 */
>> order_atq_process_stage_0(&ev[i]);
>> } else if (ev[i].sub_event_type == 1) { /* stage 1
>*/
>> @@ -95,11 +101,19 @@ worker_wrapper(void *arg)
>> {
>> struct worker_data *w = arg;
>> const bool burst = evt_has_burst_mode(w->dev_id);
>> -
>> - if (burst)
>> - return order_atq_worker_burst(arg);
>> - else
>> - return order_atq_worker(arg);
>> + const bool flow_id_cap = evt_has_flow_id(w->dev_id);
>> +
>> + if (burst) {
>> + if (flow_id_cap)
>> + return order_atq_worker_burst(arg, true);
>> + else
>> + return order_atq_worker_burst(arg, false);
>> + } else {
>> + if (flow_id_cap)
>> + return order_atq_worker(arg, true);
>> + else
>> + return order_atq_worker(arg, false);
>> + }
>> }
>>
>> static int
>> diff --git a/app/test-eventdev/test_order_common.c b/app/test-
>> eventdev/test_order_common.c
>> index 4190f9a..7942390 100644
>> --- a/app/test-eventdev/test_order_common.c
>> +++ b/app/test-eventdev/test_order_common.c
>> @@ -49,6 +49,7 @@ order_producer(void *arg)
>> const uint32_t flow = (uintptr_t)m % nb_flows;
>> /* Maintain seq number per flow */
>> m->seqn = producer_flow_seq[flow]++;
>> + m->udata64 = flow;
>>
>> ev.flow_id = flow;
>> ev.mbuf = m;
>> diff --git a/app/test-eventdev/test_order_queue.c b/app/test-
>> eventdev/test_order_queue.c
>> index 495efd9..1511c00 100644
>> --- a/app/test-eventdev/test_order_queue.c
>> +++ b/app/test-eventdev/test_order_queue.c
>> @@ -19,7 +19,7 @@ order_queue_process_stage_0(struct rte_event
>*const ev)
>> }
>>
>> static int
>> -order_queue_worker(void *arg)
>> +order_queue_worker(void *arg, const bool flow_id_cap)
>> {
>> ORDER_WORKER_INIT;
>> struct rte_event ev;
>> @@ -34,6 +34,9 @@ order_queue_worker(void *arg)
>> continue;
>> }
>>
>> + if (!flow_id_cap)
>> + ev.flow_id = ev.mbuf->udata64;
>> +
>> if (ev.queue_id == 0) { /* from ordered queue */
>> order_queue_process_stage_0(&ev);
>> while (rte_event_enqueue_burst(dev_id, port,
>&ev, 1)
>> @@ -50,7 +53,7 @@ order_queue_worker(void *arg)
>> }
>>
>> static int
>> -order_queue_worker_burst(void *arg)
>> +order_queue_worker_burst(void *arg, const bool flow_id_cap)
>> {
>> ORDER_WORKER_INIT;
>> struct rte_event ev[BURST_SIZE];
>> @@ -68,6 +71,10 @@ order_queue_worker_burst(void *arg)
>> }
>>
>> for (i = 0; i < nb_rx; i++) {
>> +
>> + if (!flow_id_cap)
>> + ev[i].flow_id = ev[i].mbuf->udata64;
>> +
>> if (ev[i].queue_id == 0) { /* from ordered queue
>*/
>> order_queue_process_stage_0(&ev[i]);
>> } else if (ev[i].queue_id == 1) {/* from atomic
>queue */
>> @@ -95,11 +102,19 @@ worker_wrapper(void *arg)
>> {
>> struct worker_data *w = arg;
>> const bool burst = evt_has_burst_mode(w->dev_id);
>> -
>> - if (burst)
>> - return order_queue_worker_burst(arg);
>> - else
>> - return order_queue_worker(arg);
>> + const bool flow_id_cap = evt_has_flow_id(w->dev_id);
>> +
>> + if (burst) {
>> + if (flow_id_cap)
>> + return order_queue_worker_burst(arg, true);
>> + else
>> + return order_queue_worker_burst(arg, false);
>> + } else {
>> + if (flow_id_cap)
>> + return order_queue_worker(arg, true);
>> + else
>> + return order_queue_worker(arg, false);
>> + }
>> }
>>
>> static int
>> diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
>> index 43ccb1c..62019c1 100644
>> --- a/app/test/test_eventdev.c
>> +++ b/app/test/test_eventdev.c
>> @@ -559,10 +559,10 @@ test_eventdev_port_setup(void)
>> if (!(info.event_dev_cap &
>> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
>> pconf.enqueue_depth =
>info.max_event_port_enqueue_depth;
>> - pconf.disable_implicit_release = 1;
>> + pconf.event_port_cfg =
>> RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>> ret = rte_event_port_setup(TEST_DEV_ID, 0, &pconf);
>> TEST_ASSERT(ret == -EINVAL, "Expected -EINVAL, %d",
>ret);
>> - pconf.disable_implicit_release = 0;
>> + pconf.event_port_cfg = 0;
>> }
>>
>> ret = rte_event_port_setup(TEST_DEV_ID,
>info.max_event_ports,
>> diff --git a/examples/eventdev_pipeline/pipeline_worker_generic.c
>> b/examples/eventdev_pipeline/pipeline_worker_generic.c
>> index 42ff4ee..f70ab0c 100644
>> --- a/examples/eventdev_pipeline/pipeline_worker_generic.c
>> +++ b/examples/eventdev_pipeline/pipeline_worker_generic.c
>> @@ -129,6 +129,7 @@ setup_eventdev_generic(struct worker_data
>*worker_data)
>> struct rte_event_dev_config config = {
>> .nb_event_queues = nb_queues,
>> .nb_event_ports = nb_ports,
>> + .nb_single_link_event_port_queues = 1,
>> .nb_events_limit = 4096,
>> .nb_event_queue_flows = 1024,
>> .nb_event_port_dequeue_depth = 128,
>> @@ -143,7 +144,7 @@ setup_eventdev_generic(struct worker_data
>*worker_data)
>> .schedule_type = cdata.queue_type,
>> .priority =
>RTE_EVENT_DEV_PRIORITY_NORMAL,
>> .nb_atomic_flows = 1024,
>> - .nb_atomic_order_sequences = 1024,
>> + .nb_atomic_order_sequences = 1024,
>> };
>> struct rte_event_queue_conf tx_q_conf = {
>> .priority =
>RTE_EVENT_DEV_PRIORITY_HIGHEST,
>> @@ -167,7 +168,8 @@ setup_eventdev_generic(struct worker_data
>*worker_data)
>> disable_implicit_release = (dev_info.event_dev_cap &
>>
> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
>>
>> - wkr_p_conf.disable_implicit_release = disable_implicit_release;
>> + wkr_p_conf.event_port_cfg = disable_implicit_release ?
>> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
>>
>> if (dev_info.max_num_events < config.nb_events_limit)
>> config.nb_events_limit = dev_info.max_num_events;
>> diff --git a/examples/eventdev_pipeline/pipeline_worker_tx.c
>> b/examples/eventdev_pipeline/pipeline_worker_tx.c
>> index 55bb2f7..ca6cd20 100644
>> --- a/examples/eventdev_pipeline/pipeline_worker_tx.c
>> +++ b/examples/eventdev_pipeline/pipeline_worker_tx.c
>> @@ -436,6 +436,7 @@ setup_eventdev_worker_tx_enq(struct
>worker_data
>> *worker_data)
>> struct rte_event_dev_config config = {
>> .nb_event_queues = nb_queues,
>> .nb_event_ports = nb_ports,
>> + .nb_single_link_event_port_queues = 0,
>> .nb_events_limit = 4096,
>> .nb_event_queue_flows = 1024,
>> .nb_event_port_dequeue_depth = 128,
>> diff --git a/examples/l2fwd-event/l2fwd_event_generic.c
>b/examples/l2fwd-
>> event/l2fwd_event_generic.c
>> index 2dc95e5..9a3167c 100644
>> --- a/examples/l2fwd-event/l2fwd_event_generic.c
>> +++ b/examples/l2fwd-event/l2fwd_event_generic.c
>> @@ -126,8 +126,11 @@ l2fwd_event_port_setup_generic(struct
>l2fwd_resources
>> *rsrc)
>> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
>> event_p_conf.enqueue_depth =
>def_p_conf.enqueue_depth;
>>
>> - event_p_conf.disable_implicit_release =
>> - evt_rsrc->disable_implicit_release;
>> + event_p_conf.event_port_cfg = 0;
>> + if (evt_rsrc->disable_implicit_release)
>> + event_p_conf.event_port_cfg |=
>> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>> +
>> evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
>>
>> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
>> diff --git a/examples/l2fwd-event/l2fwd_event_internal_port.c
>b/examples/l2fwd-
>> event/l2fwd_event_internal_port.c
>> index 63d57b4..203a14c 100644
>> --- a/examples/l2fwd-event/l2fwd_event_internal_port.c
>> +++ b/examples/l2fwd-event/l2fwd_event_internal_port.c
>> @@ -123,8 +123,10 @@
>l2fwd_event_port_setup_internal_port(struct
>> l2fwd_resources *rsrc)
>> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
>> event_p_conf.enqueue_depth =
>def_p_conf.enqueue_depth;
>>
>> - event_p_conf.disable_implicit_release =
>> - evt_rsrc->disable_implicit_release;
>> + event_p_conf.event_port_cfg = 0;
>> + if (evt_rsrc->disable_implicit_release)
>> + event_p_conf.event_port_cfg |=
>> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>>
>> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
>>
> event_p_id++) {
>> diff --git a/examples/l3fwd/l3fwd_event_generic.c
>> b/examples/l3fwd/l3fwd_event_generic.c
>> index f8c9843..c80573f 100644
>> --- a/examples/l3fwd/l3fwd_event_generic.c
>> +++ b/examples/l3fwd/l3fwd_event_generic.c
>> @@ -115,8 +115,11 @@ l3fwd_event_port_setup_generic(void)
>> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
>> event_p_conf.enqueue_depth =
>def_p_conf.enqueue_depth;
>>
>> - event_p_conf.disable_implicit_release =
>> - evt_rsrc->disable_implicit_release;
>> + event_p_conf.event_port_cfg = 0;
>> + if (evt_rsrc->disable_implicit_release)
>> + event_p_conf.event_port_cfg |=
>> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>> +
>> evt_rsrc->deq_depth = def_p_conf.dequeue_depth;
>>
>> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
>> diff --git a/examples/l3fwd/l3fwd_event_internal_port.c
>> b/examples/l3fwd/l3fwd_event_internal_port.c
>> index 03ac581..9916a7f 100644
>> --- a/examples/l3fwd/l3fwd_event_internal_port.c
>> +++ b/examples/l3fwd/l3fwd_event_internal_port.c
>> @@ -113,8 +113,10 @@ l3fwd_event_port_setup_internal_port(void)
>> if (def_p_conf.enqueue_depth < event_p_conf.enqueue_depth)
>> event_p_conf.enqueue_depth =
>def_p_conf.enqueue_depth;
>>
>> - event_p_conf.disable_implicit_release =
>> - evt_rsrc->disable_implicit_release;
>> + event_p_conf.event_port_cfg = 0;
>> + if (evt_rsrc->disable_implicit_release)
>> + event_p_conf.event_port_cfg |=
>> + RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL;
>>
>> for (event_p_id = 0; event_p_id < evt_rsrc->evp.nb_ports;
>>
> event_p_id++) {
>> --
>> 2.6.4
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] [PATCH v2 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints
@ 2020-10-12 19:06 0% ` Pavan Nikhilesh Bhagavatula
0 siblings, 0 replies; 200+ results
From: Pavan Nikhilesh Bhagavatula @ 2020-10-12 19:06 UTC (permalink / raw)
To: Timothy McDaniel, Hemant Agrawal, Nipun Gupta,
Mattias Rönnblom, Jerin Jacob Kollanukkaran, Liang Ma,
Peter Mccarthy, Harry van Haaren, Nikhil Rao, Ray Kinsella,
Neil Horman
Cc: dev, erik.g.carrillo, gage.eads
>This commit implements the eventdev ABI changes required by
>the DLB PMD.
>
>Signed-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>
For octeontx/octeontx2
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>---
> drivers/event/dpaa/dpaa_eventdev.c | 3 +-
> drivers/event/dpaa2/dpaa2_eventdev.c | 5 +-
> drivers/event/dsw/dsw_evdev.c | 3 +-
> drivers/event/octeontx/ssovf_evdev.c | 5 +-
> drivers/event/octeontx2/otx2_evdev.c | 3 +-
> drivers/event/opdl/opdl_evdev.c | 3 +-
> drivers/event/skeleton/skeleton_eventdev.c | 5 +-
> drivers/event/sw/sw_evdev.c | 8 ++--
> drivers/event/sw/sw_evdev_selftest.c | 6 +--
> lib/librte_eventdev/rte_event_eth_tx_adapter.c | 2 +-
> lib/librte_eventdev/rte_eventdev.c | 66
>+++++++++++++++++++++++---
> lib/librte_eventdev/rte_eventdev.h | 51 ++++++++++++++++----
> lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 -
> lib/librte_eventdev/rte_eventdev_trace.h | 7 +--
> lib/librte_eventdev/rte_eventdev_version.map | 4 +-
> 15 files changed, 134 insertions(+), 38 deletions(-)
>
>diff --git a/drivers/event/dpaa/dpaa_eventdev.c
>b/drivers/event/dpaa/dpaa_eventdev.c
>index b5ae87a..07cd079 100644
>--- a/drivers/event/dpaa/dpaa_eventdev.c
>+++ b/drivers/event/dpaa/dpaa_eventdev.c
>@@ -355,7 +355,8 @@ dpaa_event_dev_info_get(struct rte_eventdev
>*dev,
> RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED |
> RTE_EVENT_DEV_CAP_BURST_MODE |
> RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
>- RTE_EVENT_DEV_CAP_NONSEQ_MODE;
>+ RTE_EVENT_DEV_CAP_NONSEQ_MODE |
>+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
> }
>
> static int
>diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c
>b/drivers/event/dpaa2/dpaa2_eventdev.c
>index 3ae4441..712db6c 100644
>--- a/drivers/event/dpaa2/dpaa2_eventdev.c
>+++ b/drivers/event/dpaa2/dpaa2_eventdev.c
>@@ -406,7 +406,8 @@ dpaa2_eventdev_info_get(struct rte_eventdev
>*dev,
> RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
> RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
> RTE_EVENT_DEV_CAP_NONSEQ_MODE |
>- RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES;
>+ RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
>+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
>
> }
>
>@@ -536,7 +537,7 @@ dpaa2_eventdev_port_def_conf(struct
>rte_eventdev *dev, uint8_t port_id,
> DPAA2_EVENT_MAX_PORT_DEQUEUE_DEPTH;
> port_conf->enqueue_depth =
> DPAA2_EVENT_MAX_PORT_ENQUEUE_DEPTH;
>- port_conf->disable_implicit_release = 0;
>+ port_conf->event_port_cfg = 0;
> }
>
> static int
>diff --git a/drivers/event/dsw/dsw_evdev.c
>b/drivers/event/dsw/dsw_evdev.c
>index e796975..933a5a5 100644
>--- a/drivers/event/dsw/dsw_evdev.c
>+++ b/drivers/event/dsw/dsw_evdev.c
>@@ -224,7 +224,8 @@ dsw_info_get(struct rte_eventdev *dev
>__rte_unused,
> .event_dev_cap =
>RTE_EVENT_DEV_CAP_BURST_MODE|
> RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED|
> RTE_EVENT_DEV_CAP_NONSEQ_MODE|
>- RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT
>+ RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT|
>+ RTE_EVENT_DEV_CAP_CARRY_FLOW_ID
> };
> }
>
>diff --git a/drivers/event/octeontx/ssovf_evdev.c
>b/drivers/event/octeontx/ssovf_evdev.c
>index 4fc4e8f..1c6bcca 100644
>--- a/drivers/event/octeontx/ssovf_evdev.c
>+++ b/drivers/event/octeontx/ssovf_evdev.c
>@@ -152,7 +152,8 @@ ssovf_info_get(struct rte_eventdev *dev, struct
>rte_event_dev_info *dev_info)
>
> RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES|
>
> RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
>
> RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
>-
> RTE_EVENT_DEV_CAP_NONSEQ_MODE;
>+
> RTE_EVENT_DEV_CAP_NONSEQ_MODE |
>+
> RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
>
> }
>
>@@ -218,7 +219,7 @@ ssovf_port_def_conf(struct rte_eventdev *dev,
>uint8_t port_id,
> port_conf->new_event_threshold = edev->max_num_events;
> port_conf->dequeue_depth = 1;
> port_conf->enqueue_depth = 1;
>- port_conf->disable_implicit_release = 0;
>+ port_conf->event_port_cfg = 0;
> }
>
> static void
>diff --git a/drivers/event/octeontx2/otx2_evdev.c
>b/drivers/event/octeontx2/otx2_evdev.c
>index b8b57c3..ae35bb5 100644
>--- a/drivers/event/octeontx2/otx2_evdev.c
>+++ b/drivers/event/octeontx2/otx2_evdev.c
>@@ -501,7 +501,8 @@ otx2_sso_info_get(struct rte_eventdev
>*event_dev,
>
> RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES |
>
> RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
>
> RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
>-
> RTE_EVENT_DEV_CAP_NONSEQ_MODE;
>+
> RTE_EVENT_DEV_CAP_NONSEQ_MODE |
>+
> RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
> }
>
> static void
>diff --git a/drivers/event/opdl/opdl_evdev.c
>b/drivers/event/opdl/opdl_evdev.c
>index 9b2f75f..3050578 100644
>--- a/drivers/event/opdl/opdl_evdev.c
>+++ b/drivers/event/opdl/opdl_evdev.c
>@@ -374,7 +374,8 @@ opdl_info_get(struct rte_eventdev *dev, struct
>rte_event_dev_info *info)
> .max_event_port_dequeue_depth =
>MAX_OPDL_CONS_Q_DEPTH,
> .max_event_port_enqueue_depth =
>MAX_OPDL_CONS_Q_DEPTH,
> .max_num_events = OPDL_INFLIGHT_EVENTS_TOTAL,
>- .event_dev_cap =
>RTE_EVENT_DEV_CAP_BURST_MODE,
>+ .event_dev_cap =
>RTE_EVENT_DEV_CAP_BURST_MODE |
>+
>RTE_EVENT_DEV_CAP_CARRY_FLOW_ID,
> };
>
> *info = evdev_opdl_info;
>diff --git a/drivers/event/skeleton/skeleton_eventdev.c
>b/drivers/event/skeleton/skeleton_eventdev.c
>index c889220..6fd1102 100644
>--- a/drivers/event/skeleton/skeleton_eventdev.c
>+++ b/drivers/event/skeleton/skeleton_eventdev.c
>@@ -101,7 +101,8 @@ skeleton_eventdev_info_get(struct
>rte_eventdev *dev,
> dev_info->max_num_events = (1ULL << 20);
> dev_info->event_dev_cap =
>RTE_EVENT_DEV_CAP_QUEUE_QOS |
>
> RTE_EVENT_DEV_CAP_BURST_MODE |
>-
> RTE_EVENT_DEV_CAP_EVENT_QOS;
>+
> RTE_EVENT_DEV_CAP_EVENT_QOS |
>+
> RTE_EVENT_DEV_CAP_CARRY_FLOW_ID;
> }
>
> static int
>@@ -209,7 +210,7 @@ skeleton_eventdev_port_def_conf(struct
>rte_eventdev *dev, uint8_t port_id,
> port_conf->new_event_threshold = 32 * 1024;
> port_conf->dequeue_depth = 16;
> port_conf->enqueue_depth = 16;
>- port_conf->disable_implicit_release = 0;
>+ port_conf->event_port_cfg = 0;
> }
>
> static void
>diff --git a/drivers/event/sw/sw_evdev.c
>b/drivers/event/sw/sw_evdev.c
>index 98dae71..058f568 100644
>--- a/drivers/event/sw/sw_evdev.c
>+++ b/drivers/event/sw/sw_evdev.c
>@@ -175,7 +175,8 @@ sw_port_setup(struct rte_eventdev *dev,
>uint8_t port_id,
> }
>
> p->inflight_max = conf->new_event_threshold;
>- p->implicit_release = !conf->disable_implicit_release;
>+ p->implicit_release = !(conf->event_port_cfg &
>+
> RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
>
> /* check if ring exists, same as rx_worker above */
> snprintf(buf, sizeof(buf), "sw%d_p%u, %s", dev->data->dev_id,
>@@ -508,7 +509,7 @@ sw_port_def_conf(struct rte_eventdev *dev,
>uint8_t port_id,
> port_conf->new_event_threshold = 1024;
> port_conf->dequeue_depth = 16;
> port_conf->enqueue_depth = 16;
>- port_conf->disable_implicit_release = 0;
>+ port_conf->event_port_cfg = 0;
> }
>
> static int
>@@ -615,7 +616,8 @@ sw_info_get(struct rte_eventdev *dev, struct
>rte_event_dev_info *info)
>
> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE|
>
> RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK |
>
> RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT |
>-
> RTE_EVENT_DEV_CAP_NONSEQ_MODE),
>+ RTE_EVENT_DEV_CAP_NONSEQ_MODE
>|
>+
> RTE_EVENT_DEV_CAP_CARRY_FLOW_ID),
> };
>
> *info = evdev_sw_info;
>diff --git a/drivers/event/sw/sw_evdev_selftest.c
>b/drivers/event/sw/sw_evdev_selftest.c
>index 38c21fa..4a7d823 100644
>--- a/drivers/event/sw/sw_evdev_selftest.c
>+++ b/drivers/event/sw/sw_evdev_selftest.c
>@@ -172,7 +172,6 @@ create_ports(struct test *t, int num_ports)
> .new_event_threshold = 1024,
> .dequeue_depth = 32,
> .enqueue_depth = 64,
>- .disable_implicit_release = 0,
> };
> if (num_ports > MAX_PORTS)
> return -1;
>@@ -1227,7 +1226,6 @@ port_reconfig_credits(struct test *t)
> .new_event_threshold = 128,
> .dequeue_depth = 32,
> .enqueue_depth = 64,
>- .disable_implicit_release = 0,
> };
> if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
> printf("%d Error setting up port\n", __LINE__);
>@@ -1317,7 +1315,6 @@ port_single_lb_reconfig(struct test *t)
> .new_event_threshold = 128,
> .dequeue_depth = 32,
> .enqueue_depth = 64,
>- .disable_implicit_release = 0,
> };
> if (rte_event_port_setup(evdev, 0, &port_conf) < 0) {
> printf("%d Error setting up port\n", __LINE__);
>@@ -3079,7 +3076,8 @@ worker_loopback(struct test *t, uint8_t
>disable_implicit_release)
> * only be initialized once - and this needs to be set for multiple
>runs
> */
> conf.new_event_threshold = 512;
>- conf.disable_implicit_release = disable_implicit_release;
>+ conf.event_port_cfg = disable_implicit_release ?
>+ RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL : 0;
>
> if (rte_event_port_setup(evdev, 0, &conf) < 0) {
> printf("Error setting up RX port\n");
>diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
>b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
>index bb21dc4..8a72256 100644
>--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
>+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
>@@ -286,7 +286,7 @@ txa_service_conf_cb(uint8_t __rte_unused id,
>uint8_t dev_id,
> return ret;
> }
>
>- pc->disable_implicit_release = 0;
>+ pc->event_port_cfg = 0;
> ret = rte_event_port_setup(dev_id, port_id, pc);
> if (ret) {
> RTE_EDEV_LOG_ERR("failed to setup event port %u\n",
>diff --git a/lib/librte_eventdev/rte_eventdev.c
>b/lib/librte_eventdev/rte_eventdev.c
>index 82c177c..3a5b738 100644
>--- a/lib/librte_eventdev/rte_eventdev.c
>+++ b/lib/librte_eventdev/rte_eventdev.c
>@@ -32,6 +32,7 @@
> #include <rte_ethdev.h>
> #include <rte_cryptodev.h>
> #include <rte_cryptodev_pmd.h>
>+#include <rte_compat.h>
>
> #include "rte_eventdev.h"
> #include "rte_eventdev_pmd.h"
>@@ -437,9 +438,29 @@ rte_event_dev_configure(uint8_t dev_id,
> dev_id);
> return -EINVAL;
> }
>- if (dev_conf->nb_event_queues > info.max_event_queues) {
>- RTE_EDEV_LOG_ERR("%d nb_event_queues=%d >
>max_event_queues=%d",
>- dev_id, dev_conf->nb_event_queues,
>info.max_event_queues);
>+ if (dev_conf->nb_event_queues > info.max_event_queues +
>+ info.max_single_link_event_port_queue_pairs)
>{
>+ RTE_EDEV_LOG_ERR("%d nb_event_queues=%d >
>max_event_queues=%d +
>max_single_link_event_port_queue_pairs=%d",
>+ dev_id, dev_conf->nb_event_queues,
>+ info.max_event_queues,
>+
>info.max_single_link_event_port_queue_pairs);
>+ return -EINVAL;
>+ }
>+ if (dev_conf->nb_event_queues -
>+ dev_conf->nb_single_link_event_port_queues >
>+ info.max_event_queues) {
>+ RTE_EDEV_LOG_ERR("id%d nb_event_queues=%d -
>nb_single_link_event_port_queues=%d > max_event_queues=%d",
>+ dev_id, dev_conf->nb_event_queues,
>+ dev_conf-
>>nb_single_link_event_port_queues,
>+ info.max_event_queues);
>+ return -EINVAL;
>+ }
>+ if (dev_conf->nb_single_link_event_port_queues >
>+ dev_conf->nb_event_queues) {
>+ RTE_EDEV_LOG_ERR("dev%d
>nb_single_link_event_port_queues=%d > nb_event_queues=%d",
>+ dev_id,
>+ dev_conf-
>>nb_single_link_event_port_queues,
>+ dev_conf->nb_event_queues);
> return -EINVAL;
> }
>
>@@ -448,9 +469,31 @@ rte_event_dev_configure(uint8_t dev_id,
> RTE_EDEV_LOG_ERR("dev%d nb_event_ports cannot
>be zero", dev_id);
> return -EINVAL;
> }
>- if (dev_conf->nb_event_ports > info.max_event_ports) {
>- RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d >
>max_event_ports= %d",
>- dev_id, dev_conf->nb_event_ports,
>info.max_event_ports);
>+ if (dev_conf->nb_event_ports > info.max_event_ports +
>+ info.max_single_link_event_port_queue_pairs)
>{
>+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d >
>max_event_ports=%d + max_single_link_event_port_queue_pairs=%d",
>+ dev_id, dev_conf->nb_event_ports,
>+ info.max_event_ports,
>+
>info.max_single_link_event_port_queue_pairs);
>+ return -EINVAL;
>+ }
>+ if (dev_conf->nb_event_ports -
>+ dev_conf->nb_single_link_event_port_queues
>+ > info.max_event_ports) {
>+ RTE_EDEV_LOG_ERR("id%d nb_event_ports=%d -
>nb_single_link_event_port_queues=%d > max_event_ports=%d",
>+ dev_id, dev_conf->nb_event_ports,
>+ dev_conf-
>>nb_single_link_event_port_queues,
>+ info.max_event_ports);
>+ return -EINVAL;
>+ }
>+
>+ if (dev_conf->nb_single_link_event_port_queues >
>+ dev_conf->nb_event_ports) {
>+ RTE_EDEV_LOG_ERR(
>+ "dev%d
>nb_single_link_event_port_queues=%d > nb_event_ports=%d",
>+ dev_id,
>+ dev_conf-
>>nb_single_link_event_port_queues,
>+ dev_conf->nb_event_ports);
> return -EINVAL;
> }
>
>@@ -737,7 +780,8 @@ rte_event_port_setup(uint8_t dev_id, uint8_t
>port_id,
> return -EINVAL;
> }
>
>- if (port_conf && port_conf->disable_implicit_release &&
>+ if (port_conf &&
>+ (port_conf->event_port_cfg &
>RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL) &&
> !(dev->data->event_dev_cap &
> RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE)) {
> RTE_EDEV_LOG_ERR(
>@@ -830,6 +874,14 @@ rte_event_port_attr_get(uint8_t dev_id,
>uint8_t port_id, uint32_t attr_id,
> case RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD:
> *attr_value = dev->data-
>>ports_cfg[port_id].new_event_threshold;
> break;
>+ case RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE:
>+ {
>+ uint32_t config;
>+
>+ config = dev->data-
>>ports_cfg[port_id].event_port_cfg;
>+ *attr_value = !!(config &
>RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL);
>+ break;
>+ }
> default:
> return -EINVAL;
> };
>diff --git a/lib/librte_eventdev/rte_eventdev.h
>b/lib/librte_eventdev/rte_eventdev.h
>index 7dc8323..ce1fc2c 100644
>--- a/lib/librte_eventdev/rte_eventdev.h
>+++ b/lib/librte_eventdev/rte_eventdev.h
>@@ -291,6 +291,12 @@ struct rte_event;
> * single queue to each port or map a single queue to many port.
> */
>
>+#define RTE_EVENT_DEV_CAP_CARRY_FLOW_ID (1ULL << 9)
>+/**< Event device preserves the flow ID from the enqueued
>+ * event to the dequeued event if the flag is set. Otherwise,
>+ * the content of this field is implementation dependent.
>+ */
>+
> /* Event device priority levels */
> #define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
> /**< Highest priority expressed across eventdev subsystem
>@@ -380,6 +386,10 @@ struct rte_event_dev_info {
> * event port by this device.
> * A device that does not support bulk enqueue will set this as 1.
> */
>+ uint8_t max_event_port_links;
>+ /**< Maximum number of queues that can be linked to a single
>event
>+ * port by this device.
>+ */
> int32_t max_num_events;
> /**< A *closed system* event dev has a limit on the number of
>events it
> * can manage at a time. An *open system* event dev does not
>have a
>@@ -387,6 +397,12 @@ struct rte_event_dev_info {
> */
> uint32_t event_dev_cap;
> /**< Event device capabilities(RTE_EVENT_DEV_CAP_)*/
>+ uint8_t max_single_link_event_port_queue_pairs;
>+ /**< Maximum number of event ports and queues that are
>optimized for
>+ * (and only capable of) single-link configurations supported by
>this
>+ * device. These ports and queues are not accounted for in
>+ * max_event_ports or max_event_queues.
>+ */
> };
>
> /**
>@@ -494,6 +510,14 @@ struct rte_event_dev_config {
> */
> uint32_t event_dev_cfg;
> /**< Event device config flags(RTE_EVENT_DEV_CFG_)*/
>+ uint8_t nb_single_link_event_port_queues;
>+ /**< Number of event ports and queues that will be singly-
>linked to
>+ * each other. These are a subset of the overall event ports and
>+ * queues; this value cannot exceed *nb_event_ports* or
>+ * *nb_event_queues*. If the device has ports and queues that
>are
>+ * optimized for single-link usage, this field is a hint for how
>many
>+ * to allocate; otherwise, regular event ports and queues can be
>used.
>+ */
> };
>
> /**
>@@ -519,7 +543,6 @@ int
> rte_event_dev_configure(uint8_t dev_id,
> const struct rte_event_dev_config *dev_conf);
>
>-
> /* Event queue specific APIs */
>
> /* Event queue configuration bitmap flags */
>@@ -671,6 +694,20 @@ rte_event_queue_attr_get(uint8_t dev_id,
>uint8_t queue_id, uint32_t attr_id,
>
> /* Event port specific APIs */
>
>+/* Event port configuration bitmap flags */
>+#define RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL (1ULL << 0)
>+/**< Configure the port not to release outstanding events in
>+ * rte_event_dev_dequeue_burst(). If set, all events received through
>+ * the port must be explicitly released with RTE_EVENT_OP_RELEASE
>or
>+ * RTE_EVENT_OP_FORWARD. Must be unset if the device is not
>+ * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
>+ */
>+#define RTE_EVENT_PORT_CFG_SINGLE_LINK (1ULL << 1)
>+/**< This event port links only to a single event queue.
>+ *
>+ * @see rte_event_port_setup(), rte_event_port_link()
>+ */
>+
> /** Event port configuration structure */
> struct rte_event_port_conf {
> int32_t new_event_threshold;
>@@ -698,13 +735,7 @@ struct rte_event_port_conf {
> * which previously supplied to rte_event_dev_configure().
> * Ignored when device is not
>RTE_EVENT_DEV_CAP_BURST_MODE capable.
> */
>- uint8_t disable_implicit_release;
>- /**< Configure the port not to release outstanding events in
>- * rte_event_dev_dequeue_burst(). If true, all events received
>through
>- * the port must be explicitly released with
>RTE_EVENT_OP_RELEASE or
>- * RTE_EVENT_OP_FORWARD. Must be false when the device is
>not
>- * RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE capable.
>- */
>+ uint32_t event_port_cfg; /**< Port cfg
>flags(EVENT_PORT_CFG_) */
> };
>
> /**
>@@ -769,6 +800,10 @@ rte_event_port_setup(uint8_t dev_id, uint8_t
>port_id,
> * The new event threshold of the port
> */
> #define RTE_EVENT_PORT_ATTR_NEW_EVENT_THRESHOLD 2
>+/**
>+ * The implicit release disable attribute of the port
>+ */
>+#define RTE_EVENT_PORT_ATTR_IMPLICIT_RELEASE_DISABLE 3
>
> /**
> * Get an attribute from a port.
>diff --git a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
>b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
>index 443cd38..a3f9244 100644
>--- a/lib/librte_eventdev/rte_eventdev_pmd_pci.h
>+++ b/lib/librte_eventdev/rte_eventdev_pmd_pci.h
>@@ -88,7 +88,6 @@ rte_event_pmd_pci_probe(struct rte_pci_driver
>*pci_drv,
> return -ENXIO;
> }
>
>-
> /**
> * @internal
> * Wrapper for use by pci drivers as a .remove function to detach a
>event
>diff --git a/lib/librte_eventdev/rte_eventdev_trace.h
>b/lib/librte_eventdev/rte_eventdev_trace.h
>index 4de6341..5ec43d8 100644
>--- a/lib/librte_eventdev/rte_eventdev_trace.h
>+++ b/lib/librte_eventdev/rte_eventdev_trace.h
>@@ -34,6 +34,7 @@ RTE_TRACE_POINT(
> rte_trace_point_emit_u32(dev_conf-
>>nb_event_port_dequeue_depth);
> rte_trace_point_emit_u32(dev_conf-
>>nb_event_port_enqueue_depth);
> rte_trace_point_emit_u32(dev_conf->event_dev_cfg);
>+ rte_trace_point_emit_u8(dev_conf-
>>nb_single_link_event_port_queues);
> rte_trace_point_emit_int(rc);
> )
>
>@@ -59,7 +60,7 @@ RTE_TRACE_POINT(
> rte_trace_point_emit_i32(port_conf->new_event_threshold);
> rte_trace_point_emit_u16(port_conf->dequeue_depth);
> rte_trace_point_emit_u16(port_conf->enqueue_depth);
>- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
>+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
> rte_trace_point_emit_int(rc);
> )
>
>@@ -165,7 +166,7 @@ RTE_TRACE_POINT(
> rte_trace_point_emit_i32(port_conf->new_event_threshold);
> rte_trace_point_emit_u16(port_conf->dequeue_depth);
> rte_trace_point_emit_u16(port_conf->enqueue_depth);
>- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
>+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
> rte_trace_point_emit_ptr(conf_cb);
> rte_trace_point_emit_int(rc);
> )
>@@ -257,7 +258,7 @@ RTE_TRACE_POINT(
> rte_trace_point_emit_i32(port_conf->new_event_threshold);
> rte_trace_point_emit_u16(port_conf->dequeue_depth);
> rte_trace_point_emit_u16(port_conf->enqueue_depth);
>- rte_trace_point_emit_u8(port_conf->disable_implicit_release);
>+ rte_trace_point_emit_u32(port_conf->event_port_cfg);
> )
>
> RTE_TRACE_POINT(
>diff --git a/lib/librte_eventdev/rte_eventdev_version.map
>b/lib/librte_eventdev/rte_eventdev_version.map
>index 3d9d0ca..2846d04 100644
>--- a/lib/librte_eventdev/rte_eventdev_version.map
>+++ b/lib/librte_eventdev/rte_eventdev_version.map
>@@ -100,7 +100,6 @@ EXPERIMENTAL {
> # added in 20.05
> __rte_eventdev_trace_configure;
> __rte_eventdev_trace_queue_setup;
>- __rte_eventdev_trace_port_setup;
> __rte_eventdev_trace_port_link;
> __rte_eventdev_trace_port_unlink;
> __rte_eventdev_trace_start;
>@@ -134,4 +133,7 @@ EXPERIMENTAL {
> __rte_eventdev_trace_crypto_adapter_queue_pair_del;
> __rte_eventdev_trace_crypto_adapter_start;
> __rte_eventdev_trace_crypto_adapter_stop;
>+
>+ # changed in 20.11
>+ __rte_eventdev_trace_port_setup;
> };
>--
>2.6.4
^ permalink raw reply [relevance 0%]
Results 4601-4800 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2019-12-04 10:05 [dpdk-dev] [PATCH] drivers/net: fix mlx* glue libraries ABI version David Marchand
2020-10-19 9:41 9% ` [dpdk-dev] [PATCH v2] drivers: remove mlx* glue libraries separate " David Marchand
2020-10-27 12:13 4% ` David Marchand
2020-11-01 14:48 4% ` Thomas Monjalon
2020-11-01 15:02 7% ` Slava Ovsiienko
2020-11-01 15:09 4% ` Raslan Darawsheh
2020-01-04 1:33 [dpdk-dev] [PATCH 00/14] cleanup resources on shutdown Stephen Hemminger
2020-04-28 23:58 ` [dpdk-dev] [PATCH v3 0/8] eal: " Stephen Hemminger
2020-05-03 17:21 ` David Marchand
2020-10-19 22:24 0% ` Thomas Monjalon
2020-02-24 20:39 [dpdk-dev] [RFC 0/1] lib/ring: add scatter gather and serial dequeue APIs Honnappa Nagarahalli
2020-10-06 13:29 ` [dpdk-dev] [RFC v2 0/1] lib/ring: add scatter gather APIs Honnappa Nagarahalli
2020-10-06 13:29 ` [dpdk-dev] [RFC v2 1/1] " Honnappa Nagarahalli
2020-10-12 16:20 ` Ananyev, Konstantin
2020-10-12 22:31 4% ` Honnappa Nagarahalli
2020-10-13 11:38 0% ` Ananyev, Konstantin
2020-06-12 21:24 [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites McDaniel, Timothy
2020-10-29 14:57 3% ` [dpdk-dev] [PATCH v7 00/23] Add DLB PMD Timothy McDaniel
2020-10-30 9:40 3% ` [dpdk-dev] [PATCH v8 " Timothy McDaniel
2020-10-30 12:41 3% ` [dpdk-dev] [PATCH v9 " Timothy McDaniel
2020-10-30 18:27 3% ` [dpdk-dev] [PATCH v10 " Timothy McDaniel
2020-10-30 23:41 3% ` [dpdk-dev] [PATCH v11 " Timothy McDaniel
2020-10-31 1:19 3% ` [dpdk-dev] [PATCH v12 " Timothy McDaniel
2020-10-31 2:12 3% ` [dpdk-dev] [PATCH v13 " Timothy McDaniel
2020-10-31 12:49 0% ` Jerin Jacob
2020-10-31 18:17 3% ` [dpdk-dev] [PATCH v14 " Timothy McDaniel
2020-11-01 19:26 3% ` [dpdk-dev] [PATCH v15 " Timothy McDaniel
2020-11-01 23:29 3% ` [dpdk-dev] [PATCH v16 " Timothy McDaniel
2020-11-02 14:07 0% ` Jerin Jacob
2020-06-25 16:03 [dpdk-dev] [PATCH 0/2] ethdev: tunnel offload model Gregory Etelson
2020-10-16 12:51 ` [dpdk-dev] [PATCH v8 0/3] Tunnel Offload API Gregory Etelson
2020-10-16 12:51 ` [dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model Gregory Etelson
2020-10-16 15:41 3% ` Kinsella, Ray
2020-07-30 19:49 [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites McDaniel, Timothy
2020-10-17 19:03 3% ` [dpdk-dev] [PATCH v5 00/22] Add DLB PMD Timothy McDaniel
2020-10-23 18:32 3% ` [dpdk-dev] [PATCH v6 00/23] " Timothy McDaniel
2020-08-07 12:29 [dpdk-dev] [PATCH 20.11 00/19] remove make support in DPDK Ciara Power
2020-10-21 8:17 ` [dpdk-dev] [PATCH v7 00/14] " Ciara Power
2020-10-21 8:17 9% ` [dpdk-dev] [PATCH v7 12/14] doc: remove references to make from contributing guide Ciara Power
2020-10-21 8:17 2% ` [dpdk-dev] [PATCH v7 14/14] doc: update patch cheatsheet to use meson Ciara Power
2020-08-17 17:49 [dpdk-dev] [RFC] ethdev: introduce Rx buffer split Slava Ovsiienko
2020-10-14 18:11 ` [dpdk-dev] [PATCH v6 0/6] " Viacheslav Ovsiienko
2020-10-14 18:11 ` [dpdk-dev] [PATCH v6 1/6] " Viacheslav Ovsiienko
2020-10-14 18:57 ` Jerin Jacob
2020-10-15 7:43 ` Slava Ovsiienko
2020-10-15 9:27 3% ` Jerin Jacob
2020-10-15 10:27 3% ` Jerin Jacob
2020-10-15 10:51 3% ` Slava Ovsiienko
2020-10-15 11:26 0% ` Jerin Jacob
2020-10-15 11:36 0% ` Ferruh Yigit
2020-10-15 11:49 3% ` Slava Ovsiienko
2020-10-15 12:49 0% ` Thomas Monjalon
2020-10-15 13:07 0% ` Andrew Rybchenko
2020-10-15 13:57 0% ` Slava Ovsiienko
2020-10-15 20:22 0% ` Slava Ovsiienko
2020-10-15 9:49 ` Andrew Rybchenko
2020-10-15 10:34 3% ` Slava Ovsiienko
2020-10-15 11:09 0% ` Andrew Rybchenko
2020-10-15 14:39 0% ` Slava Ovsiienko
2020-10-16 10:22 ` [dpdk-dev] [PATCH v9 0/6] " Viacheslav Ovsiienko
2020-10-16 10:22 ` [dpdk-dev] [PATCH v9 1/6] " Viacheslav Ovsiienko
2020-10-16 11:21 4% ` Ferruh Yigit
2020-10-16 13:08 0% ` Slava Ovsiienko
2020-09-03 20:09 [dpdk-dev] [PATCH] security: update session create API akhil.goyal
[not found] ` <CGME20201010221145eucas1p12bd7152a21d291cc91a97fb7849e33d0@eucas1p1.samsung.com>
2020-10-10 22:11 ` [dpdk-dev] [PATCH v2] " Akhil Goyal
2020-10-13 2:12 0% ` Lukasz Wojciechowski
2020-10-14 18:56 2% ` [dpdk-dev] [PATCH v3] " Akhil Goyal
2020-10-15 1:11 0% ` Lukasz Wojciechowski
2020-09-07 8:15 [dpdk-dev] [PATCH 0/2] LPM changes Ruifeng Wang
2020-09-07 8:15 ` [dpdk-dev] [PATCH 2/2] lpm: hide internal data Ruifeng Wang
2020-09-15 16:02 ` Bruce Richardson
2020-09-15 16:28 ` Medvedkin, Vladimir
2020-09-16 3:17 ` Ruifeng Wang
2020-09-30 8:45 ` Kevin Traynor
2020-10-09 6:54 ` Ruifeng Wang
2020-10-13 13:53 0% ` Kevin Traynor
2020-10-13 14:58 0% ` Michel Machado
2020-10-13 15:41 0% ` Medvedkin, Vladimir
2020-10-13 17:46 0% ` Michel Machado
2020-10-13 19:06 0% ` Medvedkin, Vladimir
2020-10-13 19:48 0% ` Michel Machado
2020-10-14 13:10 0% ` Medvedkin, Vladimir
2020-10-14 23:57 0% ` Honnappa Nagarahalli
2020-10-19 17:53 0% ` Honnappa Nagarahalli
2020-10-21 3:02 ` [dpdk-dev] [PATCH v2 0/2] LPM changes Ruifeng Wang
2020-10-21 3:02 5% ` [dpdk-dev] [PATCH v2 2/2] lpm: hide internal data Ruifeng Wang
2020-10-21 7:58 0% ` Thomas Monjalon
2020-10-21 8:15 0% ` Ruifeng Wang
2020-10-23 9:38 ` [dpdk-dev] [PATCH v3 0/2] LPM changes David Marchand
2020-10-23 9:38 3% ` [dpdk-dev] [PATCH v3 2/2] lpm: hide internal data David Marchand
2020-09-09 20:30 [dpdk-dev] [RFC 0/3] introduce Stateful Flow Table Andrey Vesnovaty
2020-11-04 12:59 ` [dpdk-dev] [PATCH v2 0/2] introduce stateful flow table Ori Kam
2020-11-04 12:59 1% ` [dpdk-dev] [PATCH v2 2/2] ethdev: introduce sft lib Ori Kam
2020-11-04 13:17 ` [dpdk-dev] [RFC v3 0/2] introduce stateful flow table Ori Kam
2020-11-04 13:17 1% ` [dpdk-dev] [RFC v3 2/2] ethdev: introduce sft lib Ori Kam
2020-09-11 16:58 [dpdk-dev] [PATCH 1/2] eventdev: implement ABI change Timothy McDaniel
2020-10-14 21:36 9% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-14 21:36 2% ` [dpdk-dev] [PATCH 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-14 21:36 6% ` [dpdk-dev] [PATCH 2/2] eventdev: update app and examples for new eventdev ABI Timothy McDaniel
2020-10-15 14:26 7% ` [dpdk-dev] [PATCH 0/2] Eventdev ABI changes for DLB/DLB2 Jerin Jacob
2020-10-15 14:38 4% ` McDaniel, Timothy
2020-10-15 17:31 9% ` [dpdk-dev] [PATCH 0/3] " Timothy McDaniel
2020-10-15 17:31 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-15 17:31 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
2020-10-15 17:31 13% ` [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes Timothy McDaniel
2020-10-15 18:07 9% ` [dpdk-dev] [PATCH 0/3] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-15 18:07 1% ` [dpdk-dev] [PATCH 1/3] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-15 18:07 4% ` [dpdk-dev] [PATCH 2/3] doc: remove eventdev ABI change announcement Timothy McDaniel
2020-10-15 18:27 4% ` Jerin Jacob
2020-10-15 18:07 13% ` [dpdk-dev] [PATCH 3/3] doc: announce new eventdev ABI changes Timothy McDaniel
2020-09-11 16:58 [dpdk-dev] [PATCH 2/2] eventdev: update app and examples for new eventdev ABI Timothy McDaniel
2020-10-14 17:33 6% ` [dpdk-dev] [PATCH v3] " Timothy McDaniel
2020-10-14 20:01 4% ` Jerin Jacob
2020-09-11 19:06 [dpdk-dev] [PATCH 00/15] Replace terms master/slave lcore with main/worker lcore Stephen Hemminger
2020-10-14 15:27 ` [dpdk-dev] [PATCH v6 00/18] Replace terms master/slave Stephen Hemminger
2020-10-14 15:27 1% ` [dpdk-dev] [PATCH v6 03/18] eal: rename lcore word choices Stephen Hemminger
2020-10-15 22:57 ` [dpdk-dev] [PATCH v7 00/20] Replace terms master/slave Stephen Hemminger
2020-10-15 22:57 1% ` [dpdk-dev] [PATCH v7 03/20] eal: rename lcore word choices Stephen Hemminger
2020-09-11 20:26 [dpdk-dev] [PATCH 01/22] event/dlb2: add meson build infrastructure Timothy McDaniel
2020-10-29 15:24 ` [dpdk-dev] [PATCH v4 00/23] Add DLB2 PMD Timothy McDaniel
2020-10-29 15:24 ` [dpdk-dev] [PATCH v4 03/23] event/dlb2: add private data structures and constants Timothy McDaniel
2020-10-29 15:29 3% ` Stephen Hemminger
2020-10-29 16:07 0% ` McDaniel, Timothy
2020-09-14 18:19 [dpdk-dev] [PATCH v2 00/17] Replace terms master/slave Stephen Hemminger
2020-10-13 15:25 ` [dpdk-dev] [PATCH v5 00/18] " Stephen Hemminger
2020-10-13 15:25 1% ` [dpdk-dev] [PATCH v5 03/18] eal: rename lcore word choices Stephen Hemminger
2020-09-15 16:50 [dpdk-dev] [PATCH v2 00/12] acl: introduce AVX512 classify method Konstantin Ananyev
2020-10-05 18:45 ` [dpdk-dev] [PATCH v3 00/14] acl: introduce AVX512 classify methods Konstantin Ananyev
2020-10-06 15:05 ` David Marchand
2020-10-06 16:07 ` Ananyev, Konstantin
2020-10-14 9:23 4% ` Kinsella, Ray
2020-09-16 10:40 [dpdk-dev] [PATCH v3] mbuf: minor cleanup Morten Brørup
2020-10-07 9:16 ` Olivier Matz
2020-10-20 11:55 0% ` Thomas Monjalon
2020-11-04 22:17 0% ` Morten Brørup
2020-09-16 16:44 [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility Bruce Richardson
2020-10-14 14:12 ` [dpdk-dev] [PATCH v3 0/7] Rework build macros Bruce Richardson
2020-10-14 14:13 ` [dpdk-dev] [PATCH v3 6/7] build: standardize component names and defines Bruce Richardson
2020-10-15 10:30 ` Luca Boccassi
2020-10-15 11:18 ` Bruce Richardson
2020-10-15 13:05 3% ` Luca Boccassi
2020-10-15 14:03 3% ` Bruce Richardson
2020-10-15 15:32 0% ` Luca Boccassi
2020-10-15 15:34 0% ` Bruce Richardson
2020-09-22 14:31 [dpdk-dev] [PATCH 0/8] replace blacklist/whitelist with block/allow Stephen Hemminger
2020-10-20 16:20 ` [dpdk-dev] [PATCH v2 0/5] " Stephen Hemminger
2020-10-20 16:20 1% ` [dpdk-dev] [PATCH v2 5/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-10-22 14:39 ` [dpdk-dev] [PATCH v3 0/5] replace blacklist/whitelist with block/allow Stephen Hemminger
2020-10-22 14:39 1% ` [dpdk-dev] [PATCH v3 5/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-10-22 20:39 ` [dpdk-dev] [PATCH v4 0/5] replace blacklist/whitelist with block/allow Stephen Hemminger
2020-10-22 20:40 1% ` [dpdk-dev] [PATCH v4 5/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-10-24 1:01 ` [dpdk-dev] [PATCH v5 0/5] replace blacklist/whitelist with block/allow Stephen Hemminger
2020-10-24 1:01 1% ` [dpdk-dev] [PATCH v5 5/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-10-25 16:57 ` [dpdk-dev] [PATCH v6 0/5] replace blacklist/whitelist with allow/block Stephen Hemminger
2020-10-25 16:57 1% ` [dpdk-dev] [PATCH v6 5/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-10-25 20:57 ` [dpdk-dev] [PATCH v7 0/5] replace blacklist/whitelist with allow/block Stephen Hemminger
2020-10-25 20:57 1% ` [dpdk-dev] [PATCH v7 4/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-10-25 21:15 ` [dpdk-dev] [PATCH v8 0/5] replace blacklist/whitelist with allow/block Stephen Hemminger
2020-10-25 21:15 1% ` [dpdk-dev] [PATCH v8 4/5] doc: change references to blacklist and whitelist Stephen Hemminger
2020-11-05 22:35 ` [dpdk-dev] [PATCH v9 0/6] replace blacklist/whitelist with allow/block Stephen Hemminger
2020-11-05 22:36 4% ` [dpdk-dev] [PATCH v9 6/6] doc: update release notes now for block allow changes Stephen Hemminger
2020-11-10 22:55 ` [dpdk-dev] [PATCH v10 0/7] replace blacklist/whitelist with allow/block Stephen Hemminger
2020-11-10 22:55 1% ` [dpdk-dev] [PATCH v10 4/7] doc: update documentation to reflect new options Stephen Hemminger
2020-09-30 14:10 [dpdk-dev] [PATCH 00/10] support match on L3 fragmented packets Dekel Peled
2020-10-14 16:35 3% ` [dpdk-dev] [PATCH v7 0/5] " Dekel Peled
2020-10-14 16:35 4% ` [dpdk-dev] [PATCH v7 1/5] ethdev: add extensions attributes to IPv6 item Dekel Peled
2020-10-14 17:18 0% ` [dpdk-dev] [PATCH v7 0/5] support match on L3 fragmented packets Ferruh Yigit
2020-10-01 0:25 [dpdk-dev] [PATCH 0/4] introduce support for hairpin between two ports Bing Zhao
2020-10-15 5:35 ` [dpdk-dev] [PATCH v5 0/5] " Bing Zhao
2020-10-15 5:35 4% ` [dpdk-dev] [PATCH v5 2/5] ethdev: add new attributes to hairpin config Bing Zhao
2020-10-15 13:08 ` [dpdk-dev] [PATCH v6 0/5] introduce support for hairpin between two ports Bing Zhao
2020-10-15 13:08 4% ` [dpdk-dev] [PATCH v6 2/5] ethdev: add new attributes to hairpin config Bing Zhao
2020-10-05 20:27 [dpdk-dev] [PATCH v2 0/2] Eventdev ABI changes for DLB/DLB2 Timothy McDaniel
2020-10-05 20:27 ` [dpdk-dev] [PATCH v2 1/2] eventdev: eventdev: express DLB/DLB2 PMD constraints Timothy McDaniel
2020-10-12 19:06 0% ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2020-10-05 20:27 ` [dpdk-dev] [PATCH v2 2/2] eventdev: update app and examples for new eventdev ABI Timothy McDaniel
2020-10-06 8:26 ` Van Haaren, Harry
2020-10-12 19:09 4% ` Pavan Nikhilesh Bhagavatula
2020-10-13 19:20 4% ` Jerin Jacob
2020-10-07 10:53 [dpdk-dev] [PATCH v4 00/11] support match on L3 fragmented packets Dekel Peled
2020-10-12 10:42 ` [dpdk-dev] [PATCH v5 " Dekel Peled
2020-10-12 10:43 ` [dpdk-dev] [PATCH v5 10/11] doc: update release notes for MLX5 L3 frag support Dekel Peled
2020-10-12 19:29 0% ` Thomas Monjalon
2020-10-13 13:32 3% ` [dpdk-dev] [PATCH v6 0/5] support match on L3 fragmented packets Dekel Peled
2020-10-13 13:32 4% ` [dpdk-dev] [PATCH v6 1/5] ethdev: add extensions attributes to IPv6 item Dekel Peled
2020-10-07 14:09 [dpdk-dev] [PATCH v8 0/8] Enable dynamic config of subport bandwidth Savinay Dharmappa
2020-10-09 12:39 ` [dpdk-dev] [PATCH v9 " Savinay Dharmappa
2020-10-11 20:11 ` Thomas Monjalon
2020-10-12 5:24 ` Dharmappa, Savinay
2020-10-12 23:08 0% ` Dharmappa, Savinay
2020-10-13 13:56 0% ` Dharmappa, Savinay
2020-10-07 16:45 [dpdk-dev] [PATCH v4 0/8] Add Crypto PMD for Broadcom`s FlexSparc devices Vikas Gupta
2020-10-07 17:18 ` [dpdk-dev] [PATCH v5 " Vikas Gupta
2020-10-07 17:18 ` [dpdk-dev] [PATCH v5 1/8] crypto/bcmfs: add BCMFS driver Vikas Gupta
2020-10-15 0:55 3% ` Thomas Monjalon
2020-10-08 12:05 [dpdk-dev] [PATCH v3 0/6] introduce support for hairpin between two ports Bing Zhao
2020-10-13 16:19 ` [dpdk-dev] [PATCH v4 0/5] " Bing Zhao
2020-10-13 16:19 4% ` [dpdk-dev] [PATCH v4 2/5] ethdev: add new attributes to hairpin config Bing Zhao
2020-10-12 8:08 [dpdk-dev] [PATCH v5 0/4] devtools: abi breakage checks Conor Walsh
2020-10-12 13:03 ` [dpdk-dev] [PATCH v6 " Conor Walsh
2020-10-12 13:03 ` [dpdk-dev] [PATCH v6 1/4] devtools: add generation of compressed abi dump archives Conor Walsh
2020-10-14 9:38 4% ` Kinsella, Ray
2020-10-12 13:03 ` [dpdk-dev] [PATCH v6 2/4] devtools: abi and UX changes for test-meson-builds.sh Conor Walsh
2020-10-14 9:43 4% ` Kinsella, Ray
2020-10-12 13:03 ` [dpdk-dev] [PATCH v6 3/4] devtools: change dump file not found to warning in check-abi.sh Conor Walsh
2020-10-14 9:44 4% ` Kinsella, Ray
2020-10-12 13:03 ` [dpdk-dev] [PATCH v6 4/4] doc: test-meson-builds.sh doc updates Conor Walsh
2020-10-14 9:46 0% ` Kinsella, Ray
2020-10-14 9:37 4% ` [dpdk-dev] [PATCH v6 0/4] devtools: abi breakage checks Kinsella, Ray
2020-10-14 10:33 4% ` Walsh, Conor
2020-10-14 10:41 10% ` [dpdk-dev] [PATCH v7 " Conor Walsh
2020-10-14 10:41 21% ` [dpdk-dev] [PATCH v7 1/4] devtools: add generation of compressed abi dump archives Conor Walsh
2020-10-15 10:15 4% ` Kinsella, Ray
2020-10-14 10:41 26% ` [dpdk-dev] [PATCH v7 2/4] devtools: abi and UX changes for test-meson-builds.sh Conor Walsh
2020-10-15 10:16 4% ` Kinsella, Ray
2020-10-14 10:41 15% ` [dpdk-dev] [PATCH v7 3/4] devtools: change not found to warning check-abi.sh Conor Walsh
2020-10-14 10:41 18% ` [dpdk-dev] [PATCH v7 4/4] doc: test-meson-builds.sh doc updates Conor Walsh
[not found] ` <7206c209-ed4a-2aeb-12d8-ee162ef92596@ashroe.eu>
[not found] ` <CAJFAV8wmpft6XLRg1RAL+d4ibbJVrR9C0ghkE-kqyig_q_Meeg@mail.gmail.com>
2020-11-03 10:07 9% ` [dpdk-dev] [PATCH v7 0/4] devtools: abi breakage checks Kinsella, Ray
2020-11-10 12:53 8% ` David Marchand
2020-11-10 13:54 4% ` Kinsella, Ray
2020-11-10 13:57 4% ` David Marchand
2020-10-12 19:21 [dpdk-dev] [PATCH v4 0/2] remove list end enumerators Arek Kusztal
2020-10-12 19:21 7% ` [dpdk-dev] [PATCH v4 1/2] cryptodev: remove crypto " Arek Kusztal
2020-10-14 13:28 [dpdk-dev] [PATCH 00/11] ethdev: change device stop to return status Andrew Rybchenko
2020-10-15 13:30 ` [dpdk-dev] [PATCH v2 " Andrew Rybchenko
2020-10-15 13:30 4% ` [dpdk-dev] [PATCH v2 01/11] ethdev: change eth dev stop function to return int Andrew Rybchenko
2020-10-16 9:22 0% ` Ferruh Yigit
2020-10-16 11:20 3% ` Kinsella, Ray
2020-10-16 17:13 0% ` Andrew Rybchenko
2020-10-19 9:37 0% ` Kinsella, Ray
2020-10-15 9:56 11% [dpdk-dev] [PATCH] cryptodev: revert support for 20.0 node Ray Kinsella
2020-10-15 10:08 0% ` David Marchand
2020-10-15 10:10 3% ` Kinsella, Ray
2020-10-15 16:00 [dpdk-dev] performance degradation with fpic Ali Alnubani
2020-10-15 17:08 ` Bruce Richardson
2020-10-15 17:14 ` Thomas Monjalon
2020-10-15 21:44 ` Stephen Hemminger
2020-10-16 8:35 3% ` Bruce Richardson
2020-10-19 2:57 [dpdk-dev] [v3 0/2] support enqueue callbacks on cryptodev Abhinandan Gujjar
2020-10-19 2:57 ` [dpdk-dev] [v3 1/2] cryptodev: support enqueue callback functions Abhinandan Gujjar
2020-10-21 19:33 3% ` Ananyev, Konstantin
2020-10-23 12:36 0% ` Gujjar, Abhinandan S
2020-10-22 7:47 3% [dpdk-dev] [PATCH] build: fix version map file references in documentation David Marchand
2020-10-22 7:52 0% ` Kinsella, Ray
2020-10-22 12:11 3% ` David Marchand
2020-10-22 14:24 0% ` Kinsella, Ray
2020-10-23 16:07 33% [dpdk-dev] [PATCH v1] doc: update abi version references Ray Kinsella
2020-10-23 16:51 7% ` David Marchand
2020-10-26 18:27 4% ` Kinsella, Ray
2020-10-26 19:23 33% ` [dpdk-dev] [PATCH] " Ray Kinsella
2020-10-26 19:31 33% ` [dpdk-dev] [PATCH v3] " Ray Kinsella
2020-10-27 11:40 4% ` David Marchand
2020-10-25 9:44 [dpdk-dev] [v4 0/3] support enqueue callbacks on cryptodev Abhinandan Gujjar
2020-10-25 9:44 ` [dpdk-dev] [v4 1/3] cryptodev: support enqueue callback functions Abhinandan Gujjar
2020-10-27 18:19 4% ` Akhil Goyal
2020-10-27 19:16 0% ` Gujjar, Abhinandan S
2020-10-27 19:26 0% ` Akhil Goyal
2020-10-27 19:41 0% ` Gujjar, Abhinandan S
2020-10-27 18:28 4% ` Akhil Goyal
2020-10-28 8:20 0% ` Gujjar, Abhinandan S
2020-10-28 12:55 0% ` Ananyev, Konstantin
2020-10-28 14:28 0% ` Akhil Goyal
2020-10-28 14:52 0% ` Ananyev, Konstantin
2020-10-28 15:11 3% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2020-10-28 15:22 4% ` Honnappa Nagarahalli
2020-10-29 13:52 0% ` Gujjar, Abhinandan S
2020-10-29 14:00 0% ` Akhil Goyal
2020-10-30 4:24 0% ` Gujjar, Abhinandan S
2020-10-30 17:18 0% ` Gujjar, Abhinandan S
2020-10-29 14:26 3% ` Kinsella, Ray
2020-10-26 6:47 3% [dpdk-dev] [PATCH v3] gso: fix free issue of mbuf gso segments attach to yang_y_yi
2020-10-27 19:55 0% ` Ananyev, Konstantin
2020-10-28 0:51 0% ` Hu, Jiayu
2020-10-28 23:10 [dpdk-dev] [v6 0/2] support enqueue & dequeue callbacks on cryptodev Abhinandan Gujjar
2020-10-28 23:10 2% ` [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions Abhinandan Gujjar
2020-10-29 8:52 [dpdk-dev] [PATCH] ethdev: deprecate shared counters using action attribute Andrew Rybchenko
2020-10-29 16:11 ` Thomas Monjalon
2020-11-01 7:49 ` Ori Kam
2020-11-03 17:21 3% ` Thomas Monjalon
2020-11-03 17:26 0% ` Andrew Rybchenko
2020-10-29 9:27 [dpdk-dev] [PATCH 00/15] remove mbuf timestamp Thomas Monjalon
2020-10-29 9:27 ` [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotter first half Thomas Monjalon
2020-10-29 14:42 4% ` Kinsella, Ray
2020-10-31 20:40 ` [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst half Thomas Monjalon
2020-11-01 9:12 ` Morten Brørup
2020-11-01 16:38 ` Thomas Monjalon
2020-11-01 20:59 3% ` Morten Brørup
2020-11-02 15:58 0% ` Thomas Monjalon
2020-11-03 12:10 4% ` Morten Brørup
2020-11-03 12:25 0% ` Bruce Richardson
2020-11-03 13:46 0% ` Morten Brørup
2020-11-03 13:50 0% ` Bruce Richardson
2020-11-03 14:03 0% ` Morten Brørup
2020-11-03 14:02 0% ` Slava Ovsiienko
2020-11-03 15:03 0% ` Morten Brørup
2020-11-04 15:00 0% ` Olivier Matz
2020-11-05 0:25 0% ` Ananyev, Konstantin
2020-11-05 9:35 3% ` Morten Brørup
2020-11-05 10:29 0% ` Bruce Richardson
2020-10-29 12:22 3% [dpdk-dev] DPDK Release Status Meeting 29/10/2020 Ferruh Yigit
2020-11-02 16:17 3% [dpdk-dev] Ionic PMD - can we still get patches into a 20.02 stable? Andrew Boyer
2020-11-02 16:25 0% ` Burakov, Anatoly
2020-11-02 16:31 0% ` Ferruh Yigit
2020-11-03 14:25 4% [dpdk-dev] Minutes of Technical Board Meeting, 2020-10-21 Jerin Jacob Kollanukkaran
2020-11-04 17:00 [dpdk-dev] [PATCH] mbuf: fix reset on mbuf free Olivier Matz
2020-11-05 0:15 ` Ananyev, Konstantin
2020-11-05 7:46 ` Olivier Matz
2020-11-05 8:26 ` Andrew Rybchenko
2020-11-05 9:10 ` Olivier Matz
2020-11-05 11:34 ` Ananyev, Konstantin
2020-11-05 12:31 ` Olivier Matz
2020-11-05 13:14 ` Ananyev, Konstantin
2020-11-05 13:24 ` Olivier Matz
2020-11-05 13:55 ` Ananyev, Konstantin
2020-11-05 16:30 ` Morten Brørup
2020-11-05 23:55 ` Ananyev, Konstantin
2020-11-06 7:52 4% ` Morten Brørup
2020-11-06 8:20 0% ` Olivier Matz
2020-11-06 8:50 0% ` Morten Brørup
2020-11-06 10:04 0% ` Olivier Matz
2020-11-06 10:07 0% ` Morten Brørup
2020-11-06 11:53 0% ` Ananyev, Konstantin
2020-11-06 12:23 0% ` Morten Brørup
2020-11-08 14:16 0% ` Andrew Rybchenko
2020-11-08 14:19 0% ` Ananyev, Konstantin
2020-11-10 16:26 0% ` Olivier Matz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).