RE: [PATCH v2] eal: add notes to SMP memory barrier APIs

[Ruifeng Wang]

> -Original Message-
> From: Mattias Rönnblom 
> Sent: Friday, June 30, 2023 3:44 AM
> To: Ruifeng Wang ; tho...@monjalon.net; 
> david.march...@redhat.com
> Cc: dev@dpdk.org; roret...@linux.microsoft.com; 
> konstantin.v.anan...@yandex.ru; Honnappa
> Nagarahalli ; nd 
> Subject: Re: [PATCH v2] eal: add notes to SMP memory barrier APIs
> 
> On 2023-06-26 09:12, Ruifeng Wang wrote:
> > The rte_smp_xx() APIs are deprecated. But it is not mentioned in the
> > function header.
> > Added notes in function header for clarification.
> >
> > Signed-off-by: Ruifeng Wang 
> > ---
> > v2: Made the notes more specific.
> >
> >   lib/eal/include/generic/rte_atomic.h | 19 +++
> >   1 file changed, 19 insertions(+)
> >
> > diff --git a/lib/eal/include/generic/rte_atomic.h
> > b/lib/eal/include/generic/rte_atomic.h
> > index 58df843c54..35e0041ce6 100644
> > --- a/lib/eal/include/generic/rte_atomic.h
> > +++ b/lib/eal/include/generic/rte_atomic.h
> > @@ -55,6 +55,11 @@ static inline void rte_rmb(void);
> >* Guarantees that the LOAD and STORE operations that precede the
> >* rte_smp_mb() call are globally visible across the lcores
> >* before the LOAD and STORE operations that follows it.
> > + *
> > + * @note
> > + *  This function is deprecated. It provides fence synchronization
> > + *  primitive but doesn't take memory order parameter.
> > + *  rte_atomic_thread_fence() should be used instead.
> 
> I can't see why coding the memory model semantics into the name, rather than 
> by
> specification-by-means-of-a-parameter, could be the real issue.
> Could you explain? Seems like just different syntax to me.

Yes, rte_smp_xx and rte_atomic_thread_fence have different syntaxes.

The compiler atomic builtins were accepted for memory ordering. It comprises 
atomic arithmetic,
atomic load/store, and atomic fence. It is simpler and clearer to do memory 
ordering by using
the atomic builtins whenever possible.
rte_smp_xx has functionality overlap with atomic fence builtins but with 
different memory model
semantics and different syntaxes. Because of the differences, it will make 
memory ordering a little
more complex if rte_smp_xx is kept aside atomic builtins suite.

> 
> The old  atomic arithmetic and atomic load/store operations 
> suffered from
> unspecified semantics in regards to any ordering they imposed on other memory 
> accesses. I
> guess that shortcoming could be described as a "missing parameter", although 
> that too
> would be misleading. Unclear semantics seems not be the case for the 
> kernel-style barriers
> though.
> 
> >*/
> >   static inline void rte_smp_mb(void);
> >
> > @@ -64,6 +69,11 @@ static inline void rte_smp_mb(void);
> >* Guarantees that the STORE operations that precede the
> >* rte_smp_wmb() call are globally visible across the lcores
> >* before the STORE operations that follows it.
> > + *
> > + * @note
> > + *  This function is deprecated. It provides fence synchronization
> > + *  primitive but doesn't take memory order parameter.
> > + *  rte_atomic_thread_fence() should be used instead.
> >*/
> >   static inline void rte_smp_wmb(void);
> >
> > @@ -73,6 +83,11 @@ static inline void rte_smp_wmb(void);
> >* Guarantees that the LOAD operations that precede the
> >* rte_smp_rmb() call are globally visible across the lcores
> >* before the LOAD operations that follows it.
> > + *
> > + * @note
> > + *  This function is deprecated. It provides fence synchronization
> > + *  primitive but doesn't take memory order parameter.
> > + *  rte_atomic_thread_fence() should be used instead.
> >*/
> >   static inline void rte_smp_rmb(void);
> >   ///@}
> > @@ -122,6 +137,10 @@ static inline void rte_io_rmb(void);
> >
> >   /**
> >* Synchronization fence between threads based on the specified memory 
> > order.
> > + *
> > + * @param memorder
> > + *   The memory order defined by compiler atomic builtin at:
> > + *   https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> >*/
> >   static inline void rte_atomic_thread_fence(int memorder);
> >

RE: [EXT] [PATCH] eal/interrupts: Allow UIO interrupts when using igb_uio

[Harman Kalra]

>  Some drivers and devices(ex: igc + i225/i226) use RTE_INTR_HANDLE_UIO
> handler when captured under igb_uio so just let them use it.
> 
> Signed-off-by: Vladimir Ratnikov 


Reviewed-by: Harman Kalra 

Thanks
Harman 

> ---
>  lib/eal/linux/eal_interrupts.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/eal/linux/eal_interrupts.c b/lib/eal/linux/eal_interrupts.c
> index c9881143be..037db09cfd 100644
> --- a/lib/eal/linux/eal_interrupts.c
> +++ b/lib/eal/linux/eal_interrupts.c
> @@ -1596,6 +1596,9 @@ rte_intr_cap_multiple(struct rte_intr_handle
> *intr_handle)
>   if (rte_intr_type_get(intr_handle) == RTE_INTR_HANDLE_VDEV)
>   return 1;
> 
> + if (rte_intr_type_get(intr_handle) == RTE_INTR_HANDLE_UIO)
> + return 1;
> +
>   return 0;
>  }
> 
> --
> 2.34.1

Re: [PATCH v5 2/2] ethdev: support xstats reset telemetry command

[Thomas Monjalon]

03/07/2023 05:58, fengchengwen:
> 
> On 2023/2/20 21:05, Thomas Monjalon wrote:
> > 17/02/2023 10:44, fengchengwen:
> >> On 2023/2/16 20:54, Bruce Richardson wrote:
> >>> On Thu, Feb 16, 2023 at 08:42:34PM +0800, fengchengwen wrote:
>  On 2023/2/16 20:06, Ferruh Yigit wrote:
> > On 2/16/2023 11:53 AM, fengchengwen wrote:
> >> On 2023/2/15 11:19, Dongdong Liu wrote:
> >>> Hi Chengwen
> >>>
> >>> On 2023/2/9 10:32, Chengwen Feng wrote:
>  The xstats reset is useful for debugging, so add it to the ethdev
>  telemetry command lists.
> 
>  Signed-off-by: Chengwen Feng 
> >>> This patch looks good, so
> >>> Reviewed-by: Dongdong Liu 
> >>>
> >>> A minior question
> >>> Do we need to support stats reset ?
> >>
> >> Stats is contained by xstats, and future direction I think is xstats.
> >> So I think we don't need support stats reset.
> >>
> >
> > I have similar question with Dongdong, readonly values are safe for
> > telemetry, but modifying data can be more tricky since we don't have
> > locking in ethdev APIs, this can cause concurrency issues.
> 
>  Yes, it indeed has concurrency issues.
> 
> >
> > Overall do we want telemetry go that way and become something that
> > alters ethdev data/config?
> 
>  There are at least two part of data: config and status.
>  For stats (which belong status data) could help for debugging, I think 
>  it's acceptable.
> 
>  As for concurrency issues. People should know what to do and when to do, 
>  just like
>  the don't invoke config API (e.g. dev_configure/dev_start/...) 
>  concurrency.
> 
> >>> While this is probably ok for now, I think in next release we should look
> >>> to add some sort of support for locking for destructive ops in a future
> >>> release. For example, we could:
> >>>
> >>> 1. Add support for marking a callback as "destructive" and only allow it 
> >>> to
> >>> be called if only one connection is present or
> >>>
> >>> 2. Make it possible for callbacks to query the number of connections so
> >>> that the callback itself is non-destructive in more than one connection is
> >>> open.
> >>>
> >>> [Both of these will require locking support so that new connections aren't
> >>> openned when the callback is in-flight!]
> >>
> >> Except telemetry, the application may have other console could execute 
> >> DPDK API.
> >> So I think trying to keep it simple, it's up to the user to invoke.
> > 
> > No, the user should not be responsible for concurrency issues.
> > We can ask the app developper to take care,
> > but not to the user who has no control on what happens in the app.
> > 
> > On a more general note, I feel the expansion of telemetry is not controlled 
> > enough.
> > I would like to stop on adding more telemetry until we have a clear 
> > guideline
> > about what is telemetry for and how to use it.
> 
> Hi Thomas,
> 
> Should this be discussed on TB?

What would be your question exactly?

RE: [PATCH] net/cpfl: fix RSS lookup table configuration

[Wu, Jingjing]

> -Original Message-
> From: Xing, Beilei 
> Sent: Monday, July 3, 2023 7:28 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org; Xing, Beilei 
> Subject: [PATCH] net/cpfl: fix RSS lookup table configuration
> 
> From: Beilei Xing 
> 
> Ethdev Rx queues includes normal data queues and hairpin queues,
> RSS should direct traffic only to the normal data queues.
> 
> Fixes: fda03330fcaa ("net/cpfl: support hairpin queue configuration")
> 
> Signed-off-by: Beilei Xing 

Acked-by: Jingjing Wu 

[PATCH v1] graph: fix graph model check in core binding

[Zhirun Yan]

Fix graph model check in core binding with graph.
Update release notes for new mcore dispatch model.

Signed-off-by: Zhirun Yan 
---
 doc/guides/rel_notes/release_23_07.rst | 12 
 lib/graph/graph.c  |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index 4459144140..adaecb3e7c 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -185,6 +185,13 @@ New Features
 
   * Added SM2 algorithm support in asymmetric crypto operations.
 
+* **Added mcore dispatch model in rte_graph library.**
+
+  * Added set, get and validate model APIs to enhance graph framework
+to chose different walk models.
+  * Added clone graph, bind graph with lcore and affinity node with
+lcore APIs to support mcore dispatch model.
+
 * **Added PDCP Library.**
 
   Added an experimental library to provide PDCP UL and DL processing of 
packets.
@@ -200,6 +207,11 @@ New Features
 
   Enhanced the GRO library to support TCP packets over IPv6 network.
 
+* **Update l3fwd-graph sample application.**
+
+  Added a new cmdline option ``--model`` which can be used to chose
+  RTC or mcore dispatch model.
+
 
 Removed Items
 -
diff --git a/lib/graph/graph.c b/lib/graph/graph.c
index 0c28d925bc..26f0968a97 100644
--- a/lib/graph/graph.c
+++ b/lib/graph/graph.c
@@ -287,7 +287,7 @@ rte_graph_model_mcore_dispatch_core_bind(rte_graph_t id, 
int lcore)
if (graph->id == id)
break;
 
-   if (graph->graph->model == RTE_GRAPH_MODEL_MCORE_DISPATCH)
+   if (graph->graph->model != RTE_GRAPH_MODEL_MCORE_DISPATCH)
goto fail;
 
graph->lcore_id = lcore;
-- 
2.37.2

Re: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in secondary process

[David Marchand]

On Thu, Jun 29, 2023 at 4:27 AM Miao Li  wrote:
>
> When doing IO port map for legacy device in secondary process,
> vfio_cfg setup for legacy device like vfio_group_fd and vfio_dev_fd
> is missing. So, in secondary process, rte_pci_map_device is added
> for legacy device to setup vfio_cfg and fill in region info like in
> primary process.

I think, in legacy mode, there is no PCI mappable memory.
So there should be no need for this call to rte_pci_map_device.

What is missing is a vfio setup, is this correct?
I'd rather see this issue be fixed in the pci_vfio_ioport_map() function.


>> Fixes: 512e27eeb743 ("net/virtio: move PCI specific dev init to PCI ethdev 
>> init")

This commit only moved code, and at this point, there was no need for
a call to rte_pci_map_device in the secondary process case.
It seems unlikely this is a faulty change.

The recent addition on the vfio side seems a better culprit, but I am
fine with being proven wrong :-).


> Cc: sta...@dpdk.org
>
> Signed-off-by: Miao Li 


-- 
David Marchand

[PATCH] doc: update mlxreg command arguments for recent versions

[Ali Alnubani]

Recent versions of the command require vhca_id and all_vhca
to be set with the --indexes arg.

Signed-off-by: Ali Alnubani 
---
 doc/guides/nics/mlx5.rst | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 7a137d5f6a..68ecdbec15 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1887,9 +1887,15 @@ The procedure below is an example of using a ConnectX-5 
adapter card (pf0) with
 $ ip link set p0 vf 0 trust on
 $ ip link set p0 vf 1 trust on
 
-#. Configure all VFs using mlxreg::
+#. Configure all VFs using mlxreg:
 
-   $ mlxreg -d /dev/mst/mt4121_pciconf0 --reg_name VHCA_TRUST_LEVEL --yes 
--set "all_vhca=0x1,trust_level=0x1"
+  - For MFT >= 4.21::
+
+$ mlxreg -d /dev/mst/mt4121_pciconf0 --reg_name VHCA_TRUST_LEVEL --yes 
--indexes 'all_vhca=0x1,vhca_id=0x0' --set 'trust_level=0x1'
+
+  - For MFT < 4.21::
+
+$ mlxreg -d /dev/mst/mt4121_pciconf0 --reg_name VHCA_TRUST_LEVEL --yes 
--set "all_vhca=0x1,trust_level=0x1"
 
.. note::
 
-- 
2.25.1

[PATCH] doc: fix typos and wording in flow API guide

[Ali Alnubani]

This fixes typos, punctuation and wording in the rte flow API guide.

Fixes: 2f82d143fb31 ("ethdev: add group jump action")
Cc: declan.dohe...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Ali Alnubani 
---
 doc/guides/prog_guide/rte_flow.rst | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 32fc45516a..6dbf5ef0a4 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -148,14 +148,14 @@ Attribute: Group
 Flow rules can be grouped by assigning them a common group number. Groups
 allow a logical hierarchy of flow rule groups (tables) to be defined. These
 groups can be supported virtually in the PMD or in the physical device.
-Group 0 is the default group and this is the only group which flows are
-guarantee to matched against, all subsequent groups can only be reached by
-way of the JUMP action from a matched flow rule.
+Group 0 is the default group and is the only group where flows are
+guaranteed to be matched against. All subsequent groups can only be reached by
+using a JUMP action from a matched flow rule.
 
 Although optional, applications are encouraged to group similar rules as
 much as possible to fully take advantage of hardware capabilities
 (e.g. optimized matching) and work around limitations (e.g. a single pattern
-type possibly allowed in a given group), while being aware that the groups
+type possibly allowed in a given group), while being aware that the groups'
 hierarchies must be programmed explicitly.
 
 Note that support for more than a single group is not guaranteed.
@@ -170,7 +170,7 @@ Priority levels are arbitrary and up to the application, 
they do
 not need to be contiguous nor start from 0, however the maximum number
 varies between devices and may be affected by existing flow rules.
 
-A flow which matches multiple rules in the same group will always matched by
+A flow which matches multiple rules in the same group will always be matched by
 the rule with the highest priority in that group.
 
 If a packet is matched by several rules of a given group for a given
@@ -1755,12 +1755,12 @@ flow group/tables on the device, this action redirects 
the matched flow to
 the specified group on that device.
 
 If a matched flow is redirected to a table which doesn't contain a matching
-rule for that flow then the behavior is undefined and the resulting behavior
-is up to the specific device. Best practice when using groups would be define
+rule for that flow, then the behavior is undefined and the resulting behavior
+is up to the specific device. Best practice when using groups would be to 
define
 a default flow rule for each group which a defines the default actions in that
 group so a consistent behavior is defined.
 
-Defining an action for matched flow in a group to jump to a group which is
+Defining an action for a matched flow in a group to jump to a group which is
 higher in the group hierarchy may not be supported by physical devices,
 depending on how groups are mapped to the physical devices. In the
 definitions of jump actions, applications should be aware that it may be
-- 
2.25.1

[PATCH] doc: fix typos and wording of cuda guide

[Ali Alnubani]

Adds missing punctuation, and improves wording.
Additionally, one of the example commands for adding CUDA
headers to CFLAGS is removed as it's redundant.

Fixes: 24c77594e08f ("gpu/cuda: map GPU memory with GDRCopy")
Fixes: 1306a73b1958 ("gpu/cuda: introduce CUDA driver")
Cc: eagost...@nvidia.com

Signed-off-by: Ali Alnubani 
---
 doc/guides/gpus/cuda.rst | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/doc/guides/gpus/cuda.rst b/doc/guides/gpus/cuda.rst
index 114e3bc8cb..6520c17c3e 100644
--- a/doc/guides/gpus/cuda.rst
+++ b/doc/guides/gpus/cuda.rst
@@ -12,20 +12,19 @@ Information and documentation about these devices can be 
found on the
 Build dependencies
 --
 
-The CUDA GPU driver library has an header-only dependency on ``cuda.h`` and 
``cudaTypedefs.h``.
-To get these headers there are two options:
+The CUDA GPU driver library has a header-only dependency on ``cuda.h`` and 
``cudaTypedefs.h``.
+To get these headers, there are two options:
 
 - Install `CUDA Toolkit `_
   (either regular or stubs installation).
 - Download these two headers from this `CUDA headers
   `_ repository.
 
-You need to indicate to meson where CUDA headers files are through the CFLAGS 
variable.
-Three ways:
+You can point to CUDA header files either with the ``CFLAGS`` environment 
variable,
+or with the ``c_args`` Meson option. Examples:
 
-- Set ``export CFLAGS=-I/usr/local/cuda/include`` before building
-- Add CFLAGS in the meson command line ``CFLAGS=-I/usr/local/cuda/include 
meson setup build``
-- Add the ``-Dc_args`` in meson command line ``meson setup build 
-Dc_args=-I/usr/local/cuda/include``
+- ``CFLAGS=-I/usr/local/cuda/include meson setup build``
+- ``meson setup build -Dc_args=-I/usr/local/cuda/include``
 
 If headers are not found, the CUDA GPU driver library is not built.
 
@@ -46,15 +45,15 @@ A quick recipe to download, build and run GDRCopy library 
and driver:
   $ # Launch gdrdrv kernel module on the system
   $ sudo ./insmod.sh
 
-You need to indicate to meson where GDRCopy headers files are as in case of 
CUDA headers.
+You need to indicate to Meson where GDRCopy header files are as in case of 
CUDA headers.
 An example would be:
 
 .. code-block:: console
 
   $ meson setup build -Dc_args="-I/usr/local/cuda/include 
-I/path/to/gdrcopy/include"
 
-If headers are not found, the CUDA GPU driver library is built without the CPU 
map capability
-and will return error if the application invokes the gpudev 
``rte_gpu_mem_cpu_map`` function.
+If headers are not found, the CUDA GPU driver library is built without the CPU 
map capability,
+and will return an error if the application invokes the gpudev 
``rte_gpu_mem_cpu_map`` function.
 
 
 CUDA Shared Library
@@ -143,7 +142,7 @@ if the address is not in the table the CUDA driver library 
will return an error.
 Features
 
 
-- Register new child devices aka new CUDA Driver contexts.
+- Register new child devices, aka CUDA driver contexts.
 - Allocate memory on the GPU.
 - Register CPU memory to make it visible from GPU.
 
@@ -189,9 +188,10 @@ External references
 A good example of how to use the GPU CUDA driver library through the gpudev 
library
 is the l2fwd-nv application that can be found `here 
`_.
 
-The application is based on vanilla DPDK example l2fwd
-and is enhanced with GPU memory managed through gpudev library
-and CUDA to launch the swap of packets MAC addresses workload on the GPU.
+The application is based on the DPDK example l2fwd,
+with GPU memory managed through gpudev library.
+It includes a CUDA workload swapping MAC addresses
+of packets received in the GPU.
 
 l2fwd-nv is not intended to be used for performance
 (testpmd is the good candidate for this).
-- 
2.25.1

Re: [PATCH v11] app/dma-perf: introduce dma-perf application

[fengchengwen]

Acked-by: Chengwen Feng 

On 2023/6/29 21:14, Cheng Jiang wrote:
> There are many high-performance DMA devices supported in DPDK now, and
> these DMA devices can also be integrated into other modules of DPDK as
> accelerators, such as Vhost. Before integrating DMA into applications,
> developers need to know the performance of these DMA devices in various
> scenarios and the performance of CPUs in the same scenario, such as
> different buffer lengths. Only in this way can we know the target
> performance of the application accelerated by using them. This patch
> introduces a high-performance testing tool, which supports comparing the
> performance of CPU and DMA in different scenarios automatically with a
> pre-set config file. Memory Copy performance test are supported for now.
> This patch also updates the documentation and maintainer list for the
> application.
> 
> Signed-off-by: Cheng Jiang 
> Signed-off-by: Jiayu Hu 
> Signed-off-by: Yuan Wang 
> Acked-by: Morten Brørup 
> Acked-by: Chenbo Xia 
> Acked-by: Anoob Joseph 
> Tested-by: Anoob Joseph 
> Tested-by: Wei Ling 

...

> 
> .
> 

[PATCH] vhost: fix build with gcc 4.8

[Ali Alnubani]

Adds braces around initializer to resolve the following
false-positive build error with gcc 4.8.5 on CentOS:
lib/vhost/vduse.c:441:9: error: missing braces around initializer
  [-Werror=missing-braces]

Fixes: 653327e191f0 ("vhost: add multiqueue support to VDUSE")
Cc: maxime.coque...@redhat.com

Signed-off-by: Ali Alnubani 
---
 lib/vhost/vduse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vhost/vduse.c b/lib/vhost/vduse.c
index a509daf80c..aa5f1f564d 100644
--- a/lib/vhost/vduse.c
+++ b/lib/vhost/vduse.c
@@ -438,7 +438,7 @@ vduse_device_create(const char *path)
pthread_t fdset_tid;
uint32_t i, max_queue_pairs, total_queues;
struct virtio_net *dev;
-   struct virtio_net_config vnet_config = { 0 };
+   struct virtio_net_config vnet_config = {{ 0 }};
uint64_t ver = VHOST_VDUSE_API_VERSION;
uint64_t features = VDUSE_NET_SUPPORTED_FEATURES;
struct vduse_dev_config *dev_config = NULL;
-- 
2.25.1

Re: [PATCH] vhost: fix build with gcc 4.8

[Maxime Coquelin]

Hi Ali,

On 7/3/23 10:21, Ali Alnubani wrote:

Adds braces around initializer to resolve the following
false-positive build error with gcc 4.8.5 on CentOS:
lib/vhost/vduse.c:441:9: error: missing braces around initializer
   [-Werror=missing-braces]

Fixes: 653327e191f0 ("vhost: add multiqueue support to VDUSE")
Cc: maxime.coque...@redhat.com

Signed-off-by: Ali Alnubani 
---
  lib/vhost/vduse.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vhost/vduse.c b/lib/vhost/vduse.c
index a509daf80c..aa5f1f564d 100644
--- a/lib/vhost/vduse.c
+++ b/lib/vhost/vduse.c
@@ -438,7 +438,7 @@ vduse_device_create(const char *path)
pthread_t fdset_tid;
uint32_t i, max_queue_pairs, total_queues;
struct virtio_net *dev;
-   struct virtio_net_config vnet_config = { 0 };
+   struct virtio_net_config vnet_config = {{ 0 }};
uint64_t ver = VHOST_VDUSE_API_VERSION;
uint64_t features = VDUSE_NET_SUPPORTED_FEATURES;
struct vduse_dev_config *dev_config = NULL;


Reviewed-by: Maxime Coquelin 

This is not going to introduce any functional change so this is fine,
but the DPDK documentation indicates the minimum requirement is GCC 4.9[0]:

"
General development tools including a supported C compiler such as gcc 
(version 4.9+) or clang (version 3.4+), and pkg-config or pkgconf to be 
used when building end-user binaries against DPDK.

"

Thanks,
Maxime

[0]: 
http://doc.dpdk.org/guides/linux_gsg/sys_reqs.html#compilation-of-the-dpdk

RE: [PATCH] net/mlx5: fix flow dump for modify field

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Sean Zhang 
> Sent: Thursday, June 29, 2023 1:01 PM
> To: NBU-Contact-Thomas Monjalon (EXTERNAL) ;
> Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Haifei Luo 
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix flow dump for modify field
> 
> When using other process to dump flow information, the modify field
> information cannot be dumpped due to incorrect lcore value. Add loop
> to get modify field information from all lcore to fix the issue.
> 
> Fixes: a7ac7fae4919 ("net/mlx5: enhance flow dump")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Sean Zhang 
> Acked-by: Viacheslav Ovsiienko 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in secondary process

[Li, Miao]

Hi,

> -Original Message-
> From: David Marchand 
> Sent: Monday, July 3, 2023 3:48 PM
> To: Li, Miao 
> Cc: dev@dpdk.org; sta...@dpdk.org; Maxime Coquelin
> ; Xia, Chenbo 
> Subject: Re: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in
> secondary process
> 
> On Thu, Jun 29, 2023 at 4:27 AM Miao Li  wrote:
> >
> > When doing IO port map for legacy device in secondary process,
> > vfio_cfg setup for legacy device like vfio_group_fd and vfio_dev_fd is
> > missing. So, in secondary process, rte_pci_map_device is added for
> > legacy device to setup vfio_cfg and fill in region info like in
> > primary process.
> 
> I think, in legacy mode, there is no PCI mappable memory.
> So there should be no need for this call to rte_pci_map_device.
> 
> What is missing is a vfio setup, is this correct?
> I'd rather see this issue be fixed in the pci_vfio_ioport_map() function.
> 
If adding vfio setup in the pci_vfio_ioport_map() function, vfio will be setup 
twice in primary process because rte_pci_map_device will be called for legacy 
device in primary process.
I add IO port region check to skip region map in the next patch.
> 
> >> Fixes: 512e27eeb743 ("net/virtio: move PCI specific dev init to PCI
> >> ethdev init")
> 
> This commit only moved code, and at this point, there was no need for a call 
> to
> rte_pci_map_device in the secondary process case.
> It seems unlikely this is a faulty change.
> 
> The recent addition on the vfio side seems a better culprit, but I am fine 
> with
> being proven wrong :-).
> 
Yes,  the fix commit is wrong, but not the recent addition commit on the vfio 
side. Because the root cause is missing a vfio setup. After adding recent 
addition commit, the uninitialized vfio_cfg info(like vfio_dev_fd, region info) 
will be used so this bug will be found. I think the correct fix commit will be 
6d890f8ab512("net/virtio: fix multiple process support").
> 
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Miao Li 
> 
> 
> --
> David Marchand

Thanks,
Miao Li

Re: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in secondary process

[David Marchand]

On Mon, Jul 3, 2023 at 10:54 AM Li, Miao  wrote:
> > > When doing IO port map for legacy device in secondary process,
> > > vfio_cfg setup for legacy device like vfio_group_fd and vfio_dev_fd is
> > > missing. So, in secondary process, rte_pci_map_device is added for
> > > legacy device to setup vfio_cfg and fill in region info like in
> > > primary process.
> >
> > I think, in legacy mode, there is no PCI mappable memory.
> > So there should be no need for this call to rte_pci_map_device.
> >
> > What is missing is a vfio setup, is this correct?
> > I'd rather see this issue be fixed in the pci_vfio_ioport_map() function.
> >
> If adding vfio setup in the pci_vfio_ioport_map() function, vfio will be 
> setup twice in primary process because rte_pci_map_device will be called for 
> legacy device in primary process.
> I add IO port region check to skip region map in the next patch.

Well, something must be done so that it is not mapped twice, I did not
look into the details.
This current patch looks wrong to me and I understand this is not a
virtio only issue.


-- 
David Marchand

RE: [PATCH v2] net/mlx5: fix flow workspace destruction

[Matan Azrad]

From: Bing Zhao 
> PMD uses pthread key to allocate and access per thread flow workspace
> memory buffers.
> 
> PMD registered a key destructor function to clean up flow workspace buffers.
> However, the key destructor was not called by the pthread library.
> 
> The patch keeps track of per-thread flow workspaces in PMD.
> Flow workspaces memory release is activated from PMD destructor.
> 
> In the meanwhile, workspace buffer and RSS queues array are allocated in a
> single memory chunk with this patch. The maximal number of queues
> RTE_ETH_RSS_RETA_SIZE_512 is chosen. Then the workspace adjustment can
> be removed to reduce the software hiccup:
>   1. realloc and content copy
>   2. spinlock acquire and release
> 
> Fixes: 5d55a494f4e6 ("net/mlx5: split multi-thread flow handling per OS")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Gregory Etelson 
> Signed-off-by: Bing Zhao 
Acked-by: Matan Azrad 

[PATCH 1/2] node: add IPv4 local node to handle local pkts

[Rakesh Kudurumalla]

Local or Host destined pkts can be redirected IPv4 local node
using IP4 Lookup node entries with prefix of 32 and be redirected
to this IP4 local node for further processing.

Signed-off-by: Rakesh Kudurumalla 
---
Depends-on: series-28622 ("add inbuilt graph nodes data flow")

 doc/guides/prog_guide/graph_lib.rst   |  15 ++
 .../img/graph_inbuilt_node_flow.svg   | 138 ++
 lib/node/ip4_local.c  |  88 +++
 lib/node/ip4_lookup.c |   1 +
 lib/node/meson.build  |   1 +
 lib/node/rte_node_ip4_api.h   |  12 ++
 6 files changed, 196 insertions(+), 59 deletions(-)
 create mode 100644 lib/node/ip4_local.c

diff --git a/doc/guides/prog_guide/graph_lib.rst 
b/doc/guides/prog_guide/graph_lib.rst
index 96af29e8da..eaa8ee337e 100644
--- a/doc/guides/prog_guide/graph_lib.rst
+++ b/doc/guides/prog_guide/graph_lib.rst
@@ -498,3 +498,18 @@ Uses ``poll`` function to poll on the socket fd
 for ``POLLIN`` events to read the packets from raw socket
 to stream buffer and does ``rte_node_next_stream_move()``
 when there are received packets.
+
+ip4_local
+~
+This node is an intermediate node that does ``packet_type`` lookup for
+the received ipv4 packets and the result determines each packets next node.
+
+On successful ``packet_type`` lookup, for any IPv4 protocol the result
+contains the ``next_node`` id and ``next-hop`` id with which the packet
+needs to be further processed.
+
+On packet_type lookup failure, objects are redirected to ``pkt_drop`` node.
+``rte_node_ip4_route_add()`` is control path API to add ipv4 address with 32 
bit
+depth to receive to packets.
+To achieve home run, node use ``rte_node_stream_move()`` as mentioned in above
+sections.
diff --git a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg 
b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
index 02fe768dfe..7a3ace48dc 100644
--- a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
+++ b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
@@ -37,174 +37,194 @@ digraph dpdk_inbuilt_nodes_flow {
 ethdev_tx -> pkt_drop [color="cyan" style="dashed"]
 pkt_cls->pkt_drop   [color="cyan" style="dashed"]
 kernel_tx -> kernel_rx [color="red" style="dashed"]
+ip4_lookup -> ip4_local
+ip4_local -> pkt_drop [color="cyan" style="dashed"]
 }
 
  -->
 
 
-http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
-
+http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
+
 dpdk_inbuilt_nodes_flow
-
+
 
 
 ethdev_rx
-
-ethdev_rx
+
+ethdev_rx
 
 
 
 pkt_cls
-
-pkt_cls
+
+pkt_cls
 
 
 
 ethdev_rx->pkt_cls
-
-
+
+
 
 
 
 kernel_rx
-
-kernel_rx
+
+kernel_rx
 
 
 
 kernel_rx->pkt_cls
-
-
+
+
 
 
 
 ethdev_tx
-
-ethdev_tx
+
+ethdev_tx
 
 
 
 pkt_drop
-
-pkt_drop
+
+pkt_drop
 
 
 
 ethdev_tx->pkt_drop
-
-
+
+
 
 
 
 kernel_tx
-
-kernel_tx
+
+kernel_tx
 
 
 
 kernel_tx->kernel_rx
-
-
+
+
 
 
 
 pkt_cls->pkt_drop
-
-
+
+
 
 
 
 pkt_cls->kernel_tx
-
-
-exception pkts
+
+
+exception pkts
 
 
 
 ip4_lookup
-
-ip4_lookup
+
+ip4_lookup
 
 
 
 pkt_cls->ip4_lookup
-
-
-ipv4
+
+
+ipv4
 
 
 
 ip6_lookup
-
-ip6_lookup
+
+ip6_lookup
 
 
 
 pkt_cls->ip6_lookup
-
-
-ipv6
+
+
+ipv6
 
 
 
 ip4_lookup->pkt_drop
-
-
+
+
 
 
 
 ip4_rewrite
-
-ip4_rewrite
+
+ip4_rewrite
 
 
 
 ip4_lookup->ip4_rewrite
-
-
+
+
+
+
+
+ip4_local
+
+ip4_local
+
+
+
+ip4_lookup->ip4_local
+
+
 
 
 
 ip6_lookup->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite
-
-ip6_rewrite
+
+ip6_rewrite
 
 
 
 ip6_lookup->ip6_rewrite
-
-
+
+
 
 
 
 ip4_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip4_rewrite->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip6_rewrite->pkt_drop
-
-
+
+
+
+
+
+ip4_local->pkt_drop
+
+
 
 
 
diff --git a/lib/node/ip4_local.c b/lib/node/ip4_local.c
new file mode 100644
index 00..fb31d0f970
--- /dev/null
+++ b/lib/node/ip4_local.c
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#include "rte_node_ip4_api.h"
+
+#include "node_private.h"
+
+static uint16_t
+ip4_local_node_process_scalar(struct rte_graph *graph, struct rte_node *node,
+ void **objs, uint16_t nb_objs)
+{
+   void **to_next, **from;
+   uint16_t last_spec = 0;
+   rte_edge_t next_index;
+   struct rte_mbuf *mbuf;
+   uint16_t held = 0;
+   uint32_t l4;
+   int i;
+
+   /* Speculative next */
+   next_index = RTE_NODE_IP4_LOCAL_NEXT_UDP4_INPUT;
+
+   from = objs;
+   to_next = rte_node_next_stream_get(graph, node, next_index, nb_objs);
+   for (i = 0; i < nb_objs; i++) {
+   uint16_t next;
+
+   mbuf = (struct rte_mbuf *)objs[i];
+   l4 = mbuf->packet_type & RTE_PTYPE_L4_MASK;
+
+   next = (l4 == RTE_PTYPE_L4_UDP)
+

[PATCH 2/2] node: add UDP v4 support

[Rakesh Kudurumalla]

IPv4 UDP packets are given to application
with specified UDP destination port given
by user.

Signed-off-by: Rakesh Kudurumalla 
---
 doc/api/doxy-api-index.md |   3 +-
 doc/guides/prog_guide/graph_lib.rst   |  25 ++
 .../img/graph_inbuilt_node_flow.svg   | 165 -
 lib/node/meson.build  |   2 +
 lib/node/rte_node_udp4_input_api.h|  60 +
 lib/node/udp4_input.c | 226 ++
 lib/node/version.map  |   2 +
 7 files changed, 417 insertions(+), 66 deletions(-)
 create mode 100644 lib/node/rte_node_udp4_input_api.h
 create mode 100644 lib/node/udp4_input.c

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 3bc8778981..b81777b3fb 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -209,7 +209,8 @@ The public API headers are grouped by topics:
   * graph_nodes:
 [eth_node](@ref rte_node_eth_api.h),
 [ip4_node](@ref rte_node_ip4_api.h),
-[ip6_node](@ref rte_node_ip6_api.h)
+[ip6_node](@ref rte_node_ip6_api.h),
+[udp4_input_node](@ref rte_node_udp4_input_api.h)
 
 - **basic**:
   [bitops](@ref rte_bitops.h),
diff --git a/doc/guides/prog_guide/graph_lib.rst 
b/doc/guides/prog_guide/graph_lib.rst
index eaa8ee337e..98473383f1 100644
--- a/doc/guides/prog_guide/graph_lib.rst
+++ b/doc/guides/prog_guide/graph_lib.rst
@@ -513,3 +513,28 @@ On packet_type lookup failure, objects are redirected to 
``pkt_drop`` node.
 depth to receive to packets.
 To achieve home run, node use ``rte_node_stream_move()`` as mentioned in above
 sections.
+
+udp4_input
+~~
+This node is an intermediate node that does udp destination port lookup for
+the received ipv4 packets and the result determines each packets next node.
+
+User registers a new node ``udp4_input`` into graph library during 
initialization
+and attach user specified node as edege to this node using
+``rte_node_udp4_usr_node_add()``, and create empty hash table with destination
+port and node id as its feilds.
+
+After successful addition of user node as edege, edge id is returned to the 
user.
+
+User would register ``ip4_lookup`` table with specified ip address and 32 bit 
as mask
+for ip filtration using api ``rte_node_ip4_route_add()``.
+
+After graph is created user would update hash table with custom port with
+and previously obtained edge id using API ``rte_node_udp4_dst_port_add()``.
+
+When packet is received lpm look up is performed if ip is matched the packet
+is handed over to ip4_local node, then packet is verified for udp proto and
+on success packet is enqueued to ``udp4_input`` node.
+
+Hash lookup is performed in ``udp4_input`` node with registered destination 
port
+and destination port in UDP packet , on success packet is handed to 
``udp_user_node``.
diff --git a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg 
b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
index 7a3ace48dc..5db96adb01 100644
--- a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
+++ b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
@@ -39,192 +39,227 @@ digraph dpdk_inbuilt_nodes_flow {
 kernel_tx -> kernel_rx [color="red" style="dashed"]
 ip4_lookup -> ip4_local
 ip4_local -> pkt_drop [color="cyan" style="dashed"]
+ip4_local -> udp4_input [ label="udpv4"]
+udp4_input -> udp_user_node
+udp4_input -> pkt_drop [color="cyan" style="dashed"]
+
 }
 
  -->
 
 
-http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
-
+http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
+
 dpdk_inbuilt_nodes_flow
-
+
 
 
 ethdev_rx
-
-ethdev_rx
+
+ethdev_rx
 
 
 
 pkt_cls
-
-pkt_cls
+
+pkt_cls
 
 
 
 ethdev_rx->pkt_cls
-
-
+
+
 
 
 
 kernel_rx
-
-kernel_rx
+
+kernel_rx
 
 
 
 kernel_rx->pkt_cls
-
-
+
+
 
 
 
 ethdev_tx
-
-ethdev_tx
+
+ethdev_tx
 
 
 
 pkt_drop
-
-pkt_drop
+
+pkt_drop
 
 
 
 ethdev_tx->pkt_drop
-
-
+
+
 
 
 
 kernel_tx
-
-kernel_tx
+
+kernel_tx
 
 
 
 kernel_tx->kernel_rx
-
-
+
+
 
 
 
 pkt_cls->pkt_drop
-
-
+
+
 
 
 
 pkt_cls->kernel_tx
-
-
-exception pkts
+
+
+exception pkts
 
 
 
 ip4_lookup
-
-ip4_lookup
+
+ip4_lookup
 
 
 
 pkt_cls->ip4_lookup
-
-
-ipv4
+
+
+ipv4
 
 
 
 ip6_lookup
-
-ip6_lookup
+
+ip6_lookup
 
 
 
 pkt_cls->ip6_lookup
-
-
-ipv6
+
+
+ipv6
 
 
 
 ip4_lookup->pkt_drop
-
-
+
+
 
 
 
 ip4_rewrite
-
-ip4_rewrite
+
+ip4_rewrite
 
 
 
 ip4_lookup->ip4_rewrite
-
-
+
+
 
 
 
 ip4_local
-
-ip4_local
+
+ip4_local
 
 
 
 ip4_lookup->ip4_local
-
-
+
+
 
 
 
 ip6_lookup->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite
-
-ip6_rewrite
+
+ip6_rewrite
 
 
 
 ip6_lookup->ip6_rewrite
-
-
+
+
 
 
 
 ip4_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip4_rewrite->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip6_rewrite->pkt_drop
-
-
+
+
 
 
 
 ip4_local->pkt_drop
-
-
+
+
+
+
+
+udp4_input
+
+udp4_input
+
+
+
+ip4_local->udp4_input
+
+
+udpv4
+
+
+
+udp4_input->pkt_drop
+
+
+
+
+
+udp_user_node
+
+udp

Re: [RFC PATCH 00/29] cover letter for net/qdma PMD

[Ferruh Yigit]

On 7/3/2023 12:36 AM, Stephen Hemminger wrote:
> On Tue, 19 Jul 2022 22:52:20 +0530
> aman.ku...@vvdntech.in wrote:
> 
>
> QDMA is a very generic name and many vendors have IP for it.
>
> My suggestions is the qualify the specific driver with vendor name i.e.
> amd_qdma or xilinx_qdma or something similar.
>
> NXP also did the same dpaa2_qdma
>
>  
 @Thomas, @Hemant,
 Thank you for highlights and suggestions regarding conflicting names.
 We've discussed this internally and came up with below plan.

 For v22.11 DPDK, we would like to submit patches with below renames:
   drivers/net/qdma -> drivers/net/t1
   drivers/net/qdma/qdma_*.c/h -> drivers/net/t1/t1_*.c/h
   driver/net/qdma/qdma_access -> driver/net/t1/base  
>>>
>>> Curious why "t1"?
>>> What is the meaning?  
>>
>> The hardware is commerically named as the "T1 card". T1 represents first 
>> card of the telco accelerator series.
>> https://www.xilinx.com/publications/product-briefs/xilinx-t1-product-brief.pdf
>>
> 
> The discussion around this driver stalled. Either hardware abandoned, 
> renamed, or there was no interest.
> If you want to get this in a future DPDK release, please resubmit a new 
> version addressing review comments.
>

Hi Stephen,

I can confirm that this work is stalled, and it is not clear yet if
there will be a new version or not, so OK to clean this from patchwork.

Thanks,
ferruh

[v2 1/5] net/mlx5: support indirect list METER_MARK action

[Itamar Gozlan]

From: Gregory Etelson 

Signed-off-by: Gregory Etelson 
---
 drivers/net/mlx5/mlx5_flow.c|  69 +-
 drivers/net/mlx5/mlx5_flow.h|  67 -
 drivers/net/mlx5/mlx5_flow_hw.c | 419 +++-
 3 files changed, 476 insertions(+), 79 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 29e9819dd6..fb7b82fa26 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -63,8 +63,11 @@ mlx5_indirect_list_handles_release(struct rte_eth_dev *dev)
switch (e->type) {
 #ifdef HAVE_MLX5_HWS_SUPPORT
case MLX5_INDIRECT_ACTION_LIST_TYPE_MIRROR:
-   mlx5_hw_mirror_destroy(dev, (struct mlx5_mirror *)e, 
true);
+   mlx5_hw_mirror_destroy(dev, (struct mlx5_mirror *)e);
break;
+   case MLX5_INDIRECT_ACTION_LIST_TYPE_LEGACY:
+   mlx5_destroy_legacy_indirect(dev, e);
+   break;
 #endif
default:
DRV_LOG(ERR, "invalid indirect list type");
@@ -1156,7 +1159,24 @@ mlx5_flow_async_action_list_handle_destroy
 const struct rte_flow_op_attr *op_attr,
 struct rte_flow_action_list_handle *action_handle,
 void *user_data, struct rte_flow_error *error);
-
+static int
+mlx5_flow_action_list_handle_query_update(struct rte_eth_dev *dev,
+ const
+ struct rte_flow_action_list_handle 
*handle,
+ const void **update, void **query,
+ enum rte_flow_query_update_mode mode,
+ struct rte_flow_error *error);
+static int
+mlx5_flow_async_action_list_handle_query_update(struct rte_eth_dev *dev,
+   uint32_t queue_id,
+   const struct rte_flow_op_attr 
*attr,
+   const struct
+   rte_flow_action_list_handle 
*handle,
+   const void **update,
+   void **query,
+   enum rte_flow_query_update_mode 
mode,
+   void *user_data,
+   struct rte_flow_error *error);
 static const struct rte_flow_ops mlx5_flow_ops = {
.validate = mlx5_flow_validate,
.create = mlx5_flow_create,
@@ -1206,6 +1226,10 @@ static const struct rte_flow_ops mlx5_flow_ops = {
mlx5_flow_async_action_list_handle_create,
.async_action_list_handle_destroy =
mlx5_flow_async_action_list_handle_destroy,
+   .action_list_handle_query_update =
+   mlx5_flow_action_list_handle_query_update,
+   .async_action_list_handle_query_update =
+   mlx5_flow_async_action_list_handle_query_update,
 };
 
 /* Tunnel information. */
@@ -11054,6 +11078,47 @@ mlx5_flow_async_action_list_handle_destroy
  error);
 }
 
+static int
+mlx5_flow_action_list_handle_query_update(struct rte_eth_dev *dev,
+ const
+ struct rte_flow_action_list_handle 
*handle,
+ const void **update, void **query,
+ enum rte_flow_query_update_mode mode,
+ struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops,
+action_list_handle_query_update, ENOTSUP);
+   return fops->action_list_handle_query_update(dev, handle, update, query,
+mode, error);
+}
+
+static int
+mlx5_flow_async_action_list_handle_query_update(struct rte_eth_dev *dev,
+   uint32_t queue_id,
+   const
+   struct rte_flow_op_attr 
*op_attr,
+   const struct
+   rte_flow_action_list_handle 
*handle,
+   const void **update,
+   void **query,
+   enum
+   rte_flow_query_update_mode mode,
+   void *user_data,
+   struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_

[v2 2/5] app/testpmd: support indirect actions list syntax

[Itamar Gozlan]

From: Gregory Etelson 

Syntax:
actions .. indirect_list handle H conf C ..

H references shared action resources related to that handle.
C references configuration array:
if H was created from a list of actions A1 / A2 / ... / END,
C[i] points to a flow configuration update of A[i].

Signed-off-by: Gregory Etelson 
---
 app/test-pmd/cmdline_flow.c | 227 +---
 app/test-pmd/config.c   |   5 +-
 app/test-pmd/testpmd.h  |   2 +-
 3 files changed, 215 insertions(+), 19 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 7eb8e045b4..1644328bf4 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -66,6 +66,7 @@ enum index {
COMMON_ACTIONS_TEMPLATE_ID,
COMMON_TABLE_ID,
COMMON_QUEUE_ID,
+   COMMON_METER_COLOR_NAME,
 
/* TOP-level command. */
ADD,
@@ -253,6 +254,7 @@ enum index {
/* Indirect action arguments */
INDIRECT_ACTION_CREATE,
INDIRECT_ACTION_LIST_CREATE,
+   INDIRECT_ACTION_FLOW_CONF_CREATE,
INDIRECT_ACTION_UPDATE,
INDIRECT_ACTION_DESTROY,
INDIRECT_ACTION_QUERY,
@@ -265,6 +267,7 @@ enum index {
INDIRECT_ACTION_TRANSFER,
INDIRECT_ACTION_SPEC,
INDIRECT_ACTION_LIST,
+   INDIRECT_ACTION_FLOW_CONF,
 
/* Indirect action destroy arguments */
INDIRECT_ACTION_DESTROY_ID,
@@ -529,7 +532,6 @@ enum index {
ITEM_PPP_PROTO_ID,
ITEM_METER,
ITEM_METER_COLOR,
-   ITEM_METER_COLOR_NAME,
ITEM_QUOTA,
ITEM_QUOTA_STATE,
ITEM_QUOTA_STATE_NAME,
@@ -585,6 +587,8 @@ enum index {
ACTION_METER_COLOR_RED,
ACTION_METER_ID,
ACTION_METER_MARK,
+   ACTION_METER_MARK_CONF,
+   ACTION_METER_MARK_CONF_COLOR,
ACTION_METER_PROFILE,
ACTION_METER_PROFILE_ID2PTR,
ACTION_METER_POLICY,
@@ -669,6 +673,10 @@ enum index {
ACTION_SAMPLE_INDEX_VALUE,
ACTION_INDIRECT,
ACTION_INDIRECT_LIST,
+   ACTION_INDIRECT_LIST_HANDLE,
+   ACTION_INDIRECT_LIST_CONF,
+   INDIRECT_LIST_ACTION_ID2PTR_HANDLE,
+   INDIRECT_LIST_ACTION_ID2PTR_CONF,
ACTION_SHARED_INDIRECT,
INDIRECT_ACTION_ID2PTR,
ACTION_MODIFY_FIELD,
@@ -1366,6 +1374,7 @@ static const enum index next_ia_create_attr[] = {
INDIRECT_ACTION_TRANSFER,
INDIRECT_ACTION_SPEC,
INDIRECT_ACTION_LIST,
+   INDIRECT_ACTION_FLOW_CONF,
ZERO,
 };
 
@@ -1375,6 +1384,13 @@ static const enum index next_ia[] = {
ZERO
 };
 
+static const enum index next_ial[] = {
+   ACTION_INDIRECT_LIST_HANDLE,
+   ACTION_INDIRECT_LIST_CONF,
+   ACTION_NEXT,
+   ZERO
+};
+
 static const enum index next_shia[] = {
COMMON_INDIRECT_ACTION_PORT,
ACTION_NEXT,
@@ -2075,6 +2091,7 @@ static const enum index next_action[] = {
ACTION_METER,
ACTION_METER_COLOR,
ACTION_METER_MARK,
+   ACTION_METER_MARK_CONF,
ACTION_OF_DEC_NW_TTL,
ACTION_OF_POP_VLAN,
ACTION_OF_PUSH_VLAN,
@@ -2754,6 +2771,10 @@ static int parse_ia_destroy(struct context *ctx, const 
struct token *token,
 static int parse_ia_id2ptr(struct context *ctx, const struct token *token,
   const char *str, unsigned int len, void *buf,
   unsigned int size);
+
+static int parse_indlst_id2ptr(struct context *ctx, const struct token *token,
+  const char *str, unsigned int len, void *buf,
+  unsigned int size);
 static int parse_ia_port(struct context *ctx, const struct token *token,
 const char *str, unsigned int len, void *buf,
 unsigned int size);
@@ -2842,6 +2863,16 @@ static int comp_insertion_table_type(struct context *, 
const struct token *,
 static int comp_hash_table_type(struct context *, const struct token *,
unsigned int, char *, unsigned int);
 
+struct indlst_conf {
+   uint32_t id;
+   uint32_t conf_num;
+   struct rte_flow_action *actions;
+   const void **conf;
+   SLIST_ENTRY(indlst_conf) next;
+};
+
+static const struct indlst_conf *indirect_action_list_conf_get(uint32_t 
conf_id);
+
 /** Token definitions. */
 static const struct token token_list[] = {
/* Special tokens. */
@@ -3026,6 +3057,12 @@ static const struct token token_list[] = {
.call = parse_int,
.comp = comp_queue_id,
},
+   [COMMON_METER_COLOR_NAME] = {
+   .name = "color_name",
+   .help = "meter color name",
+   .call = parse_meter_color,
+   .comp = comp_meter_color,
+   },
/* Top-level command. */
[FLOW] = {
.name = "flow",
@@ -5769,17 +5806,11 @@ static const struct token token_list[] = {
.name = "color",
.help = "met

[v2 3/5] net/mlx5: add indirect encap decap support

[Itamar Gozlan]

From: Rongwei Liu 

Support the raw_encap/decap combinations in the indirect action
list, and translates to 4 types of underlayer tunnel operations:
1. Layer 2 encapsulation like VxLAN.
2. Layer 2 decapsulation like VxLAN.
3. Layer 3 encapsulation like GRE.
4. Layer 3 decapsulation like GRE.

Each indirect action list has a unique handle ID and stands for
different tunnel operations. The operation is shared globally with
fixed patterns. It means there is no configuration associated with
each handle ID and conf pointer should be NULL always no matter in
the action template or flow rules.

If the handle ID mask in the action template is NULL, each flow rule
can take its own indirect handle, otherwise, the ID in action template
is used for all rules.
The handle ID used in the flow rules must be the same type as the one
in the action template.

Testpmd cli example:

flow indirect_action 0 create action_id 10 transfer list actions
raw_decap index 1 / raw_encap index 2 / end 

flow pattern_template 0 create transfer pattern_template_id 1 template
eth / ipv4 / udp / end

flow actions_template 0 create transfer actions_template_id 1 template
indirect_list handle 10 / jump / end mask indirect_list / jump / end

flow template_table 0 create table_id 1 group 1 priority 0 transfer
rules_number 64 pattern_template 1 actions_template 1

flow queue 0 create 0 template_table 1 pattern_template 0
actions_template 0 postpone no pattern eth / ipv4 / udp / end actions
indirect_list handle 11 / jump group 10 / end 

Signed-off-by: Rongwei Liu 
---
 drivers/net/mlx5/mlx5_flow.c|   5 +
 drivers/net/mlx5/mlx5_flow.h|  16 ++
 drivers/net/mlx5/mlx5_flow_hw.c | 323 
 3 files changed, 344 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index fb7b82fa26..45f2210ae7 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -54,6 +54,7 @@ void
 mlx5_indirect_list_handles_release(struct rte_eth_dev *dev)
 {
struct mlx5_priv *priv = dev->data->dev_private;
+   struct rte_flow_error error;
 
while (!LIST_EMPTY(&priv->indirect_list_head)) {
struct mlx5_indirect_list *e =
@@ -68,6 +69,10 @@ mlx5_indirect_list_handles_release(struct rte_eth_dev *dev)
case MLX5_INDIRECT_ACTION_LIST_TYPE_LEGACY:
mlx5_destroy_legacy_indirect(dev, e);
break;
+   case MLX5_INDIRECT_ACTION_LIST_TYPE_REFORMAT:
+   mlx5_reformat_action_destroy(dev,
+   (struct rte_flow_action_list_handle *)e, 
&error);
+   break;
 #endif
default:
DRV_LOG(ERR, "invalid indirect list type");
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 46bfd4d8a7..e273bd958d 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -116,6 +116,7 @@ enum mlx5_indirect_list_type {
MLX5_INDIRECT_ACTION_LIST_TYPE_ERR = 0,
MLX5_INDIRECT_ACTION_LIST_TYPE_LEGACY = 1,
MLX5_INDIRECT_ACTION_LIST_TYPE_MIRROR = 2,
+   MLX5_INDIRECT_ACTION_LIST_TYPE_REFORMAT = 3,
 };
 
 /**
@@ -1433,6 +1434,8 @@ struct mlx5_hw_jump_action {
 
 /* Encap decap action struct. */
 struct mlx5_hw_encap_decap_action {
+   struct mlx5_indirect_list indirect;
+   enum mlx5dr_action_type action_type;
struct mlx5dr_action *action; /* Action object. */
/* Is header_reformat action shared across flows in table. */
bool shared;
@@ -2596,6 +2599,16 @@ flow_hw_validate_action_ipsec(struct rte_eth_dev *dev,
  uint64_t action_flags,
  struct rte_flow_error *error);
 
+struct mlx5_hw_encap_decap_action*
+mlx5_reformat_action_create(struct rte_eth_dev *dev,
+   const struct rte_flow_indir_action_conf *conf,
+   const struct rte_flow_action *encap_action,
+   const struct rte_flow_action *decap_action,
+   struct rte_flow_error *error);
+int mlx5_reformat_action_destroy(struct rte_eth_dev *dev,
+struct rte_flow_action_list_handle *handle,
+struct rte_flow_error *error);
+
 int mlx5_flow_validate_action_count(struct rte_eth_dev *dev,
const struct rte_flow_attr *attr,
struct rte_flow_error *error);
@@ -3041,5 +3054,8 @@ mlx5_hw_mirror_destroy(struct rte_eth_dev *dev, struct 
mlx5_mirror *mirror);
 void
 mlx5_destroy_legacy_indirect(struct rte_eth_dev *dev,
 struct mlx5_indirect_list *ptr);
+void
+mlx5_hw_decap_encap_destroy(struct rte_eth_dev *dev,
+   struct mlx5_indirect_list *reformat);
 #endif
 #endif /* RTE_PMD_MLX5_FLOW_H_ */
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/

[v2 5/5] net/mlx5/hws: support default miss action on FDB

[Itamar Gozlan]

From: Alex Vesker 

Add the support for default miss on HWS FDB, this implementation
was missing until now. Default miss can be used for more efficient
miss flow instead of going to an empty matcher or some defecated
empty table.

Signed-off-by: Alex Vesker 
---
 drivers/net/mlx5/hws/mlx5dr_action.c | 27 ---
 drivers/net/mlx5/hws/mlx5dr_table.c  |  8 ++--
 2 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c 
b/drivers/net/mlx5/hws/mlx5dr_action.c
index a514b82fec..96c0c10cd9 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -327,10 +327,12 @@ int mlx5dr_action_root_build_attr(struct 
mlx5dr_rule_action rule_actions[],
return 0;
 }
 
-static bool mlx5dr_action_fixup_stc_attr(struct mlx5dr_cmd_stc_modify_attr 
*stc_attr,
-struct mlx5dr_cmd_stc_modify_attr 
*fixup_stc_attr,
-enum mlx5dr_table_type table_type,
-bool is_mirror)
+static bool
+mlx5dr_action_fixup_stc_attr(struct mlx5dr_context *ctx,
+struct mlx5dr_cmd_stc_modify_attr *stc_attr,
+struct mlx5dr_cmd_stc_modify_attr *fixup_stc_attr,
+enum mlx5dr_table_type table_type,
+bool is_mirror)
 {
struct mlx5dr_devx_obj *devx_obj;
bool use_fixup = false;
@@ -353,6 +355,17 @@ static bool mlx5dr_action_fixup_stc_attr(struct 
mlx5dr_cmd_stc_modify_attr *stc_
use_fixup = true;
break;
 
+   case MLX5_IFC_STC_ACTION_TYPE_ALLOW:
+   if (fw_tbl_type == FS_FT_FDB_TX || fw_tbl_type == FS_FT_FDB_RX) 
{
+   fixup_stc_attr->action_type = 
MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_VPORT;
+   fixup_stc_attr->action_offset = stc_attr->action_offset;
+   fixup_stc_attr->stc_offset = stc_attr->stc_offset;
+   fixup_stc_attr->vport.esw_owner_vhca_id = 
ctx->caps->vhca_id;
+   fixup_stc_attr->vport.vport_num = 
ctx->caps->eswitch_manager_vport_number;
+   use_fixup = true;
+   }
+   break;
+
case MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_VPORT:
if (stc_attr->vport.vport_num != WIRE_PORT)
break;
@@ -402,7 +415,7 @@ int mlx5dr_action_alloc_single_stc(struct mlx5dr_context 
*ctx,
devx_obj_0 = mlx5dr_pool_chunk_get_base_devx_obj(stc_pool, stc);
 
/* According to table/action limitation change the stc_attr */
-   use_fixup = mlx5dr_action_fixup_stc_attr(stc_attr, &fixup_stc_attr, 
table_type, false);
+   use_fixup = mlx5dr_action_fixup_stc_attr(ctx, stc_attr, 
&fixup_stc_attr, table_type, false);
ret = mlx5dr_cmd_stc_modify(devx_obj_0, use_fixup ? &fixup_stc_attr : 
stc_attr);
if (ret) {
DR_LOG(ERR, "Failed to modify STC action_type %d tbl_type %d",
@@ -416,7 +429,8 @@ int mlx5dr_action_alloc_single_stc(struct mlx5dr_context 
*ctx,
 
devx_obj_1 = 
mlx5dr_pool_chunk_get_base_devx_obj_mirror(stc_pool, stc);
 
-   use_fixup = mlx5dr_action_fixup_stc_attr(stc_attr, 
&fixup_stc_attr,
+   use_fixup = mlx5dr_action_fixup_stc_attr(ctx, stc_attr,
+&fixup_stc_attr,
 table_type, true);
ret = mlx5dr_cmd_stc_modify(devx_obj_1, use_fixup ? 
&fixup_stc_attr : stc_attr);
if (ret) {
@@ -496,7 +510,6 @@ static void mlx5dr_action_fill_stc_attr(struct 
mlx5dr_action *action,
case MLX5DR_ACTION_TYP_MISS:
attr->action_type = MLX5_IFC_STC_ACTION_TYPE_ALLOW;
attr->action_offset = MLX5DR_ACTION_OFFSET_HIT;
-   /* TODO Need to support default miss for FDB */
break;
case MLX5DR_ACTION_TYP_CTR:
attr->id = obj->id;
diff --git a/drivers/net/mlx5/hws/mlx5dr_table.c 
b/drivers/net/mlx5/hws/mlx5dr_table.c
index 46c2a47015..2c8b7a2b9e 100644
--- a/drivers/net/mlx5/hws/mlx5dr_table.c
+++ b/drivers/net/mlx5/hws/mlx5dr_table.c
@@ -25,8 +25,6 @@ mlx5dr_table_up_default_fdb_miss_tbl(struct mlx5dr_table *tbl)
struct mlx5dr_cmd_set_fte_dest dest = {0};
struct mlx5dr_context *ctx = tbl->ctx;
uint8_t tbl_type = tbl->type;
-   uint32_t vport;
-
if (tbl->type != MLX5DR_TABLE_TYPE_FDB)
return 0;
 
@@ -39,11 +37,9 @@ mlx5dr_table_up_default_fdb_miss_tbl(struct mlx5dr_table 
*tbl)
ft_attr.level = tbl->ctx->caps->fdb_ft.max_level; /* The last level */
ft_attr.rtc_valid = false;
 
-   assert(ctx->caps->eswitch_manager);
-   vport = ctx->caps->eswitch_manager_vport_number;
-
dest.destination_type = MLX5_FLOW_DESTINATION_TYPE_VPORT;
-   

[v2 4/5] net/mlx5: support symmetric RSS hash function

[Itamar Gozlan]

From: Xueming Li 

This patch supports symmetric hash function that creating same
hash result for bi-direction traffic which having reverse
source and destination IP and L4 port.

Since the hash algorithom is different than spec(XOR), leave a
warning in validation.

Signed-off-by: Xueming Li 
---
 drivers/net/mlx5/mlx5.h |  3 +++
 drivers/net/mlx5/mlx5_devx.c| 11 ---
 drivers/net/mlx5/mlx5_flow.c| 10 --
 drivers/net/mlx5/mlx5_flow.h|  5 +
 drivers/net/mlx5/mlx5_flow_dv.c | 13 -
 drivers/net/mlx5/mlx5_flow_hw.c |  7 +++
 drivers/net/mlx5/mlx5_rx.h  |  2 +-
 drivers/net/mlx5/mlx5_rxq.c |  8 +---
 8 files changed, 49 insertions(+), 10 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b5b809633c..4fc67c4f36 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1579,6 +1579,7 @@ struct mlx5_mtr_config {
 
 /* RSS description. */
 struct mlx5_flow_rss_desc {
+   bool symmetric_hash_function; /**< Symmetric hash function */
uint32_t level;
uint32_t queue_num; /**< Number of entries in @p queue. */
uint64_t types; /**< Specific RSS hash types (see RTE_ETH_RSS_*). */
@@ -1647,6 +1648,7 @@ struct mlx5_hrxq {
 #if defined(HAVE_IBV_FLOW_DV_SUPPORT) || !defined(HAVE_INFINIBAND_VERBS_H)
void *action; /* DV QP action pointer. */
 #endif
+   bool symmetric_hash_function; /* Symmetric hash function */
uint32_t hws_flags; /* Hw steering flags. */
uint64_t hash_fields; /* Verbs Hash fields. */
uint32_t rss_key_len; /* Hash key length in bytes. */
@@ -1718,6 +1720,7 @@ struct mlx5_obj_ops {
int (*hrxq_modify)(struct rte_eth_dev *dev, struct mlx5_hrxq *hrxq,
   const uint8_t *rss_key,
   uint64_t hash_fields,
+  bool symmetric_hash_function,
   const struct mlx5_ind_table_obj *ind_tbl);
void (*hrxq_destroy)(struct mlx5_hrxq *hrxq);
int (*drop_action_create)(struct rte_eth_dev *dev);
diff --git a/drivers/net/mlx5/mlx5_devx.c b/drivers/net/mlx5/mlx5_devx.c
index 5082a7e178..d286cfe864 100644
--- a/drivers/net/mlx5/mlx5_devx.c
+++ b/drivers/net/mlx5/mlx5_devx.c
@@ -803,7 +803,8 @@ static void
 mlx5_devx_tir_attr_set(struct rte_eth_dev *dev, const uint8_t *rss_key,
   uint64_t hash_fields,
   const struct mlx5_ind_table_obj *ind_tbl,
-  int tunnel, struct mlx5_devx_tir_attr *tir_attr)
+  int tunnel, bool symmetric_hash_function,
+  struct mlx5_devx_tir_attr *tir_attr)
 {
struct mlx5_priv *priv = dev->data->dev_private;
bool is_hairpin;
@@ -834,6 +835,7 @@ mlx5_devx_tir_attr_set(struct rte_eth_dev *dev, const 
uint8_t *rss_key,
tir_attr->disp_type = MLX5_TIRC_DISP_TYPE_INDIRECT;
tir_attr->rx_hash_fn = MLX5_RX_HASH_FN_TOEPLITZ;
tir_attr->tunneled_offload_en = !!tunnel;
+   tir_attr->rx_hash_symmetric = symmetric_hash_function;
/* If needed, translate hash_fields bitmap to PRM format. */
if (hash_fields) {
struct mlx5_rx_hash_field_select *rx_hash_field_select =
@@ -902,7 +904,8 @@ mlx5_devx_hrxq_new(struct rte_eth_dev *dev, struct 
mlx5_hrxq *hrxq,
int err;
 
mlx5_devx_tir_attr_set(dev, hrxq->rss_key, hrxq->hash_fields,
-  hrxq->ind_table, tunnel, &tir_attr);
+  hrxq->ind_table, tunnel, 
hrxq->symmetric_hash_function,
+  &tir_attr);
hrxq->tir = mlx5_devx_cmd_create_tir(priv->sh->cdev->ctx, &tir_attr);
if (!hrxq->tir) {
DRV_LOG(ERR, "Port %u cannot create DevX TIR.",
@@ -969,13 +972,13 @@ static int
 mlx5_devx_hrxq_modify(struct rte_eth_dev *dev, struct mlx5_hrxq *hrxq,
   const uint8_t *rss_key,
   uint64_t hash_fields,
+  bool symmetric_hash_function,
   const struct mlx5_ind_table_obj *ind_tbl)
 {
struct mlx5_devx_modify_tir_attr modify_tir = {0};
 
/*
 * untested for modification fields:
-* - rx_hash_symmetric not set in hrxq_new(),
 * - rx_hash_fn set hard-coded in hrxq_new(),
 * - lro_xxx not set after rxq setup
 */
@@ -983,11 +986,13 @@ mlx5_devx_hrxq_modify(struct rte_eth_dev *dev, struct 
mlx5_hrxq *hrxq,
modify_tir.modify_bitmask |=
MLX5_MODIFY_TIR_IN_MODIFY_BITMASK_INDIRECT_TABLE;
if (hash_fields != hrxq->hash_fields ||
+   symmetric_hash_function != 
hrxq->symmetric_hash_function ||
memcmp(hrxq->rss_key, rss_key, MLX5_RSS_HASH_KEY_LEN))
modify_tir.modify_bitmask |=
MLX5_MODIFY_TIR_IN_MODIFY_BITMASK_HASH;
mlx5_devx_tir_attr_set(dev, rss_key, hash_fields,

[PATCH] doc: update BIOS setting and supported HW list for NTB

[Junfeng Guo]

Update BIOS settings and supported platform list for Intel NTB.

Fixes: f5057be340e4 ("raw/ntb: support Intel Ice Lake")
Cc: sta...@dpdk.org

Signed-off-by: Junfeng Guo 
---
 doc/guides/rawdevs/ntb.rst | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/doc/guides/rawdevs/ntb.rst b/doc/guides/rawdevs/ntb.rst
index 2bb115d13f..c34512177a 100644
--- a/doc/guides/rawdevs/ntb.rst
+++ b/doc/guides/rawdevs/ntb.rst
@@ -17,18 +17,22 @@ some information by using scratchpad registers.
 BIOS setting on Intel Xeon
 --
 
-Intel Non-transparent Bridge needs special BIOS setting. The reference for
-Skylake is 
https://www.intel.com/content/dam/support/us/en/documents/server-products/Intel_Xeon_Processor_Scalable_Family_BIOS_User_Guide.pdf
-
-- Set the needed PCIe port as NTB to NTB mode on both hosts.
-- Enable NTB bars and set bar size of bar 23 and bar 45 as 12-29 (4K-512M)
-  on both hosts (for Ice Lake, bar size can be set as 12-51, namely 4K-128PB).
-  Note that bar size on both hosts should be the same.
-- Disable split bars for both hosts.
-- Set crosslink control override as DSD/USP on one host, USD/DSP on
+Intel Non-transparent Bridge (NTB) needs special BIOS settings on both systems.
+Note that for 4th Generation Intel® Xeon® Scalable Processors, option ``Port
+Subsystem Mode`` should be changed from ``Gen5`` to ``Gen4 Only``, then reboot.
+
+- Set ``Non-Transparent Bridge PCIe Port Definition`` for needed PCIe ports as
+  ``NTB to NTB`` mode, on both hosts.
+- Set ``Enable NTB BARs`` as ``Enabled``, on both hosts.
+- Set ``Enable SPLIT BARs`` as ``Disabled``, on both hosts.
+- Set ``Imbar1 Size``, ``Imbar2 Size``, ``Embar1 Size`` and ``Embar2 Size``, as
+  12-29 (i.e., 4K-512M) for 2nd Generation Intel® Xeon® Scalable Processors; as
+  12-51 (i.e., 4K-128PB) for 3rd and 4th Generation Intel® Xeon® Scalable
+  Processors. Note that those bar sizes on both hosts should be the same.
+- Set ``Crosslink Control override`` as ``DSD/USP`` on one host, ``USD/DSP`` on
   another host.
-- Disable PCIe PII SSC (Spread Spectrum Clocking) for both hosts. This
-  is a hardware requirement.
+- Set ``PCIe PLL SSC (Spread Spectrum Clocking)`` as ``Disabled``, on both
+  hosts. This is a hardware requirement when using Re-timer Cards.
 
 
 Device Setup
@@ -145,4 +149,8 @@ like the following:
 Limitation
 --
 
-- This PMD only supports Intel Skylake and Ice Lake platforms.
+This PMD is only supported on Intel Xeon Platforms:
+
+- 4th Generation Intel® Xeon® Scalable Processors.
+- 3rd Generation Intel® Xeon® Scalable Processors.
+- 2nd Generation Intel® Xeon® Scalable Processors.
-- 
2.34.1

Re: [PATCH] eal: fix file descriptor leakage with unhandled messages

[fengchengwen]

Acked-by: Chengwen Feng 

On 2023/6/28 20:19, Viacheslav Ovsiienko wrote:
> The sendmsg()/recvmsg() API is used to establish communication between
> the DPDK processes. The API supposes inter-process file descriptors
> sending and conversion, the recipient sees the resulting descriptors
> in the received message - the operating systems creates ones in the
> right context.
> 
> The message receiving is performed by EAL in the dedicated thread
> and it might happen the message is received by EAL and not handled
> by addressed PMD or application due to some reasons (timeouts, race
> condition, etc). EAL just dropped unhandled messages causing the
> file descriptor leakage if these ones were presented in the message.
> 
> The patch closes the descriptors (if any) in unhandled messages.
> 
> Fixes: 783b6e54971 ("eal: add synchronous multi-process communication")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Viacheslav Ovsiienko 
> ---
>  lib/eal/common/eal_common_proc.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/common/eal_common_proc.c 
> b/lib/eal/common/eal_common_proc.c
> index 1fc1d6c53b..9676dd73c5 100644
> --- a/lib/eal/common/eal_common_proc.c
> +++ b/lib/eal/common/eal_common_proc.c
> @@ -321,6 +321,15 @@ read_msg(int fd, struct mp_msg_internal *m, struct 
> sockaddr_un *s)
>   return msglen;
>  }
>  
> +static void
> +cleanup_msg_fds(const struct rte_mp_msg *msg)
> +{
> + int i;
> +
> + for (i = 0; i < msg->num_fds; i++)
> + close(msg->fds[i]);
> +}
> +
>  static void
>  process_msg(struct mp_msg_internal *m, struct sockaddr_un *s)
>  {
> @@ -349,8 +358,10 @@ process_msg(struct mp_msg_internal *m, struct 
> sockaddr_un *s)
>   else if (pending_req->type == REQUEST_TYPE_ASYNC)
>   req = async_reply_handle_thread_unsafe(
>   pending_req);
> - } else
> + } else {
>   RTE_LOG(ERR, EAL, "Drop mp reply: %s\n", msg->name);
> + cleanup_msg_fds(msg);
> + }
>   pthread_mutex_unlock(&pending_requests.lock);
>  
>   if (req != NULL)
> @@ -380,6 +391,7 @@ process_msg(struct mp_msg_internal *m, struct sockaddr_un 
> *s)
>   RTE_LOG(ERR, EAL, "Cannot find action: %s\n",
>   msg->name);
>   }
> + cleanup_msg_fds(msg);
>   } else if (action(msg, s->sun_path) < 0) {
>   RTE_LOG(ERR, EAL, "Fail to handle message: %s\n", msg->name);
>   }
> 

[PATCH v4] bitmap: add scan from offset function

[Volodymyr Fialko]

Currently, in the case when we search for a bit set after a particular
value, the bitmap has to be scanned from the beginning and
rte_bitmap_scan() has to be called multiple times until we hit the value.

Add a new rte_bitmap_scan_from_offset() function to initialize scan
state at the given offset and perform scan, this will allow getting
the next set bit after certain offset within one scan call.

Signed-off-by: Volodymyr Fialko 
---
v2:
 - added rte_bitmap_scan_from_offset
v3:
 - added note for internal use only for init_at function
v4:
 - marked init_at function as __rte_internal

 app/test/test_bitmap.c   | 33 -
 lib/eal/include/rte_bitmap.h | 56 
 2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/app/test/test_bitmap.c b/app/test/test_bitmap.c
index e9c61590ae..9e38087408 100644
--- a/app/test/test_bitmap.c
+++ b/app/test/test_bitmap.c
@@ -18,8 +18,8 @@ test_bitmap_scan_operations(struct rte_bitmap *bmp)
 {
uint64_t slab1_magic = 0xBADC0FFEEBADF00D;
uint64_t slab2_magic = 0xFEEDDEADDEADF00D;
+   int i, nb_clear, nb_set, next_cl;
uint32_t pos = 0, start_pos;
-   int i, nb_clear, nb_set;
uint64_t out_slab = 0;
 
rte_bitmap_reset(bmp);
@@ -71,6 +71,37 @@ test_bitmap_scan_operations(struct rte_bitmap *bmp)
return TEST_FAILED;
}
 
+   /* Scan with offset check. */
+   if (!rte_bitmap_scan_from_offset(bmp, RTE_BITMAP_SLAB_BIT_SIZE, &pos, 
&out_slab)) {
+   printf("Failed to get slab from bitmap with scan from 
offset.\n");
+   return TEST_FAILED;
+   }
+
+   if (slab2_magic != out_slab) {
+   printf("Scan from offset operation failed.\n");
+   return TEST_FAILED;
+   }
+
+   /* Scan with offset wrap around check. */
+   if (!rte_bitmap_scan_from_offset(bmp, 2 * RTE_BITMAP_SLAB_BIT_SIZE, 
&pos, &out_slab)) {
+   printf("Failed to get slab from bitmap with scan from 
offset.\n");
+   return TEST_FAILED;
+   }
+
+   if (slab1_magic != out_slab) {
+   printf("Scan from offset with wrap around operation failed.\n");
+   return TEST_FAILED;
+   }
+
+   /* Test scan when the bit set is on a next cline */
+   rte_bitmap_reset(bmp);
+   next_cl = RTE_MIN(RTE_BITMAP_CL_BIT_SIZE, MAX_BITS);
+   rte_bitmap_set(bmp, next_cl);
+   if (!rte_bitmap_scan_from_offset(bmp, 0, &pos, &out_slab)) {
+   printf("Failed to get slab from next cache line from 
bitmap.\n");
+   return TEST_FAILED;
+   }
+
/* Test scan when a cline is half full */
rte_bitmap_reset(bmp);
for (i = 0; i < MAX_BITS; i++)
diff --git a/lib/eal/include/rte_bitmap.h b/lib/eal/include/rte_bitmap.h
index 27ee3d18a4..0b9ae8f135 100644
--- a/lib/eal/include/rte_bitmap.h
+++ b/lib/eal/include/rte_bitmap.h
@@ -137,6 +137,30 @@ __rte_bitmap_scan_init(struct rte_bitmap *bmp)
bmp->go2 = 0;
 }
 
+/**
+ * Bitmap initialize internal scan pointers at the given position for the scan 
function.
+ *
+ * Note: for private/internal use, for public:
+ * @see rte_bitmap_scan_from_offset()
+ *
+ * @param bmp
+ *   Handle to bitmap instance
+ * @param pos
+ *   Bit position to start scan
+ */
+__rte_internal
+static inline void
+__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
+{
+   uint64_t *slab1;
+
+   bmp->index1 = pos >> (RTE_BITMAP_SLAB_BIT_SIZE_LOG2 + 
RTE_BITMAP_CL_BIT_SIZE_LOG2);
+   bmp->offset1 = (pos >> RTE_BITMAP_CL_BIT_SIZE_LOG2) & 
RTE_BITMAP_SLAB_BIT_MASK;
+   bmp->index2 = pos >> RTE_BITMAP_SLAB_BIT_SIZE_LOG2;
+   slab1 = bmp->array1 + bmp->index1;
+   bmp->go2 = *slab1 & (1llu << bmp->offset1);
+}
+
 /**
  * Bitmap memory footprint calculation
  *
@@ -591,6 +615,38 @@ rte_bitmap_scan(struct rte_bitmap *bmp, uint32_t *pos, 
uint64_t *slab)
return 0;
 }
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Bitmap scan from the given offset.
+ * Function will reset internal scan state to start scanning from the offset
+ * position.
+ * @see rte_bitmap_scan()
+ *
+ * @param bmp
+ *   Handle to bitmap instance
+ * @param offset
+ *   Bit offset to start scan
+ * @param pos
+ *   When function call returns 1, pos contains the position of the next set
+ *   bit, otherwise not modified
+ * @param slab
+ *   When function call returns 1, slab contains the value of the entire 64-bit
+ *   slab where the bit indicated by pos is located.
+ *   When function call returns 0, slab is not modified.
+ * @return
+ *   0 if there is no bit set in the bitmap, 1 otherwise
+ */
+__rte_experimental
+static inline int
+rte_bitmap_scan_from_offset(struct rte_bitmap *bmp, uint32_t offset,
+   uint32_t *pos, uint64_t *slab)
+{
+   __rte_bitmap_scan_init_at(bmp, offset);
+   return rte_bitmap_scan(bmp, pos, slab);
+}
+
 #i

RE: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in secondary process

[Xia, Chenbo]

+Nipun

> -Original Message-
> From: David Marchand 
> Sent: Monday, July 3, 2023 4:58 PM
> To: Li, Miao 
> Cc: dev@dpdk.org; sta...@dpdk.org; Maxime Coquelin
> ; Xia, Chenbo 
> Subject: Re: [PATCH v2 1/2] net/virtio: fix legacy device IO port map in
> secondary process
> 
> On Mon, Jul 3, 2023 at 10:54 AM Li, Miao  wrote:
> > > > When doing IO port map for legacy device in secondary process,
> > > > vfio_cfg setup for legacy device like vfio_group_fd and vfio_dev_fd
> is
> > > > missing. So, in secondary process, rte_pci_map_device is added for
> > > > legacy device to setup vfio_cfg and fill in region info like in
> > > > primary process.
> > >
> > > I think, in legacy mode, there is no PCI mappable memory.
> > > So there should be no need for this call to rte_pci_map_device.
> > >
> > > What is missing is a vfio setup, is this correct?
> > > I'd rather see this issue be fixed in the pci_vfio_ioport_map()
> function.
> > >
> > If adding vfio setup in the pci_vfio_ioport_map() function, vfio will be
> setup twice in primary process because rte_pci_map_device will be called
> for legacy device in primary process.
> > I add IO port region check to skip region map in the next patch.
> 
> Well, something must be done so that it is not mapped twice, I did not
> look into the details.
> This current patch looks wrong to me and I understand this is not a
> virtio only issue.

I think we could have some way to improve this:

1. Make rte_pci_map_device map either PIO or MMIO (Based on my knowledge, it's 
doable
for vfio. For UIO, I am no expert and not sure). For ioport, it's only about 
setting
up the ioport offset and size.
2. rte_pci_ioport_map may not be needed anymore.
3. struct rte_pci_ioport may not be needed anymore as the info could be saved in
struct rte_pci_device_internal.
4. ioport device uses bar #, len, offset to RW specific BAR.

Then for virtio device, either primary or secondary process only calls 
rte_pci_map_device
once.

Any comments?

Thanks,
Chenbo

> 
> 
> --
> David Marchand

RE: [PATCH] doc: update BIOS setting and supported HW list for NTB

[Wu, Jingjing]

> -Original Message-
> From: Guo, Junfeng 
> Sent: Monday, July 3, 2023 5:25 PM
> To: Wu, Jingjing 
> Cc: dev@dpdk.org; sta...@dpdk.org; Guo, Junfeng 
> Subject: [PATCH] doc: update BIOS setting and supported HW list for NTB
> 
> Update BIOS settings and supported platform list for Intel NTB.
> 
> Fixes: f5057be340e4 ("raw/ntb: support Intel Ice Lake")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Junfeng Guo 

Acked-by: Jingjing Wu 

[PATCH v3] net/mlx5: fix flow workspace destruction

[Bing Zhao]

From: Gregory Etelson 

PMD uses pthread key to allocate and access per thread flow
workspace memory buffers.

PMD registered a key destructor function to clean up flow workspace
buffers. However, the key destructor was not called by the pthread
library.

The patch keeps track of per-thread flow workspaces in PMD.
Flow workspaces memory release is activated from PMD destructor.

In the meanwhile, workspace buffer and RSS queues array are allocated
in a single memory chunk with this patch. The maximal number of
queues RTE_ETH_RSS_RETA_SIZE_512 is chosen. Then the workspace
adjustment can be removed to reduce the software hiccup:
  1. realloc and content copy
  2. spinlock acquire and release

Bugzilla ID: 1255

Fixes: 5d55a494f4e6 ("net/mlx5: split multi-thread flow handling per OS")
Cc: sta...@dpdk.org

Reported-by: David Marchand 
Signed-off-by: Gregory Etelson 
Signed-off-by: Bing Zhao 
Acked-by: Matan Azrad 
---
v2: fix typo and code style
v3: add bugzilla information
---
 drivers/net/mlx5/linux/mlx5_flow_os.c |  2 +-
 drivers/net/mlx5/mlx5.c   |  1 +
 drivers/net/mlx5/mlx5_flow.c  | 76 +++
 drivers/net/mlx5/mlx5_flow.h  |  4 +-
 4 files changed, 36 insertions(+), 47 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_flow_os.c 
b/drivers/net/mlx5/linux/mlx5_flow_os.c
index 3c9a823edf..b139bb75b9 100644
--- a/drivers/net/mlx5/linux/mlx5_flow_os.c
+++ b/drivers/net/mlx5/linux/mlx5_flow_os.c
@@ -51,7 +51,7 @@ mlx5_flow_os_validate_item_esp(const struct rte_flow_item 
*item,
 int
 mlx5_flow_os_init_workspace_once(void)
 {
-   if (rte_thread_key_create(&key_workspace, flow_release_workspace)) {
+   if (rte_thread_key_create(&key_workspace, NULL)) {
DRV_LOG(ERR, "Can't create flow workspace data thread key.");
rte_errno = ENOMEM;
return -rte_errno;
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 5f0aa296ba..fd9b76027d 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -1838,6 +1838,7 @@ mlx5_free_shared_dev_ctx(struct mlx5_dev_ctx_shared *sh)
if (LIST_EMPTY(&mlx5_dev_ctx_list)) {
mlx5_os_net_cleanup();
mlx5_flow_os_release_workspace();
+   mlx5_flow_workspace_gc_release();
}
pthread_mutex_unlock(&mlx5_dev_ctx_list_mutex);
if (sh->flex_parsers_dv) {
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index cf83db7b60..d3b1252ad6 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -7155,36 +7155,6 @@ flow_tunnel_from_rule(const struct mlx5_flow *flow)
return tunnel;
 }
 
-/**
- * Adjust flow RSS workspace if needed.
- *
- * @param wks
- *   Pointer to thread flow work space.
- * @param rss_desc
- *   Pointer to RSS descriptor.
- * @param[in] nrssq_num
- *   New RSS queue number.
- *
- * @return
- *   0 on success, -1 otherwise and rte_errno is set.
- */
-static int
-flow_rss_workspace_adjust(struct mlx5_flow_workspace *wks,
- struct mlx5_flow_rss_desc *rss_desc,
- uint32_t nrssq_num)
-{
-   if (likely(nrssq_num <= wks->rssq_num))
-   return 0;
-   rss_desc->queue = realloc(rss_desc->queue,
- sizeof(*rss_desc->queue) * RTE_ALIGN(nrssq_num, 2));
-   if (!rss_desc->queue) {
-   rte_errno = ENOMEM;
-   return -1;
-   }
-   wks->rssq_num = RTE_ALIGN(nrssq_num, 2);
-   return 0;
-}
-
 /**
  * Create a flow and add it to @p list.
  *
@@ -7303,8 +7273,7 @@ flow_list_create(struct rte_eth_dev *dev, enum 
mlx5_flow_type type,
if (attr->ingress)
rss = flow_get_rss_action(dev, p_actions_rx);
if (rss) {
-   if (flow_rss_workspace_adjust(wks, rss_desc, rss->queue_num))
-   return 0;
+   MLX5_ASSERT(rss->queue_num <= RTE_ETH_RSS_RETA_SIZE_512);
/*
 * The following information is required by
 * mlx5_flow_hashfields_adjust() in advance.
@@ -8072,12 +8041,34 @@ flow_release_workspace(void *data)
 
while (wks) {
next = wks->next;
-   free(wks->rss_desc.queue);
free(wks);
wks = next;
}
 }
 
+static struct mlx5_flow_workspace *gc_head;
+static rte_spinlock_t mlx5_flow_workspace_lock = RTE_SPINLOCK_INITIALIZER;
+
+static void
+mlx5_flow_workspace_gc_add(struct mlx5_flow_workspace *ws)
+{
+   rte_spinlock_lock(&mlx5_flow_workspace_lock);
+   ws->gc = gc_head;
+   gc_head = ws;
+   rte_spinlock_unlock(&mlx5_flow_workspace_lock);
+}
+
+void
+mlx5_flow_workspace_gc_release(void)
+{
+   while (gc_head) {
+   struct mlx5_flow_workspace *wks = gc_head;
+
+   gc_head = wks->gc;
+   flow_release_workspace(wks);
+   }
+}
+
 /**
  * Get thread specific current flow workspace.
  *

[PATCH v3] eal: add notes to SMP memory barrier APIs

[Ruifeng Wang]

The rte_smp_xx() APIs are deprecated. But it is not mentioned
in the function header.
Added notes in function header for clarification.

Signed-off-by: Ruifeng Wang 
---
v3: Added suggested memory ordering semantic for replacement.
Refined deprecation explanation.
v2: Made the notes more specific.

 lib/eal/include/generic/rte_atomic.h | 30 
 1 file changed, 30 insertions(+)

diff --git a/lib/eal/include/generic/rte_atomic.h 
b/lib/eal/include/generic/rte_atomic.h
index 58df843c54..aef44e2455 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -55,6 +55,14 @@ static inline void rte_rmb(void);
  * Guarantees that the LOAD and STORE operations that precede the
  * rte_smp_mb() call are globally visible across the lcores
  * before the LOAD and STORE operations that follows it.
+ *
+ * @note
+ *  This function is deprecated.
+ *  It provides similar synchronization primitive as atomic fence,
+ *  but has different syntax and memory ordering semantic. Hence
+ *  deprecated for the simplicity of memory ordering semantics in use.
+ *
+ *  rte_atomic_thread_fence(__ATOMIC_ACQ_REL) should be used instead.
  */
 static inline void rte_smp_mb(void);
 
@@ -64,6 +72,17 @@ static inline void rte_smp_mb(void);
  * Guarantees that the STORE operations that precede the
  * rte_smp_wmb() call are globally visible across the lcores
  * before the STORE operations that follows it.
+ *
+ * @note
+ *  This function is deprecated.
+ *  It provides similar synchronization primitive as atomic fence,
+ *  but has different syntax and memory ordering semantic. Hence
+ *  deprecated for the simplicity of memory ordering semantics in use.
+ *
+ *  rte_atomic_thread_fence(__ATOMIC_RELEASE) should be used instead.
+ *  The fence also guarantees LOAD operations that precede the call
+ *  are globally visible across the lcores before the STORE operations
+ *  that follows it.
  */
 static inline void rte_smp_wmb(void);
 
@@ -73,6 +92,17 @@ static inline void rte_smp_wmb(void);
  * Guarantees that the LOAD operations that precede the
  * rte_smp_rmb() call are globally visible across the lcores
  * before the LOAD operations that follows it.
+ *
+ * @note
+ *  This function is deprecated.
+ *  It provides similar synchronization primitive as atomic fence,
+ *  but has different syntax and memory ordering semantic. Hence
+ *  deprecated for the simplicity of memory ordering semantics in use.
+ *
+ *  rte_atomic_thread_fence(__ATOMIC_ACQUIRE) should be used instead.
+ *  The fence also guarantees LOAD operations that precede the call
+ *  are globally visible across the lcores before the STORE operations
+ *  that follows it.
  */
 static inline void rte_smp_rmb(void);
 ///@}
-- 
2.25.1

[PATCH v2] graph: fix graph model check in core binding

[Zhirun Yan]

Fix graph model check in core binding with graph. And rte_graph_clone()
need to use valid params rather than NULL pointer.
Update release notes for new mcore dispatch model.

Signed-off-by: Zhirun Yan 
---
 app/test/test_graph.c  | 15 ---
 doc/guides/rel_notes/release_23_07.rst | 12 
 lib/graph/graph.c  |  2 +-
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/app/test/test_graph.c b/app/test/test_graph.c
index 8609c0b3a4..8983363c8e 100644
--- a/app/test/test_graph.c
+++ b/app/test/test_graph.c
@@ -702,6 +702,7 @@ 
test_graph_model_mcore_dispatch_node_lcore_affinity_set(void)
unsigned int worker_lcore = RTE_MAX_LCORE;
rte_node_t nid = RTE_NODE_ID_INVALID;
char node_name[64] = "test_node00";
+   struct rte_graph_param graph_conf;
struct rte_node *node;
int ret = 0;
 
@@ -711,7 +712,7 @@ 
test_graph_model_mcore_dispatch_node_lcore_affinity_set(void)
printf("Set node %s affinity to lcore %u\n", node_name, 
worker_lcore);
 
nid = rte_node_from_name(node_name);
-   cloned_graph_id = rte_graph_clone(graph_id, "cloned-test1", NULL);
+   cloned_graph_id = rte_graph_clone(graph_id, "cloned-test1", 
&graph_conf);
node = rte_graph_node_get(cloned_graph_id, nid);
 
if (node->dispatch.lcore_id != worker_lcore) {
@@ -729,11 +730,18 @@ test_graph_model_mcore_dispatch_core_bind_unbind(void)
 {
rte_graph_t cloned_graph_id = RTE_GRAPH_ID_INVALID;
unsigned int worker_lcore = RTE_MAX_LCORE;
+   struct rte_graph_param graph_conf;
struct rte_graph *graph;
int ret = 0;
 
worker_lcore = rte_get_next_lcore(worker_lcore, true, 1);
-   cloned_graph_id = rte_graph_clone(graph_id, "cloned-test2", NULL);
+   cloned_graph_id = rte_graph_clone(graph_id, "cloned-test2", 
&graph_conf);
+
+   ret = rte_graph_worker_model_set(RTE_GRAPH_MODEL_MCORE_DISPATCH);
+   if (ret != 0) {
+   printf("Set graph mcore dispatch model failed\n");
+   ret = -1;
+   }
 
ret = rte_graph_model_mcore_dispatch_core_bind(cloned_graph_id, 
worker_lcore);
if (ret != 0) {
@@ -765,10 +773,11 @@ static int
 test_graph_worker_model_set_get(void)
 {
rte_graph_t cloned_graph_id = RTE_GRAPH_ID_INVALID;
+   struct rte_graph_param graph_conf;
struct rte_graph *graph;
int ret = 0;
 
-   cloned_graph_id = rte_graph_clone(graph_id, "cloned-test3", NULL);
+   cloned_graph_id = rte_graph_clone(graph_id, "cloned-test3", 
&graph_conf);
ret = rte_graph_worker_model_set(RTE_GRAPH_MODEL_MCORE_DISPATCH);
if (ret != 0) {
printf("Set graph mcore dispatch model failed\n");
diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index 4459144140..adaecb3e7c 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -185,6 +185,13 @@ New Features
 
   * Added SM2 algorithm support in asymmetric crypto operations.
 
+* **Added mcore dispatch model in rte_graph library.**
+
+  * Added set, get and validate model APIs to enhance graph framework
+to chose different walk models.
+  * Added clone graph, bind graph with lcore and affinity node with
+lcore APIs to support mcore dispatch model.
+
 * **Added PDCP Library.**
 
   Added an experimental library to provide PDCP UL and DL processing of 
packets.
@@ -200,6 +207,11 @@ New Features
 
   Enhanced the GRO library to support TCP packets over IPv6 network.
 
+* **Update l3fwd-graph sample application.**
+
+  Added a new cmdline option ``--model`` which can be used to chose
+  RTC or mcore dispatch model.
+
 
 Removed Items
 -
diff --git a/lib/graph/graph.c b/lib/graph/graph.c
index 0c28d925bc..26f0968a97 100644
--- a/lib/graph/graph.c
+++ b/lib/graph/graph.c
@@ -287,7 +287,7 @@ rte_graph_model_mcore_dispatch_core_bind(rte_graph_t id, 
int lcore)
if (graph->id == id)
break;
 
-   if (graph->graph->model == RTE_GRAPH_MODEL_MCORE_DISPATCH)
+   if (graph->graph->model != RTE_GRAPH_MODEL_MCORE_DISPATCH)
goto fail;
 
graph->lcore_id = lcore;
-- 
2.37.2

[PATCH v2 1/2] node: add IPv4 local node to handle local pkts

[Rakesh Kudurumalla]

Local or Host destined pkts can be redirected IPv4 local node
using IP4 Lookup node entries with prefix of 32 and be redirected
to this IP4 local node for further processing.

Signed-off-by: Rakesh Kudurumalla 
---
Depends-on: series-28622 ("add inbuilt graph nodes data flow")

v2 :
   - Resolve compilation on intel

 doc/guides/prog_guide/graph_lib.rst   |  15 ++
 .../img/graph_inbuilt_node_flow.svg   | 138 ++
 lib/node/ip4_local.c  |  88 +++
 lib/node/ip4_lookup.c |   1 +
 lib/node/meson.build  |   1 +
 lib/node/rte_node_ip4_api.h   |  12 ++
 6 files changed, 196 insertions(+), 59 deletions(-)
 create mode 100644 lib/node/ip4_local.c

diff --git a/doc/guides/prog_guide/graph_lib.rst 
b/doc/guides/prog_guide/graph_lib.rst
index 96af29e8da..eaa8ee337e 100644
--- a/doc/guides/prog_guide/graph_lib.rst
+++ b/doc/guides/prog_guide/graph_lib.rst
@@ -498,3 +498,18 @@ Uses ``poll`` function to poll on the socket fd
 for ``POLLIN`` events to read the packets from raw socket
 to stream buffer and does ``rte_node_next_stream_move()``
 when there are received packets.
+
+ip4_local
+~
+This node is an intermediate node that does ``packet_type`` lookup for
+the received ipv4 packets and the result determines each packets next node.
+
+On successful ``packet_type`` lookup, for any IPv4 protocol the result
+contains the ``next_node`` id and ``next-hop`` id with which the packet
+needs to be further processed.
+
+On packet_type lookup failure, objects are redirected to ``pkt_drop`` node.
+``rte_node_ip4_route_add()`` is control path API to add ipv4 address with 32 
bit
+depth to receive to packets.
+To achieve home run, node use ``rte_node_stream_move()`` as mentioned in above
+sections.
diff --git a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg 
b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
index 02fe768dfe..7a3ace48dc 100644
--- a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
+++ b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
@@ -37,174 +37,194 @@ digraph dpdk_inbuilt_nodes_flow {
 ethdev_tx -> pkt_drop [color="cyan" style="dashed"]
 pkt_cls->pkt_drop   [color="cyan" style="dashed"]
 kernel_tx -> kernel_rx [color="red" style="dashed"]
+ip4_lookup -> ip4_local
+ip4_local -> pkt_drop [color="cyan" style="dashed"]
 }
 
  -->
 
 
-http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
-
+http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
+
 dpdk_inbuilt_nodes_flow
-
+
 
 
 ethdev_rx
-
-ethdev_rx
+
+ethdev_rx
 
 
 
 pkt_cls
-
-pkt_cls
+
+pkt_cls
 
 
 
 ethdev_rx->pkt_cls
-
-
+
+
 
 
 
 kernel_rx
-
-kernel_rx
+
+kernel_rx
 
 
 
 kernel_rx->pkt_cls
-
-
+
+
 
 
 
 ethdev_tx
-
-ethdev_tx
+
+ethdev_tx
 
 
 
 pkt_drop
-
-pkt_drop
+
+pkt_drop
 
 
 
 ethdev_tx->pkt_drop
-
-
+
+
 
 
 
 kernel_tx
-
-kernel_tx
+
+kernel_tx
 
 
 
 kernel_tx->kernel_rx
-
-
+
+
 
 
 
 pkt_cls->pkt_drop
-
-
+
+
 
 
 
 pkt_cls->kernel_tx
-
-
-exception pkts
+
+
+exception pkts
 
 
 
 ip4_lookup
-
-ip4_lookup
+
+ip4_lookup
 
 
 
 pkt_cls->ip4_lookup
-
-
-ipv4
+
+
+ipv4
 
 
 
 ip6_lookup
-
-ip6_lookup
+
+ip6_lookup
 
 
 
 pkt_cls->ip6_lookup
-
-
-ipv6
+
+
+ipv6
 
 
 
 ip4_lookup->pkt_drop
-
-
+
+
 
 
 
 ip4_rewrite
-
-ip4_rewrite
+
+ip4_rewrite
 
 
 
 ip4_lookup->ip4_rewrite
-
-
+
+
+
+
+
+ip4_local
+
+ip4_local
+
+
+
+ip4_lookup->ip4_local
+
+
 
 
 
 ip6_lookup->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite
-
-ip6_rewrite
+
+ip6_rewrite
 
 
 
 ip6_lookup->ip6_rewrite
-
-
+
+
 
 
 
 ip4_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip4_rewrite->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip6_rewrite->pkt_drop
-
-
+
+
+
+
+
+ip4_local->pkt_drop
+
+
 
 
 
diff --git a/lib/node/ip4_local.c b/lib/node/ip4_local.c
new file mode 100644
index 00..fb31d0f970
--- /dev/null
+++ b/lib/node/ip4_local.c
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#include "rte_node_ip4_api.h"
+
+#include "node_private.h"
+
+static uint16_t
+ip4_local_node_process_scalar(struct rte_graph *graph, struct rte_node *node,
+ void **objs, uint16_t nb_objs)
+{
+   void **to_next, **from;
+   uint16_t last_spec = 0;
+   rte_edge_t next_index;
+   struct rte_mbuf *mbuf;
+   uint16_t held = 0;
+   uint32_t l4;
+   int i;
+
+   /* Speculative next */
+   next_index = RTE_NODE_IP4_LOCAL_NEXT_UDP4_INPUT;
+
+   from = objs;
+   to_next = rte_node_next_stream_get(graph, node, next_index, nb_objs);
+   for (i = 0; i < nb_objs; i++) {
+   uint16_t next;
+
+   mbuf = (struct rte_mbuf *)objs[i];
+   l4 = mbuf->packet_type & RTE_PTYPE_L4_MASK;
+
+

[PATCH v2 2/2] node: add UDP v4 support

[Rakesh Kudurumalla]

IPv4 UDP packets are given to application
with specified UDP destination port given
by user.

Signed-off-by: Rakesh Kudurumalla 
---
 doc/api/doxy-api-index.md |   3 +-
 doc/guides/prog_guide/graph_lib.rst   |  25 ++
 .../img/graph_inbuilt_node_flow.svg   | 165 -
 lib/node/meson.build  |   2 +
 lib/node/rte_node_udp4_input_api.h|  60 +
 lib/node/udp4_input.c | 226 ++
 lib/node/version.map  |   2 +
 7 files changed, 417 insertions(+), 66 deletions(-)
 create mode 100644 lib/node/rte_node_udp4_input_api.h
 create mode 100644 lib/node/udp4_input.c

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 3bc8778981..b81777b3fb 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -209,7 +209,8 @@ The public API headers are grouped by topics:
   * graph_nodes:
 [eth_node](@ref rte_node_eth_api.h),
 [ip4_node](@ref rte_node_ip4_api.h),
-[ip6_node](@ref rte_node_ip6_api.h)
+[ip6_node](@ref rte_node_ip6_api.h),
+[udp4_input_node](@ref rte_node_udp4_input_api.h)
 
 - **basic**:
   [bitops](@ref rte_bitops.h),
diff --git a/doc/guides/prog_guide/graph_lib.rst 
b/doc/guides/prog_guide/graph_lib.rst
index eaa8ee337e..98473383f1 100644
--- a/doc/guides/prog_guide/graph_lib.rst
+++ b/doc/guides/prog_guide/graph_lib.rst
@@ -513,3 +513,28 @@ On packet_type lookup failure, objects are redirected to 
``pkt_drop`` node.
 depth to receive to packets.
 To achieve home run, node use ``rte_node_stream_move()`` as mentioned in above
 sections.
+
+udp4_input
+~~
+This node is an intermediate node that does udp destination port lookup for
+the received ipv4 packets and the result determines each packets next node.
+
+User registers a new node ``udp4_input`` into graph library during 
initialization
+and attach user specified node as edege to this node using
+``rte_node_udp4_usr_node_add()``, and create empty hash table with destination
+port and node id as its feilds.
+
+After successful addition of user node as edege, edge id is returned to the 
user.
+
+User would register ``ip4_lookup`` table with specified ip address and 32 bit 
as mask
+for ip filtration using api ``rte_node_ip4_route_add()``.
+
+After graph is created user would update hash table with custom port with
+and previously obtained edge id using API ``rte_node_udp4_dst_port_add()``.
+
+When packet is received lpm look up is performed if ip is matched the packet
+is handed over to ip4_local node, then packet is verified for udp proto and
+on success packet is enqueued to ``udp4_input`` node.
+
+Hash lookup is performed in ``udp4_input`` node with registered destination 
port
+and destination port in UDP packet , on success packet is handed to 
``udp_user_node``.
diff --git a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg 
b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
index 7a3ace48dc..5db96adb01 100644
--- a/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
+++ b/doc/guides/prog_guide/img/graph_inbuilt_node_flow.svg
@@ -39,192 +39,227 @@ digraph dpdk_inbuilt_nodes_flow {
 kernel_tx -> kernel_rx [color="red" style="dashed"]
 ip4_lookup -> ip4_local
 ip4_local -> pkt_drop [color="cyan" style="dashed"]
+ip4_local -> udp4_input [ label="udpv4"]
+udp4_input -> udp_user_node
+udp4_input -> pkt_drop [color="cyan" style="dashed"]
+
 }
 
  -->
 
 
-http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
-
+http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink";>
+
 dpdk_inbuilt_nodes_flow
-
+
 
 
 ethdev_rx
-
-ethdev_rx
+
+ethdev_rx
 
 
 
 pkt_cls
-
-pkt_cls
+
+pkt_cls
 
 
 
 ethdev_rx->pkt_cls
-
-
+
+
 
 
 
 kernel_rx
-
-kernel_rx
+
+kernel_rx
 
 
 
 kernel_rx->pkt_cls
-
-
+
+
 
 
 
 ethdev_tx
-
-ethdev_tx
+
+ethdev_tx
 
 
 
 pkt_drop
-
-pkt_drop
+
+pkt_drop
 
 
 
 ethdev_tx->pkt_drop
-
-
+
+
 
 
 
 kernel_tx
-
-kernel_tx
+
+kernel_tx
 
 
 
 kernel_tx->kernel_rx
-
-
+
+
 
 
 
 pkt_cls->pkt_drop
-
-
+
+
 
 
 
 pkt_cls->kernel_tx
-
-
-exception pkts
+
+
+exception pkts
 
 
 
 ip4_lookup
-
-ip4_lookup
+
+ip4_lookup
 
 
 
 pkt_cls->ip4_lookup
-
-
-ipv4
+
+
+ipv4
 
 
 
 ip6_lookup
-
-ip6_lookup
+
+ip6_lookup
 
 
 
 pkt_cls->ip6_lookup
-
-
-ipv6
+
+
+ipv6
 
 
 
 ip4_lookup->pkt_drop
-
-
+
+
 
 
 
 ip4_rewrite
-
-ip4_rewrite
+
+ip4_rewrite
 
 
 
 ip4_lookup->ip4_rewrite
-
-
+
+
 
 
 
 ip4_local
-
-ip4_local
+
+ip4_local
 
 
 
 ip4_lookup->ip4_local
-
-
+
+
 
 
 
 ip6_lookup->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite
-
-ip6_rewrite
+
+ip6_rewrite
 
 
 
 ip6_lookup->ip6_rewrite
-
-
+
+
 
 
 
 ip4_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip4_rewrite->pkt_drop
-
-
+
+
 
 
 
 ip6_rewrite->ethdev_tx
-
-
+
+
 
 
 
 ip6_rewrite->pkt_drop
-
-
+
+
 
 
 
 ip4_local->pkt_drop
-
-
+
+
+
+
+
+udp4_input
+
+udp4_input
+
+
+
+ip4_local->udp4_input
+
+
+udpv4
+
+
+
+udp4_input->pkt_drop
+
+
+
+
+
+udp_user_node
+
+udp

Re: [PATCH v14 5/6] memarea: support dump API

[Burakov, Anatoly]

On 6/28/2023 2:39 AM, Thomas Monjalon wrote:

28/06/2023 03:25, fengchengwen:

Hi Anatoly,

   Thanks for your review, a lot of valuable advice.

   PS: This library stays for a long time, want to hear TB's opinion: whether 
to continue or stop.
   If continue I will push a new version.


Would you be able to attend the techboard meeting today (3pm UTC)?
https://core.dpdk.org/techboard/minutes/
We could discuss the value of this library.
Anatoly, would you be able to prepare some arguments as well?




Apologies, I missed this email :( I don't see any minutes, there was no 
techboard?


As for "arguments", I have no strong opinions on whether this library 
should be added or not. It seems like a viable alternative to using 
mempools when a certain amount of scratch space is needed for whatever 
reasons (I remember having discussions about current allocator being too 
heavyweight for this kind of scenario), so to me, it's not that I'm 
particularly fond of the library, it's moreso that I think that it 
sounds useful and I don't have any strong objections to its inclusion.


--
Thanks,
Anatoly

Re: [PATCH] eal: fix file descriptor leakage with unhandled messages

[Burakov, Anatoly]

On 6/28/2023 1:19 PM, Viacheslav Ovsiienko wrote:

The sendmsg()/recvmsg() API is used to establish communication between
the DPDK processes. The API supposes inter-process file descriptors
sending and conversion, the recipient sees the resulting descriptors
in the received message - the operating systems creates ones in the
right context.

The message receiving is performed by EAL in the dedicated thread
and it might happen the message is received by EAL and not handled
by addressed PMD or application due to some reasons (timeouts, race
condition, etc). EAL just dropped unhandled messages causing the
file descriptor leakage if these ones were presented in the message.

The patch closes the descriptors (if any) in unhandled messages.

Fixes: 783b6e54971 ("eal: add synchronous multi-process communication")
Cc: sta...@dpdk.org

Signed-off-by: Viacheslav Ovsiienko 
---


Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

RE: [PATCH v2] net/mlx5: fix the error set in Tx representor tagging

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 12:13 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Dariusz Sosnowski ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix the error set in Tx representor tagging
> 
> In the previous implementation, the error information was not set when there
> was a failure during the initialization.
> 
> The pointer from the user should be passed to the called functions to be set
> properly before returning.
> 
> Fixes: 483181f7b6dd ("net/mlx5: support device control of representor
> matching")
> Cc: dsosnow...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Ori Kam 
> ---
> v2: CC stable

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH v2] net/mlx5: fix the return value of vport action

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 12:22 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Dariusz Sosnowski ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix the return value of vport action
> 
> The "rte_flow_error" should be set in case a invalid pointer access to the
> message member.
> 
> Fixes: 1939eb6f660c ("net/mlx5: support flow port action with HWS")
> Cc: dsosnow...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Ori Kam 
> ---
> v2: add CC stable

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH v3] net/mlx5: fix the error set in control tables create

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 12:47 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Dariusz Sosnowski ;
> sta...@dpdk.org
> Subject: [PATCH v3] net/mlx5: fix the error set in control tables create
> 
> When some failure occurs in the flow_hw_create_ctrl_tables(), the
> "rte_flow_error" should be set properly with all needed information.
> Then the rte_errno and the "message" will reflect the actual failure.
> 
> This will also solve the crash when trying to access the "message".
> 
> Fixes: 1939eb6f660c ("net/mlx5: support flow port action with HWS")
> Fixes: 483181f7b6dd ("net/mlx5: support device control of representor
> matching")
> Fixes: ddb68e47331e ("net/mlx5: add extended metadata mode for HWS")
> Cc: dsosnow...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Reviewed-by: Suanming Mou 
> Acked-by: Ori Kam 
> ---
> v2: add CC stable
> v3: fix the typo

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH v4] bitmap: add scan from offset function

[Dumitrescu, Cristian]

> -Original Message-
> From: Volodymyr Fialko 
> Sent: Monday, July 3, 2023 10:31 AM
> To: dev@dpdk.org; Dumitrescu, Cristian 
> Cc: jer...@marvell.com; ano...@marvell.com; tho...@monjalon.net;
> Volodymyr Fialko 
> Subject: [PATCH v4] bitmap: add scan from offset function
> 
> Currently, in the case when we search for a bit set after a particular
> value, the bitmap has to be scanned from the beginning and
> rte_bitmap_scan() has to be called multiple times until we hit the value.
> 
> Add a new rte_bitmap_scan_from_offset() function to initialize scan
> state at the given offset and perform scan, this will allow getting
> the next set bit after certain offset within one scan call.
> 
> Signed-off-by: Volodymyr Fialko 
> ---
> v2:
>  - added rte_bitmap_scan_from_offset
> v3:
>  - added note for internal use only for init_at function
> v4:
>  - marked init_at function as __rte_internal
> 
>  app/test/test_bitmap.c   | 33 -
>  lib/eal/include/rte_bitmap.h | 56 

Acked-by: Cristian Dumitrescu 

RE: [PATCH v3] bitmap: add scan from offset function

[Volodymyr Fialko]

Since it's header-only library, there is issue with using __rte_intenal 
(appeared in v4).
Even if the function itself is not used directly, it get's included to the 
other public files.
It explains why other functions in this library does not have the rte_internal 
prefix, but the double underscores.
So, should I simply remove __rte_internal from v4, or there's another approach 
to resolve this issue(beside creating .c file)?

/Volodymyr

> -Original Message-
> From: Dumitrescu, Cristian 
> Sent: Friday, June 23, 2023 2:41 PM
> To: Thomas Monjalon ; Volodymyr Fialko 
> 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Anoob Joseph
> 
> Subject: [EXT] RE: [PATCH v3] bitmap: add scan from offset function
> 
> External Email
> 
> --
> 
> 
> > -Original Message-
> > From: Thomas Monjalon 
> > Sent: Thursday, June 22, 2023 6:45 PM
> > To: Volodymyr Fialko 
> > Cc: dev@dpdk.org; Dumitrescu, Cristian
> > ; jer...@marvell.com;
> > ano...@marvell.com
> > Subject: Re: [PATCH v3] bitmap: add scan from offset function
> >
> > 21/06/2023 12:01, Volodymyr Fialko:
> > > Currently, in the case when we search for a bit set after a
> > > particular value, the bitmap has to be scanned from the beginning
> > > and
> > > rte_bitmap_scan() has to be called multiple times until we hit the value.
> > >
> > > Add a new rte_bitmap_scan_from_offset() function to initialize scan
> > > state at the given offset and perform scan, this will allow getting
> > > the next set bit after certain offset within one scan call.
> > >
> > > Signed-off-by: Volodymyr Fialko 
> > > ---
> > > v2:
> > >  - added rte_bitmap_scan_from_offset
> > > v3
> > >  - added note for internal use only for init_at function
> > [...]
> > > +/**
> > > + * @warning
> > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > + *
> > > + * Bitmap initialize internal scan pointers at the given position
> > > +for the scan
> > function.
> > > + *
> > > + * Note: for private/internal use, for public:
> > > + * @see rte_bitmap_scan_from_offset()
> > > + *
> > > + * @param bmp
> > > + *   Handle to bitmap instance
> > > + * @param pos
> > > + *   Bit position to start scan
> > > + */
> > > +__rte_experimental
> > > +static inline void
> > > +__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
> >
> > I think it should marked with __rte_internal instead of experimental.
> >
> >
> 
> 
> +1

RE: [dpdk-dev] [PATCH 06/10] lib/librte_pipeline: fix the use of unsafe strcpy

[Dumitrescu, Cristian]

> -Original Message-
> From: Stephen Hemminger 
> Sent: Friday, June 30, 2023 7:09 PM
> To: Min Hu (Connor) 
> Cc: dev@dpdk.org; ferruh.yi...@intel.com; Dumitrescu, Cristian
> ; jer...@marvell.com;
> jianjay.z...@huawei.com; jia@intel.com; g.si...@nxp.com;
> andrew.rybche...@oktetlabs.ru; hemant.agra...@nxp.com; or...@nvidia.com
> Subject: Re: [dpdk-dev] [PATCH 06/10] lib/librte_pipeline: fix the use of 
> unsafe
> strcpy
> 
> On Mon, 19 Apr 2021 21:34:45 +0800
> "Min Hu (Connor)"  wrote:
> 
> > From: HongBo Zheng 
> >
> > 'strcpy' is called in rte_swx_ctl_table_info_get, this function
> > is unsafe, use 'strncpy' instead.
> >
> > Fixes: 393b96e2aa2a ("pipeline: add SWX pipeline query API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: HongBo Zheng 
> > Signed-off-by: Min Hu (Connor) 
> > ---
> >  lib/librte_pipeline/rte_swx_pipeline.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_pipeline/rte_swx_pipeline.c
> b/lib/librte_pipeline/rte_swx_pipeline.c
> > index 4455d91..d4db4dd 100644
> > --- a/lib/librte_pipeline/rte_swx_pipeline.c
> > +++ b/lib/librte_pipeline/rte_swx_pipeline.c
> > @@ -9447,8 +9447,8 @@ rte_swx_ctl_table_info_get(struct rte_swx_pipeline
> *p,
> > if (!t)
> > return -EINVAL;
> >
> > -   strcpy(table->name, t->name);
> > -   strcpy(table->args, t->args);
> > +   strncpy(table->name, t->name, RTE_SWX_CTL_NAME_SIZE);
> > +   strncpy(table->args, t->args, RTE_SWX_CTL_NAME_SIZE);
> > table->n_match_fields = t->n_fields;
> > table->n_actions = t->n_actions;
> > table->default_action_is_const = t->default_action_is_const;
> 
> This patch is unnecessary.
> Both structures declare the same size for the name and args.
> Therefore the strcpy is always safe as long as the table structure
> is correctly setup with null terminated string. If not there are worse bugs.


+1
Agree with Steve, this is not necessary here.

[PATCH] app/testpmd: fix invalid queue ID when start port

[Jie Hai]

Function update_queue_state updates queue state of all queues
of all ports, using the queue num nb_rxq|nb_txq stored locally
by testpmd. Error on invalid queue ID occurs if we start testpmd
with two ports and detach-attach one of them and start the other
port first. That's because the attached port has zero queues and
that differs from the nb_rxq|nb_txq. The similar error happens
in multi-process senoris if secondary process attaches a port
and starts it.

This patch updates queue state according to the num of queues
reported by driver instead of testpmd.

Fixes: 141a520b35f7 ("app/testpmd: fix primary process not polling all queues")
Fixes: 5028f207a4fa ("app/testpmd: fix secondary process packet forwarding")
Cc: sta...@dpdk.org

Signed-off-by: Jie Hai 
---
 app/test-pmd/testpmd.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1fc70650e0a4..c8ce67d0de9f 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2479,13 +2479,22 @@ update_tx_queue_state(uint16_t port_id, uint16_t 
queue_id)
 static void
 update_queue_state(void)
 {
+   struct rte_port *port;
+   uint16_t nb_rx_queues;
+   uint16_t nb_tx_queues;
portid_t pi;
queueid_t qi;
 
RTE_ETH_FOREACH_DEV(pi) {
-   for (qi = 0; qi < nb_rxq; qi++)
+   port = &ports[pi];
+   if (eth_dev_info_get_print_err(pi, &port->dev_info) != 0)
+   continue;
+
+   nb_rx_queues = RTE_MIN(nb_rxq, port->dev_info.nb_rx_queues);
+   nb_tx_queues = RTE_MIN(nb_txq, port->dev_info.nb_tx_queues);
+   for (qi = 0; qi < nb_rx_queues; qi++)
update_rx_queue_state(pi, qi);
-   for (qi = 0; qi < nb_txq; qi++)
+   for (qi = 0; qi < nb_tx_queues; qi++)
update_tx_queue_state(pi, qi);
}
 }
-- 
2.33.0

[PATCH] set namespace prefix to threads

[Thomas Monjalon]

When looking at threads in a system, it can be confusing
to find some unknown threads without a clue it is started by DPDK.

Let's start all thread names with "dpdk-"
and the driver name if it comes from a driver.

One more constraint: the thread names are generally limited
to 16 characters, including NUL character.

Signed-off-by: Thomas Monjalon 
---
Please review carefully, I may have missed things.

Note: we should use rte_ctrl_thread_create() as much as possible.

---
 app/test/test_lcores.c  | 2 +-
 drivers/event/dlb2/pf/base/dlb2_osdep.h | 2 +-
 drivers/net/ark/ark_ethdev.c| 4 ++--
 drivers/net/ipn3ke/ipn3ke_representor.c | 2 +-
 drivers/net/kni/rte_eth_kni.c   | 2 +-
 drivers/net/mlx5/mlx5_hws_cnt.c | 2 +-
 drivers/net/sfc/sfc_mae_counter.c   | 2 +-
 drivers/raw/ifpga/ifpga_rawdev.c| 2 +-
 drivers/vdpa/ifc/ifcvf_vdpa.c   | 6 +++---
 drivers/vdpa/mlx5/mlx5_vdpa_cthread.c   | 2 +-
 drivers/vdpa/mlx5/mlx5_vdpa_event.c | 2 +-
 examples/vhost/main.c   | 4 ++--
 examples/vhost_blk/vhost_blk.c  | 2 +-
 lib/eal/common/eal_common_proc.c| 2 +-
 lib/eal/freebsd/eal.c   | 2 +-
 lib/eal/freebsd/eal_interrupts.c| 2 +-
 lib/eal/linux/eal.c | 2 +-
 lib/eal/linux/eal_interrupts.c  | 2 +-
 lib/eal/linux/eal_timer.c   | 2 +-
 lib/eal/windows/eal.c   | 2 +-
 lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
 lib/telemetry/telemetry.c   | 4 ++--
 lib/vhost/socket.c  | 4 ++--
 lib/vhost/vduse.c   | 2 +-
 24 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/app/test/test_lcores.c b/app/test/test_lcores.c
index 2c945b0136..9522663f1a 100644
--- a/app/test/test_lcores.c
+++ b/app/test/test_lcores.c
@@ -362,7 +362,7 @@ test_ctrl_thread(void)
/* Create one control thread */
t = &ctrl_thread_context;
t->state = Thread_INIT;
-   if (rte_ctrl_thread_create((pthread_t *)&t->id, "test_ctrl_threads",
+   if (rte_ctrl_thread_create((pthread_t *)&t->id, "dpdk-test-ctrlt",
NULL, ctrl_thread_loop, t) != 0)
return -1;
 
diff --git a/drivers/event/dlb2/pf/base/dlb2_osdep.h 
b/drivers/event/dlb2/pf/base/dlb2_osdep.h
index cffe22f3c5..75860cca4d 100644
--- a/drivers/event/dlb2/pf/base/dlb2_osdep.h
+++ b/drivers/event/dlb2/pf/base/dlb2_osdep.h
@@ -200,7 +200,7 @@ static inline void os_schedule_work(struct dlb2_hw *hw)
dlb2_dev = container_of(hw, struct dlb2_dev, hw);
 
ret = rte_ctrl_thread_create(&complete_queue_map_unmap_thread,
-"dlb_queue_unmap_waiter",
+"dpdk-dlb-qunmap",
 NULL,
 dlb2_complete_queue_map_unmap,
 dlb2_dev);
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index b2995427c8..30814650bf 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -600,11 +600,11 @@ eth_ark_dev_start(struct rte_eth_dev *dev)
if (!ark->isvf && ark->start_pg && !ark->pg_running) {
pthread_t thread;
 
-   /* Delay packet generatpr start allow the hardware to be ready
+   /* Delay packet generator start allow the hardware to be ready
 * This is only used for sanity checking with internal generator
 */
char tname[32];
-   snprintf(tname, sizeof(tname), "ark-delay-pg-%d",
+   snprintf(tname, sizeof(tname), "dpdk-ark-pg%d",
 dev->data->port_id);
 
if (rte_ctrl_thread_create(&thread, tname, NULL,
diff --git a/drivers/net/ipn3ke/ipn3ke_representor.c 
b/drivers/net/ipn3ke/ipn3ke_representor.c
index e50fc73f43..c82f8b5333 100644
--- a/drivers/net/ipn3ke/ipn3ke_representor.c
+++ b/drivers/net/ipn3ke/ipn3ke_representor.c
@@ -2593,7 +2593,7 @@ ipn3ke_rpst_scan_check(void)
 
if (ipn3ke_rpst_scan_num == 1) {
ret = rte_ctrl_thread_create(&ipn3ke_rpst_scan_thread,
-   "ipn3ke scanner",
+   "dpdk-ipn3ke-scn",
NULL,
ipn3ke_rpst_scan_handle_request, NULL);
if (ret) {
diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c
index c0e1f8db40..6b90c4e9b5 100644
--- a/drivers/net/kni/rte_eth_kni.c
+++ b/drivers/net/kni/rte_eth_kni.c
@@ -163,7 +163,7 @@ eth_kni_dev_start(struct rte_eth_dev *dev)
internals->stop_thread = 0;
 
ret = rte_ctrl_thread_create(&internals->thread,
-   "kni_handle_req", NULL,
+   "dpdk-kni-req", NULL,
kni_handle_request, internals);
if (ret) {
PMD_LO

RE: [EXT] [PATCH v4 0/3] Replace obsolote test cases.

[Gowrishankar Muthukrishnan]

Series verified with openssl pmd.

Acked-by: Gowrishankar Muthukrishnan 

Thanks.

Re: [PATCH] set namespace prefix to threads

[David Marchand]

On Mon, Jul 3, 2023 at 1:24 PM Thomas Monjalon  wrote:
>
> When looking at threads in a system, it can be confusing
> to find some unknown threads without a clue it is started by DPDK.
>
> Let's start all thread names with "dpdk-"
> and the driver name if it comes from a driver.
>
> One more constraint: the thread names are generally limited
> to 16 characters, including NUL character.

Yes, and no way to discover this limit.


>
> Signed-off-by: Thomas Monjalon 
> ---
> Please review carefully, I may have missed things.
>
> Note: we should use rte_ctrl_thread_create() as much as possible.
>

As for this comment, we should advertise rte_thread_create_control()
instead, as it is thread library agnostic.
Which leads me to suggest looking at rte_thread_create_control() calls too.


> diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
> index 7008303e11..e201acd1c2 100644
> --- a/lib/eal/freebsd/eal.c
> +++ b/lib/eal/freebsd/eal.c
> @@ -843,7 +843,7 @@ rte_eal_init(int argc, char **argv)
>
> /* Set thread_name for aid in debugging. */
> snprintf(thread_name, sizeof(thread_name),
> -   "rte-worker-%d", i);
> +   "dpdk-worker-%d", i);
> rte_thread_set_name(lcore_config[i].thread_id, thread_name);
>
> ret = rte_thread_set_affinity_by_id(lcore_config[i].thread_id,

We changed this not so long ago with 8ae946970ed3 ("eal: fix thread
name for high order lcores") which offered up to 4 digits for lcores.
With your proposal, we are back to only 3 digits, which is probably
enough, but I preferred to raise it.



-- 
David Marchand

Re: [PATCH] set namespace prefix to threads

[Thomas Monjalon]

03/07/2023 13:38, David Marchand:
> On Mon, Jul 3, 2023 at 1:24 PM Thomas Monjalon  wrote:
> >
> > When looking at threads in a system, it can be confusing
> > to find some unknown threads without a clue it is started by DPDK.
> >
> > Let's start all thread names with "dpdk-"
> > and the driver name if it comes from a driver.
> >
> > One more constraint: the thread names are generally limited
> > to 16 characters, including NUL character.
> 
> Yes, and no way to discover this limit.
> 
> 
> >
> > Signed-off-by: Thomas Monjalon 
> > ---
> > Please review carefully, I may have missed things.
> >
> > Note: we should use rte_ctrl_thread_create() as much as possible.
> >
> 
> As for this comment, we should advertise rte_thread_create_control()
> instead, as it is thread library agnostic.
> Which leads me to suggest looking at rte_thread_create_control() calls too.

You're right, I'll do a second pass.

> > diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
> > index 7008303e11..e201acd1c2 100644
> > --- a/lib/eal/freebsd/eal.c
> > +++ b/lib/eal/freebsd/eal.c
> > @@ -843,7 +843,7 @@ rte_eal_init(int argc, char **argv)
> >
> > /* Set thread_name for aid in debugging. */
> > snprintf(thread_name, sizeof(thread_name),
> > -   "rte-worker-%d", i);
> > +   "dpdk-worker-%d", i);
> > rte_thread_set_name(lcore_config[i].thread_id, thread_name);
> >
> > ret = 
> > rte_thread_set_affinity_by_id(lcore_config[i].thread_id,
> 
> We changed this not so long ago with 8ae946970ed3 ("eal: fix thread
> name for high order lcores") which offered up to 4 digits for lcores.
> With your proposal, we are back to only 3 digits, which is probably
> enough, but I preferred to raise it.

In general no need of hyphen before a number.
I will change to dpdk-worker%d.

Re: [PATCH v3] bitmap: add scan from offset function

[Thomas Monjalon]

03/07/2023 12:56, Volodymyr Fialko:
> Since it's header-only library, there is issue with using __rte_intenal 
> (appeared in v4).

What is the issue?

> Even if the function itself is not used directly, it get's included to the 
> other public files.
> It explains why other functions in this library does not have the 
> rte_internal prefix, but the double underscores.
> So, should I simply remove __rte_internal from v4, or there's another 
> approach to resolve this issue(beside creating .c file)?
> 
> /Volodymyr
> 
> > -Original Message-
> > From: Dumitrescu, Cristian 
> > Sent: Friday, June 23, 2023 2:41 PM
> > To: Thomas Monjalon ; Volodymyr Fialko 
> > 
> > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Anoob 
> > Joseph
> > 
> > Subject: [EXT] RE: [PATCH v3] bitmap: add scan from offset function
> > 
> > External Email
> > 
> > --
> > 
> > 
> > > -Original Message-
> > > From: Thomas Monjalon 
> > > Sent: Thursday, June 22, 2023 6:45 PM
> > > To: Volodymyr Fialko 
> > > Cc: dev@dpdk.org; Dumitrescu, Cristian
> > > ; jer...@marvell.com;
> > > ano...@marvell.com
> > > Subject: Re: [PATCH v3] bitmap: add scan from offset function
> > >
> > > 21/06/2023 12:01, Volodymyr Fialko:
> > > > Currently, in the case when we search for a bit set after a
> > > > particular value, the bitmap has to be scanned from the beginning
> > > > and
> > > > rte_bitmap_scan() has to be called multiple times until we hit the 
> > > > value.
> > > >
> > > > Add a new rte_bitmap_scan_from_offset() function to initialize scan
> > > > state at the given offset and perform scan, this will allow getting
> > > > the next set bit after certain offset within one scan call.
> > > >
> > > > Signed-off-by: Volodymyr Fialko 
> > > > ---
> > > > v2:
> > > >  - added rte_bitmap_scan_from_offset
> > > > v3
> > > >  - added note for internal use only for init_at function
> > > [...]
> > > > +/**
> > > > + * @warning
> > > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > > + *
> > > > + * Bitmap initialize internal scan pointers at the given position
> > > > +for the scan
> > > function.
> > > > + *
> > > > + * Note: for private/internal use, for public:
> > > > + * @see rte_bitmap_scan_from_offset()
> > > > + *
> > > > + * @param bmp
> > > > + *   Handle to bitmap instance
> > > > + * @param pos
> > > > + *   Bit position to start scan
> > > > + */
> > > > +__rte_experimental
> > > > +static inline void
> > > > +__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
> > >
> > > I think it should marked with __rte_internal instead of experimental.
> > >
> > >
> > 
> > 
> > +1
> 

RE: [EXT] Re: [PATCH v3] bitmap: add scan from offset function

[Volodymyr Fialko]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Monday, July 3, 2023 1:51 PM
> To: Dumitrescu, Cristian ; Volodymyr Fialko 
> 
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Anoob Joseph
> 
> Subject: [EXT] Re: [PATCH v3] bitmap: add scan from offset function
> 
> External Email
> 
> --
> 03/07/2023 12:56, Volodymyr Fialko:
> > Since it's header-only library, there is issue with using __rte_intenal 
> > (appeared in v4).
> 
> What is the issue?

>From V4 ci build 
>failure(http://mails.dpdk.org/archives/test-report/2023-July/421235.html):
In file included from ../examples/ipsec-secgw/event_helper.c:6:
../lib/eal/include/rte_bitmap.h:645:2: error: Symbol is not public ABI
__rte_bitmap_scan_init_at(bmp, offset);
   ^
../lib/eal/include/rte_bitmap.h:150:1: note: from 'diagnose_if' 
attribute on '__rte_bitmap_scan_init_at':
__rte_internal
^~
../lib/eal/include/rte_compat.h:42:16: note: expanded from macro 
'__rte_internal'   
__attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
^   ~
1 error generated.

/Volodymyr
> 
> > Even if the function itself is not used directly, it get's included to the 
> > other public files.
> > It explains why other functions in this library does not have the 
> > rte_internal prefix, but the double
> underscores.
> > So, should I simply remove __rte_internal from v4, or there's another 
> > approach to resolve this
> issue(beside creating .c file)?
> >
> > /Volodymyr
> >
> > > -Original Message-
> > > From: Dumitrescu, Cristian 
> > > Sent: Friday, June 23, 2023 2:41 PM
> > > To: Thomas Monjalon ; Volodymyr Fialko
> > > 
> > > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> > > Anoob Joseph 
> > > Subject: [EXT] RE: [PATCH v3] bitmap: add scan from offset function
> > >
> > > External Email
> > >
> > > 
> > > --
> > >
> > >
> > > > -Original Message-
> > > > From: Thomas Monjalon 
> > > > Sent: Thursday, June 22, 2023 6:45 PM
> > > > To: Volodymyr Fialko 
> > > > Cc: dev@dpdk.org; Dumitrescu, Cristian
> > > > ; jer...@marvell.com;
> > > > ano...@marvell.com
> > > > Subject: Re: [PATCH v3] bitmap: add scan from offset function
> > > >
> > > > 21/06/2023 12:01, Volodymyr Fialko:
> > > > > Currently, in the case when we search for a bit set after a
> > > > > particular value, the bitmap has to be scanned from the
> > > > > beginning and
> > > > > rte_bitmap_scan() has to be called multiple times until we hit the 
> > > > > value.
> > > > >
> > > > > Add a new rte_bitmap_scan_from_offset() function to initialize
> > > > > scan state at the given offset and perform scan, this will allow
> > > > > getting the next set bit after certain offset within one scan call.
> > > > >
> > > > > Signed-off-by: Volodymyr Fialko 
> > > > > ---
> > > > > v2:
> > > > >  - added rte_bitmap_scan_from_offset
> > > > > v3
> > > > >  - added note for internal use only for init_at function
> > > > [...]
> > > > > +/**
> > > > > + * @warning
> > > > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > > > + *
> > > > > + * Bitmap initialize internal scan pointers at the given
> > > > > +position for the scan
> > > > function.
> > > > > + *
> > > > > + * Note: for private/internal use, for public:
> > > > > + * @see rte_bitmap_scan_from_offset()
> > > > > + *
> > > > > + * @param bmp
> > > > > + *   Handle to bitmap instance
> > > > > + * @param pos
> > > > > + *   Bit position to start scan
> > > > > + */
> > > > > +__rte_experimental
> > > > > +static inline void
> > > > > +__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
> > > >
> > > > I think it should marked with __rte_internal instead of experimental.
> > > >
> > > >
> > >
> > >
> > > +1
> >
> 
> 
> 
> 

[PATCH v2] set namespace prefix to threads

[Thomas Monjalon]

When looking at threads in a system, it can be confusing
to find some unknown threads without a clue it is started by DPDK.

Let's start all thread names with "dpdk-"
plus the driver name if it comes from a driver.

One more constraint: the thread names are generally limited
to 16 characters, including the NUL character.

Signed-off-by: Thomas Monjalon 
---
Please review carefully, I may have missed things.

Note: we should use rte_thread_create_control() as much as possible.

---
 app/test/test_lcores.c  | 2 +-
 app/test/test_threads.c | 2 +-
 drivers/dma/skeleton/skeleton_dmadev.c  | 2 +-
 drivers/event/dlb2/pf/base/dlb2_osdep.h | 2 +-
 drivers/net/ark/ark_ethdev.c| 4 ++--
 drivers/net/iavf/iavf_vchnl.c   | 2 +-
 drivers/net/ice/ice_dcf_parent.c| 2 +-
 drivers/net/ipn3ke/ipn3ke_representor.c | 2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c| 2 +-
 drivers/net/kni/rte_eth_kni.c   | 2 +-
 drivers/net/mlx5/mlx5_hws_cnt.c | 6 ++
 drivers/net/sfc/sfc_mae_counter.c   | 2 +-
 drivers/raw/ifpga/ifpga_rawdev.c| 2 +-
 drivers/vdpa/ifc/ifcvf_vdpa.c   | 6 +++---
 drivers/vdpa/mlx5/mlx5_vdpa_cthread.c   | 2 +-
 drivers/vdpa/mlx5/mlx5_vdpa_event.c | 2 +-
 examples/vhost/main.c   | 4 ++--
 examples/vhost_blk/vhost_blk.c  | 2 +-
 lib/eal/common/eal_common_proc.c| 2 +-
 lib/eal/freebsd/eal.c   | 2 +-
 lib/eal/freebsd/eal_interrupts.c| 2 +-
 lib/eal/linux/eal.c | 2 +-
 lib/eal/linux/eal_interrupts.c  | 2 +-
 lib/eal/linux/eal_timer.c   | 2 +-
 lib/eal/windows/eal.c   | 2 +-
 lib/eal/windows/eal_interrupts.c| 2 +-
 lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
 lib/telemetry/telemetry.c   | 4 ++--
 lib/vhost/socket.c  | 4 ++--
 lib/vhost/vduse.c   | 2 +-
 30 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/app/test/test_lcores.c b/app/test/test_lcores.c
index 2c945b0136..9522663f1a 100644
--- a/app/test/test_lcores.c
+++ b/app/test/test_lcores.c
@@ -362,7 +362,7 @@ test_ctrl_thread(void)
/* Create one control thread */
t = &ctrl_thread_context;
t->state = Thread_INIT;
-   if (rte_ctrl_thread_create((pthread_t *)&t->id, "test_ctrl_threads",
+   if (rte_ctrl_thread_create((pthread_t *)&t->id, "dpdk-test-ctrlt",
NULL, ctrl_thread_loop, t) != 0)
return -1;
 
diff --git a/app/test/test_threads.c b/app/test/test_threads.c
index a4c4f651a4..4ad5902969 100644
--- a/app/test/test_threads.c
+++ b/app/test/test_threads.c
@@ -239,7 +239,7 @@ test_thread_control_create_join(void)
rte_thread_t thread_main_id;
 
thread_id_ready = 0;
-   RTE_TEST_ASSERT(rte_thread_create_control(&thread_id, 
"test_control_threads",
+   RTE_TEST_ASSERT(rte_thread_create_control(&thread_id, "dpdk-test-thcc",
NULL, thread_main, &thread_main_id) == 0,
"Failed to create thread.");
 
diff --git a/drivers/dma/skeleton/skeleton_dmadev.c 
b/drivers/dma/skeleton/skeleton_dmadev.c
index c2d776dbbd..493224542f 100644
--- a/drivers/dma/skeleton/skeleton_dmadev.c
+++ b/drivers/dma/skeleton/skeleton_dmadev.c
@@ -127,7 +127,7 @@ skeldma_start(struct rte_dma_dev *dev)
 
rte_mb();
 
-   snprintf(name, sizeof(name), "dma_skel_%d", dev->data->dev_id);
+   snprintf(name, sizeof(name), "dpdk-dma-skel%d", dev->data->dev_id);
ret = rte_thread_create_control(&hw->thread, name, NULL,
 cpucopy_thread, dev);
if (ret) {
diff --git a/drivers/event/dlb2/pf/base/dlb2_osdep.h 
b/drivers/event/dlb2/pf/base/dlb2_osdep.h
index cffe22f3c5..75860cca4d 100644
--- a/drivers/event/dlb2/pf/base/dlb2_osdep.h
+++ b/drivers/event/dlb2/pf/base/dlb2_osdep.h
@@ -200,7 +200,7 @@ static inline void os_schedule_work(struct dlb2_hw *hw)
dlb2_dev = container_of(hw, struct dlb2_dev, hw);
 
ret = rte_ctrl_thread_create(&complete_queue_map_unmap_thread,
-"dlb_queue_unmap_waiter",
+"dpdk-dlb-qunmap",
 NULL,
 dlb2_complete_queue_map_unmap,
 dlb2_dev);
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index b2995427c8..30814650bf 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -600,11 +600,11 @@ eth_ark_dev_start(struct rte_eth_dev *dev)
if (!ark->isvf && ark->start_pg && !ark->pg_running) {
pthread_t thread;
 
-   /* Delay packet generatpr start allow the hardware to be ready
+   /* Delay packet generator start allow the hardware to be ready
 * This is only used for sanity checking with internal generator
 

Re: [EXT] Re: [PATCH v3] bitmap: add scan from offset function

[Thomas Monjalon]

03/07/2023 14:02, Volodymyr Fialko:
> 
> > -Original Message-
> > From: Thomas Monjalon 
> > Sent: Monday, July 3, 2023 1:51 PM
> > To: Dumitrescu, Cristian ; Volodymyr Fialko 
> > 
> > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Anoob 
> > Joseph
> > 
> > Subject: [EXT] Re: [PATCH v3] bitmap: add scan from offset function
> > 
> > External Email
> > 
> > --
> > 03/07/2023 12:56, Volodymyr Fialko:
> > > Since it's header-only library, there is issue with using __rte_intenal 
> > > (appeared in v4).
> > 
> > What is the issue?
> 
> From V4 ci build 
> failure(http://mails.dpdk.org/archives/test-report/2023-July/421235.html):
>   In file included from ../examples/ipsec-secgw/event_helper.c:6:
>   ../lib/eal/include/rte_bitmap.h:645:2: error: Symbol is not public ABI
>   __rte_bitmap_scan_init_at(bmp, offset);
>  ^
>   ../lib/eal/include/rte_bitmap.h:150:1: note: from 'diagnose_if' 
> attribute on '__rte_bitmap_scan_init_at':
>   __rte_internal
>   ^~
>   ../lib/eal/include/rte_compat.h:42:16: note: expanded from macro 
> '__rte_internal'   
>   __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
>   ^   ~
>   1 error generated.

OK I see.
So we should give up with __rte_internal for inline functions.
As it is not supposed to be exposed to the applications,
I think we can skip the __rte_experimental flag.

> > > Even if the function itself is not used directly, it get's included to 
> > > the other public files.
> > > It explains why other functions in this library does not have the 
> > > rte_internal prefix, but the double
> > underscores.
> > > So, should I simply remove __rte_internal from v4, or there's another 
> > > approach to resolve this
> > issue(beside creating .c file)?
> > >
> > > /Volodymyr
> > >
> > > > -Original Message-
> > > > From: Dumitrescu, Cristian 
> > > > Sent: Friday, June 23, 2023 2:41 PM
> > > > To: Thomas Monjalon ; Volodymyr Fialko
> > > > 
> > > > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> > > > Anoob Joseph 
> > > > Subject: [EXT] RE: [PATCH v3] bitmap: add scan from offset function
> > > >
> > > > External Email
> > > >
> > > > 
> > > > --
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Thomas Monjalon 
> > > > > Sent: Thursday, June 22, 2023 6:45 PM
> > > > > To: Volodymyr Fialko 
> > > > > Cc: dev@dpdk.org; Dumitrescu, Cristian
> > > > > ; jer...@marvell.com;
> > > > > ano...@marvell.com
> > > > > Subject: Re: [PATCH v3] bitmap: add scan from offset function
> > > > >
> > > > > 21/06/2023 12:01, Volodymyr Fialko:
> > > > > > Currently, in the case when we search for a bit set after a
> > > > > > particular value, the bitmap has to be scanned from the
> > > > > > beginning and
> > > > > > rte_bitmap_scan() has to be called multiple times until we hit the 
> > > > > > value.
> > > > > >
> > > > > > Add a new rte_bitmap_scan_from_offset() function to initialize
> > > > > > scan state at the given offset and perform scan, this will allow
> > > > > > getting the next set bit after certain offset within one scan call.
> > > > > >
> > > > > > Signed-off-by: Volodymyr Fialko 
> > > > > > ---
> > > > > > v2:
> > > > > >  - added rte_bitmap_scan_from_offset
> > > > > > v3
> > > > > >  - added note for internal use only for init_at function
> > > > > [...]
> > > > > > +/**
> > > > > > + * @warning
> > > > > > + * @b EXPERIMENTAL: this API may change without prior notice.
> > > > > > + *
> > > > > > + * Bitmap initialize internal scan pointers at the given
> > > > > > +position for the scan
> > > > > function.
> > > > > > + *
> > > > > > + * Note: for private/internal use, for public:
> > > > > > + * @see rte_bitmap_scan_from_offset()
> > > > > > + *
> > > > > > + * @param bmp
> > > > > > + *   Handle to bitmap instance
> > > > > > + * @param pos
> > > > > > + *   Bit position to start scan
> > > > > > + */
> > > > > > +__rte_experimental
> > > > > > +static inline void
> > > > > > +__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
> > > > >
> > > > > I think it should marked with __rte_internal instead of experimental.
> > > > >
> > > > >
> > > >
> > > >
> > > > +1
> > >
> > 
> > 
> > 
> > 
> 
> 

RE: [PATCH] app/testpmd: fix invalid queue ID when start port

[Ali Alnubani]

> -Original Message-
> From: Jie Hai 
> Sent: Monday, July 3, 2023 2:03 PM
> To: Aman Singh ; Yuying Zhang
> ; Ferruh Yigit ; Shiyang He
> 
> Cc: dev@dpdk.org; liudongdo...@huawei.com; Ali Alnubani
> 
> Subject: [PATCH] app/testpmd: fix invalid queue ID when start port
> 
> Function update_queue_state updates queue state of all queues
> of all ports, using the queue num nb_rxq|nb_txq stored locally
> by testpmd. Error on invalid queue ID occurs if we start testpmd
> with two ports and detach-attach one of them and start the other
> port first. That's because the attached port has zero queues and
> that differs from the nb_rxq|nb_txq. The similar error happens
> in multi-process senoris if secondary process attaches a port

Do you mean scenarios?

> and starts it.
> 
> This patch updates queue state according to the num of queues
> reported by driver instead of testpmd.
> 
> Fixes: 141a520b35f7 ("app/testpmd: fix primary process not polling all
> queues")
> Fixes: 5028f207a4fa ("app/testpmd: fix secondary process packet
> forwarding")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Jie Hai 
> ---

Thanks Jie.

Tested-by: Ali Alnubani 

[PATCH v5] bitmap: add scan from offset function

[Volodymyr Fialko]

Currently, in the case when we search for a bit set after a particular
value, the bitmap has to be scanned from the beginning and
rte_bitmap_scan() has to be called multiple times until we hit the value.

Add a new rte_bitmap_scan_from_offset() function to initialize scan
state at the given offset and perform scan, this will allow getting
the next set bit after certain offset within one scan call.

Signed-off-by: Volodymyr Fialko 
---
v2:
 - added rte_bitmap_scan_from_offset
v3:
 - added note for internal use only for init_at function
v4:
 - marked init_at function as __rte_internal
v5:
 - removed __rte_internal due to build errors

 app/test/test_bitmap.c   | 33 +-
 lib/eal/include/rte_bitmap.h | 55 
 2 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/app/test/test_bitmap.c b/app/test/test_bitmap.c
index e9c61590ae..9e38087408 100644
--- a/app/test/test_bitmap.c
+++ b/app/test/test_bitmap.c
@@ -18,8 +18,8 @@ test_bitmap_scan_operations(struct rte_bitmap *bmp)
 {
uint64_t slab1_magic = 0xBADC0FFEEBADF00D;
uint64_t slab2_magic = 0xFEEDDEADDEADF00D;
+   int i, nb_clear, nb_set, next_cl;
uint32_t pos = 0, start_pos;
-   int i, nb_clear, nb_set;
uint64_t out_slab = 0;
 
rte_bitmap_reset(bmp);
@@ -71,6 +71,37 @@ test_bitmap_scan_operations(struct rte_bitmap *bmp)
return TEST_FAILED;
}
 
+   /* Scan with offset check. */
+   if (!rte_bitmap_scan_from_offset(bmp, RTE_BITMAP_SLAB_BIT_SIZE, &pos, 
&out_slab)) {
+   printf("Failed to get slab from bitmap with scan from 
offset.\n");
+   return TEST_FAILED;
+   }
+
+   if (slab2_magic != out_slab) {
+   printf("Scan from offset operation failed.\n");
+   return TEST_FAILED;
+   }
+
+   /* Scan with offset wrap around check. */
+   if (!rte_bitmap_scan_from_offset(bmp, 2 * RTE_BITMAP_SLAB_BIT_SIZE, 
&pos, &out_slab)) {
+   printf("Failed to get slab from bitmap with scan from 
offset.\n");
+   return TEST_FAILED;
+   }
+
+   if (slab1_magic != out_slab) {
+   printf("Scan from offset with wrap around operation failed.\n");
+   return TEST_FAILED;
+   }
+
+   /* Test scan when the bit set is on a next cline */
+   rte_bitmap_reset(bmp);
+   next_cl = RTE_MIN(RTE_BITMAP_CL_BIT_SIZE, MAX_BITS);
+   rte_bitmap_set(bmp, next_cl);
+   if (!rte_bitmap_scan_from_offset(bmp, 0, &pos, &out_slab)) {
+   printf("Failed to get slab from next cache line from 
bitmap.\n");
+   return TEST_FAILED;
+   }
+
/* Test scan when a cline is half full */
rte_bitmap_reset(bmp);
for (i = 0; i < MAX_BITS; i++)
diff --git a/lib/eal/include/rte_bitmap.h b/lib/eal/include/rte_bitmap.h
index 27ee3d18a4..cc14b1ed2e 100644
--- a/lib/eal/include/rte_bitmap.h
+++ b/lib/eal/include/rte_bitmap.h
@@ -137,6 +137,29 @@ __rte_bitmap_scan_init(struct rte_bitmap *bmp)
bmp->go2 = 0;
 }
 
+/**
+ * Bitmap initialize internal scan pointers at the given position for the scan 
function.
+ *
+ * Note: for private/internal use, for public:
+ * @see rte_bitmap_scan_from_offset()
+ *
+ * @param bmp
+ *   Handle to bitmap instance
+ * @param pos
+ *   Bit position to start scan
+ */
+static inline void
+__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
+{
+   uint64_t *slab1;
+
+   bmp->index1 = pos >> (RTE_BITMAP_SLAB_BIT_SIZE_LOG2 + 
RTE_BITMAP_CL_BIT_SIZE_LOG2);
+   bmp->offset1 = (pos >> RTE_BITMAP_CL_BIT_SIZE_LOG2) & 
RTE_BITMAP_SLAB_BIT_MASK;
+   bmp->index2 = pos >> RTE_BITMAP_SLAB_BIT_SIZE_LOG2;
+   slab1 = bmp->array1 + bmp->index1;
+   bmp->go2 = *slab1 & (1llu << bmp->offset1);
+}
+
 /**
  * Bitmap memory footprint calculation
  *
@@ -591,6 +614,38 @@ rte_bitmap_scan(struct rte_bitmap *bmp, uint32_t *pos, 
uint64_t *slab)
return 0;
 }
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Bitmap scan from the given offset.
+ * Function will reset internal scan state to start scanning from the offset
+ * position.
+ * @see rte_bitmap_scan()
+ *
+ * @param bmp
+ *   Handle to bitmap instance
+ * @param offset
+ *   Bit offset to start scan
+ * @param pos
+ *   When function call returns 1, pos contains the position of the next set
+ *   bit, otherwise not modified
+ * @param slab
+ *   When function call returns 1, slab contains the value of the entire 64-bit
+ *   slab where the bit indicated by pos is located.
+ *   When function call returns 0, slab is not modified.
+ * @return
+ *   0 if there is no bit set in the bitmap, 1 otherwise
+ */
+__rte_experimental
+static inline int
+rte_bitmap_scan_from_offset(struct rte_bitmap *bmp, uint32_t offset,
+   uint32_t *pos, uint64_t *slab)
+{
+   __rte_bitmap_scan_init_at(bmp, offset);
+   return rte_bi

RE: [PATCH v5] bitmap: add scan from offset function

[Dumitrescu, Cristian]

> -Original Message-
> From: Volodymyr Fialko 
> Sent: Monday, July 3, 2023 1:39 PM
> To: dev@dpdk.org; Dumitrescu, Cristian 
> Cc: jer...@marvell.com; ano...@marvell.com; tho...@monjalon.net;
> Volodymyr Fialko 
> Subject: [PATCH v5] bitmap: add scan from offset function
> 
> Currently, in the case when we search for a bit set after a particular
> value, the bitmap has to be scanned from the beginning and
> rte_bitmap_scan() has to be called multiple times until we hit the value.
> 
> Add a new rte_bitmap_scan_from_offset() function to initialize scan
> state at the given offset and perform scan, this will allow getting
> the next set bit after certain offset within one scan call.
> 
> Signed-off-by: Volodymyr Fialko 
> ---

Acked-by: Cristian Dumitrescu 

RE: [PATCH 1/7] net/mlx5: fix the modify field check of tag

[Bing Zhao]

Hi Stephen,
If I understand correctly, do you mean that the internal value and rte_flow API 
value may have some conflict?
All the MLX5 internal enum values start from INT_MIN. When treating it as a int 
value, it would not have the same value with rte_flow enums, unless all the 
2^^32 are defined.
But yes, this has some risk since there is no limitation of the values in the 
rte_flow API.

BR. Bing

> -Original Message-
> From: Stephen Hemminger 
> Sent: Friday, June 30, 2023 2:09 PM
> To: Bing Zhao 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh ;
> dev@dpdk.org; Michael Baum 
> Subject: Re: [PATCH 1/7] net/mlx5: fix the modify field check of tag
> 
> External email: Use caution opening links or attachments
> 
> 
> On Fri, 30 Jun 2023 08:43:03 +0300
> Bing Zhao  wrote:
> 
> > @@ -1117,9 +1117,10 @@ flow_dv_fetch_field(const uint8_t *data,
> > uint32_t size)  static inline bool
> > flow_modify_field_support_tag_array(enum rte_flow_field_id field)  {
> > - switch (field) {
> > + switch ((int)field) {
> >   case RTE_FLOW_FIELD_TAG:
> >   case RTE_FLOW_FIELD_MPLS:
> > + case MLX5_RTE_FLOW_FIELD_META_REG:
> 
> Mixing internal and API fields seems like something that could get easily
> broken by changes to rte_flow.

RE: [PATCH v4] app/testpmd: fix primary process not polling all queues

[Ali Alnubani]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, June 27, 2023 2:05 PM
> To: Jie Hai ; Ali Alnubani ; Aman
> Singh ; Yuying Zhang
> ; Anatoly Burakov ;
> Matan Azrad ; Dmitry Kozlyuk
> 
> Cc: dev@dpdk.org; liudongdo...@huawei.com; shiyangx...@intel.com;
> Raslan Darawsheh ; NBU-Contact-Thomas Monjalon
> (EXTERNAL) 
> Subject: Re: [PATCH v4] app/testpmd: fix primary process not polling all
> queues
> 
> On 6/26/2023 10:30 AM, Jie Hai wrote:
> > On 2023/6/23 0:40, Ali Alnubani wrote:
> >>> -Original Message-
> >>> From: Jie Hai 
> >>> Sent: Friday, June 9, 2023 12:04 PM
> >>> To: Aman Singh ; Yuying Zhang
> >>> ; Anatoly Burakov
> ;
> >>> Matan Azrad ; Dmitry Kozlyuk
> >>> 
> >>> Cc: dev@dpdk.org; liudongdo...@huawei.com; shiyangx...@intel.com;
> >>> ferruh.yi...@amd.com
> >>> Subject: [PATCH v4] app/testpmd: fix primary process not polling all
> >>> queues
> >>>
> >>> Here's how the problem arises.
> >>> step1: Start the app.
> >>>  dpdk-testpmd -a :35:00.0 -l 0-3 -- -i --rxq=10 --txq=10
> >>>
> >>> step2: Perform the following steps and send traffic. As expected,
> >>> queue 7 does not send or receive packets, and other queues do.
> >>>  port 0 rxq 7 stop
> >>>  port 0 txq 7 stop
> >>>  set fwd mac
> >>>  start
> >>>
> >>> step3: Perform the following steps and send traffic. All queues
> >>> are expected to send and receive packets normally, but that's not
> >>> the case for queue 7.
> >>>  stop
> >>>  port stop all
> >>>  port start all
> >>>  start
> >>>  show port xstats all
> >>>
> >>> In fact, only the value of rx_q7_packets for queue 7 is not zero,
> >>> which means queue 7 is enabled for the driver but is not involved
> >>> in packet receiving and forwarding by software. If we check queue
> >>> state by command 'show rxq info 0 7' and 'show txq info 0 7',
> >>> we see queue 7 is started as other queues are.
> >>>  Rx queue state: started
> >>>  Tx queue state: started
> >>> The queue 7 is started but cannot forward. That's the problem.
> >>>
> >>> We know that each stream has a read-only "disabled" field that
> >>> control if this stream should be used to forward. This field
> >>> depends on testpmd local queue state, please see
> >>> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
> >>> DPDK framework maintains ethdev queue state that drivers reported,
> >>> which indicates the real state of queues.
> >>>
> >>> There are commands that update these two kind queue state such as
> >>> 'port X rxq|txq start|stop'. But these operations take effect only
> >>> in one stop-start round. In the following stop-start round, the
> >>> preceding operations do not take effect anymore. However, only
> >>> the ethdev queue state is updated, causing the testpmd and ethdev
> >>> state information to diverge and causing unexpected side effects
> >>> as above problem.
> >>>
> >>> There was a similar problem for the secondary process, please see
> >>> commit 5028f207a4fa ("app/testpmd: fix secondary process packet
> >>> forwarding").
> >>>
> >>> This patch applies its workaround with some difference to the
> >>> primary process. Not all PMDs implement rte_eth_rx_queue_info_get and
> >>> rte_eth_tx_queue_info_get, however they may support deferred_start
> >>> with primary process. To not break their behavior, retain the original
> >>> testpmd local queue state for those PMDs.
> >>>
> >>> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
> >>> Cc: sta...@dpdk.org
> >>>
> >>> Signed-off-by: Jie Hai 
> >>> ---
> >>
> >> Hi Jie,
> >>
> >> I see the error below when starting a representor port after
> >> reattaching it with this patch, is it expected?
> >>
> >> $ sudo ./build /app/dpdk-testpmd -n 4  -a
> >> :08:00.0,dv_esw_en=1,representor=vf0-1  -a auxiliary: -a 00:00.0
> >> --iova-mode="va" -- -i
> >> [..]
> >> testpmd> port stop all
> >> testpmd> port close 0
> >> testpmd> device detach :08:00.0
> >> testpmd> port attach :08:00.0,dv_esw_en=1,representor=0-1
> >> testpmd> port start 1
> >> Configuring Port 1 (socket 0)
> >> Port 1: FA:9E:D8:5F:D7:D8
> >> Invalid Rx queue_id=0
> >> testpmd: Failed to get rx queue info
> >> Invalid Tx queue_id=0
> >> testpmd: Failed to get tx queue info
> >>
> >> Regards,
> >> Ali
> > Hi Ali,
> > Thanks for your feedback.
> >
> > When update_queue_state is called, the status of all queues on all ports
> > are updated.
> > The number of queues is nb_rxq|nb_txq which is stored locally by testpmd
> > process.
> > All ports on the same process shares the same nb_rxq|nb_txq.
> >
> > After detached and attached, the number of queues of port 0 is 0.
> > And it changes only when the port is reconfigured by testpmd,
> > which is when port 0 is started.
> >
> > If we start port 1 first, update_queue_state will update nb_rxq|nb_txq
> > queues state of port 0, and that's invalid because there's zero queues.
> >
> > If this patch is not applied, the same problem occurs when the seconda

RE: [PATCH v5 2/2] ethdev: support xstats reset telemetry command

[Morten Brørup]

> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, 3 July 2023 09.20
> 
> 03/07/2023 05:58, fengchengwen:
> >
> > On 2023/2/20 21:05, Thomas Monjalon wrote:
> > > 17/02/2023 10:44, fengchengwen:
> > >> On 2023/2/16 20:54, Bruce Richardson wrote:
> > >>> On Thu, Feb 16, 2023 at 08:42:34PM +0800, fengchengwen wrote:
> >  On 2023/2/16 20:06, Ferruh Yigit wrote:
> > > On 2/16/2023 11:53 AM, fengchengwen wrote:
> > >> On 2023/2/15 11:19, Dongdong Liu wrote:
> > >>> Hi Chengwen
> > >>>
> > >>> On 2023/2/9 10:32, Chengwen Feng wrote:
> >  The xstats reset is useful for debugging, so add it to the
> ethdev
> >  telemetry command lists.
> > 
> >  Signed-off-by: Chengwen Feng 
> > >>> This patch looks good, so
> > >>> Reviewed-by: Dongdong Liu 
> > >>>
> > >>> A minior question
> > >>> Do we need to support stats reset ?
> > >>
> > >> Stats is contained by xstats, and future direction I think is
> xstats.
> > >> So I think we don't need support stats reset.
> > >>
> > >
> > > I have similar question with Dongdong, readonly values are safe
> for
> > > telemetry, but modifying data can be more tricky since we don't
> have
> > > locking in ethdev APIs, this can cause concurrency issues.
> > 
> >  Yes, it indeed has concurrency issues.
> > 
> > >
> > > Overall do we want telemetry go that way and become something
> that
> > > alters ethdev data/config?
> > 
> >  There are at least two part of data: config and status.
> >  For stats (which belong status data) could help for debugging, I
> think it's acceptable.
> > 
> >  As for concurrency issues. People should know what to do and when
> to do, just like
> >  the don't invoke config API (e.g. dev_configure/dev_start/...)
> concurrency.
> > 
> > >>> While this is probably ok for now, I think in next release we
> should look
> > >>> to add some sort of support for locking for destructive ops in a
> future
> > >>> release. For example, we could:
> > >>>
> > >>> 1. Add support for marking a callback as "destructive" and only
> allow it to
> > >>> be called if only one connection is present or
> > >>>
> > >>> 2. Make it possible for callbacks to query the number of
> connections so
> > >>> that the callback itself is non-destructive in more than one
> connection is
> > >>> open.
> > >>>
> > >>> [Both of these will require locking support so that new
> connections aren't
> > >>> openned when the callback is in-flight!]
> > >>
> > >> Except telemetry, the application may have other console could
> execute DPDK API.
> > >> So I think trying to keep it simple, it's up to the user to invoke.
> > >
> > > No, the user should not be responsible for concurrency issues.
> > > We can ask the app developper to take care,
> > > but not to the user who has no control on what happens in the app.
> > >
> > > On a more general note, I feel the expansion of telemetry is not
> controlled enough.
> > > I would like to stop on adding more telemetry until we have a clear
> guideline
> > > about what is telemetry for and how to use it.
> >
> > Hi Thomas,
> >
> > Should this be discussed on TB?
> 
> What would be your question exactly?

A general comment about telemetry:

If an application exposes telemetry through an end user facing API, e.g. 
http(s) REST, it would be nice if non-read-only telemetry paths are easy to 
identify by following some DPDK standard convention, so the application does 
not need to manually maintain an allow-list of read-only paths.

Bruce's documentation about trace/log/telemetry/dump might also need to be 
updated regarding non-read-only telemetry actions.

RE: [PATCH v2] net/mlx5: fix the error set for age pool initialization

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 1:27 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Michael Baum ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix the error set for age pool initialization
> 
> The rte_flow_error needs to be set when the age pool initialization has a
> failure. Or else the application will crash due to the access of the invalid
> "message" field.
> 
> Fixes: 04a4de756e14 ("net/mlx5: support flow age action with HWS")
> Cc: michae...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Ori Kam 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH v3] net/mlx5: fix the error in VLAN actions creation

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 2:02 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Gregory Etelson ;
> sta...@dpdk.org
> Subject: [PATCH v3] net/mlx5: fix the error in VLAN actions creation
> 
> When a failure occurs during the VLAN actions creating, the value of
> "rte_errno" is already set by the mlx5dr_action_create*. The value can be
> returned directly to reflect the actual reason.
> 
> In the meanwhile, the "rte_flow_error" structure should also be set with clear
> message explicitly.
> 
> Fixes: 773ca0e91ba1 ("net/mlx5: support VLAN push/pop/modify with
> HWS")
> Cc: getel...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Ori Kam 
> ---
> v2: add CC stable
> v3: fix typo

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH] common/mlx5: fix obtaining IB device in LAG mode

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 3:42 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Rongwei Liu ; sta...@dpdk.org
> Subject: [PATCH] common/mlx5: fix obtaining IB device in LAG mode
> 
> In hardware LAG mode, both PFs are in the same E-Switch domain but the VFs
> are in the other domains. Moreover, VF has its own dedicated IB device.
> 
> When probing a VF created on the 1st PF, usually its PCIe address is the same
> as the PF's except the function part. Then there would be some wrong VF BDF
> match on the IB "bond" device due to incomplete comparison (we do not
> compare the function part of BDF for bonding devices to match all bonded
> PFs).
> 
> Adding one extra condition to check whether the current PCIe address device
> is a VF will solve the incorrect IB device recognition. Thus the full address
> comparison will be done.
> 
> Fixes: f956d3d4c33c ("net/mlx5: fix probing with secondary bonding
> member")
> Cc: rongw...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Viacheslav Ovsiienko 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH] net/mlx5: fix the profile check of meter mark

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 3:45 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Alexander Kozyrev ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix the profile check of meter mark
> 
> When creating a meter_mark action, the profile should be specified.
> Or else there would be a crash if the pointer to the profile was not set
> properly:
>   1. creating an action template with only action mask set and using
>  this template to create a table
>   2. creating a flow rule without setting the profile if the action
>  of meter_mark is not fixed
> 
> The check should be done inside the action allocation and an error needs to be
> returned immediately.
> 
> Fixes: 48fbb0e93d06 ("net/mlx5: support flow meter mark indirect action
> with HWS")
> Cc: akozy...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Viacheslav Ovsiienko 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH] net/mlx5: reduce the counter pool name length

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Friday, June 30, 2023 3:58 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Jack Min ; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: reduce the counter pool name length
> 
> The name size of a rte_ring is RTE_MEMZONE_NAMESIZE with the value 32
> by default. When creating a HWS counter pool cache, the final string
> format was "RG_MLX5_HWS_CNT_POOL_%u_cache/%u" and it could support
> less than 1000 variants. For example, if the first %u representing
> port id is 100 and it will take all the available characters then the
> second %u for queues will be discarded. If there was more than one
> rule creation queue, the rte_ring could not be created.
> 
> By reducing the fixed character number and using hexadecimal format,
> the issue can be overcome with an assumption that not all the integer
> fields for queue index is used.
> 
> Fixes: 13ea6bdcc7ee ("net/mlx5: support counters in cross port shared
> mode")
> Fixes: 4d368e1da3a4 ("net/mlx5: support flow counter action for HWS")
> Cc: jack...@nvidia.com
> Cc: sta...@dpdk.org

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH v3] net/mlx5: fix flow workspace destruction

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Bing Zhao 
> Sent: Monday, July 3, 2023 12:51 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Raslan Darawsheh 
> Cc: dev@dpdk.org; Gregory Etelson ;
> sta...@dpdk.org; David Marchand 
> Subject: [PATCH v3] net/mlx5: fix flow workspace destruction
> 
> From: Gregory Etelson 
> 
> PMD uses pthread key to allocate and access per thread flow workspace
> memory buffers.
> 
> PMD registered a key destructor function to clean up flow workspace buffers.
> However, the key destructor was not called by the pthread library.
> 
> The patch keeps track of per-thread flow workspaces in PMD.
> Flow workspaces memory release is activated from PMD destructor.
> 
> In the meanwhile, workspace buffer and RSS queues array are allocated in a
> single memory chunk with this patch. The maximal number of queues
> RTE_ETH_RSS_RETA_SIZE_512 is chosen. Then the workspace adjustment can
> be removed to reduce the software hiccup:
>   1. realloc and content copy
>   2. spinlock acquire and release
> 
> Bugzilla ID: 1255
> 
> Fixes: 5d55a494f4e6 ("net/mlx5: split multi-thread flow handling per OS")
> Cc: sta...@dpdk.org
> 
> Reported-by: David Marchand 
> Signed-off-by: Gregory Etelson 
> Signed-off-by: Bing Zhao 
> Acked-by: Matan Azrad 
> ---
> v2: fix typo and code style
> v3: add bugzilla information

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [PATCH] doc: update mlxreg command arguments for recent versions

[Raslan Darawsheh]

Hi,
> -Original Message-
> From: Ali Alnubani 
> Sent: Monday, July 3, 2023 10:48 AM
> To: dev@dpdk.org
> Subject: [PATCH] doc: update mlxreg command arguments for recent versions
> 
> Recent versions of the command require vhca_id and all_vhca to be set with
> the --indexes arg.
> 
> Signed-off-by: Ali Alnubani 
Acked-by: Raslan Darawsheh 

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

RE: [EXT] [PATCH v4 0/3] Replace obsolote test cases.

[Akhil Goyal]

> Subject: RE: [EXT] [PATCH v4 0/3] Replace obsolote test cases.
> 
> Series verified with openssl pmd.
> 
> Acked-by: Gowrishankar Muthukrishnan 
> 
Series applied to dpdk-next-crypto

There seems to be a false error reported by CI. Hence ignoring it.

Thanks.

RE: [PATCH v1] crypto/qat: fix struct alignment

[Akhil Goyal]

> > Subject: [PATCH v1] crypto/qat: fix struct alignment
> >
> > The qat_sym_session struct variable alignment was causing a segfault.
> > AES expansion keys require 16-byte alignment. Added __rte_aligned to the
> > expansion keys.
> >
> > Fixes: ca0ba0e48129 ("crypto/qat: default to IPsec MB for computations")
> >
> > Signed-off-by: Brian Dooley 
> > ---
> 
> Acked-by: Ciara Power 
Applied to dpdk-next-crypto
Thanks.

RE: [PATCH v2] crypto/qat: fix NULL algorithm digest placement

[Akhil Goyal]

> -Original Message-
> From: Kusztal, ArkadiuszX 
> Sent: Monday, June 26, 2023 11:51 PM
> To: Power, Ciara ; dev@dpdk.org
> Cc: Power, Ciara ; Ji, Kai 
> Subject: [EXT] RE: [PATCH v2] crypto/qat: fix NULL algorithm digest placement
> 
> External Email
> 
> --
> 
> 
> > -Original Message-
> > From: Ciara Power 
> > Sent: Friday, June 23, 2023 3:51 PM
> > To: dev@dpdk.org
> > Cc: Power, Ciara ; Ji, Kai 
> > Subject: [PATCH v2] crypto/qat: fix NULL algorithm digest placement
> >
> > QAT HW generates bytes of 0x00 digest, even when a digest of len 0 is
> > requested for NULL. This caused test failures when the test vector had 
> > digest
> len
> > 0, as the buffer has unexpected changed bytes.
> >
> > By placing the digest into the cookie for NULL authentication, the buffer
> > remains unchanged as expected, and the digest is placed to the side, as it
> won't
> > be used anyway.
> >
> > Fixes: db0e952a5c01 ("crypto/qat: add NULL capability")
> >
> > Signed-off-by: Ciara Power 
> > ---
> > v2: added fixes line as this was a bug
> > ---
> > --
> > 2.25.1
> 
> Acked-by: Arek Kusztal 
Arek,
Please be consistent with your sign-off/acks naming.
It should align with .mailmap file.
Arek -> Arkadiusz

Applied to dpdk-next-crypto

RE: [PATCH v3] common/qat: fix detach QAT crypto compress build

[Akhil Goyal]

> > Subject: [PATCH v3] common/qat: fix detach QAT crypto compress build
> >
> > qat_qp.c is a common file for QAT crypto and compress. Moved compress
> > function from common file to compress QAT file qat_comp.c
> >
> > Bugzilla ID: 1237
> > Fixes: 2ca75c65af4c ("common/qat: build drivers from common folder")
> > Cc: bruce.richard...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Vikash Poddar 
> > ---
> > v3:
> > Fixed commit message
> > v2:
> > Fixed coding style issue
> 
> Acked-by: Ciara Power 
Applied to dpdk-next-crypto
Thanks.

RE: [PATCH] test/crypto: fix PDCP-SDAP test vectors

[Akhil Goyal]

> Subject: [PATCH] test/crypto: fix PDCP-SDAP test vectors
> 
> Fix incorrect fields in PDCP Header.
> 1. Only Data PDUs should be ciphered and authenticated.
>Here the vectors are control PDUs which should not be crypto
>processed. Change the D/C bit to make the vector as Data PDU
> 2. Reserved fields must be set to 0.
> 
> Updated the vectors and MAC-I values to handle above cases.
> 
> Fixes: 003afde411e7 ("test/crypto: add test vectors for PDCP-SDAP")
> Cc: franck.lenorm...@nxp.com
> 
> Signed-off-by: Aakash Sasidharan 

Acked-by: Akhil Goyal 
Applied to dpdk-next-crypto
Thanks.

RE: [PATCH] doc: announce addition of new security IPsec SA option

[Akhil Goyal]

> Subject: [PATCH] doc: announce addition of new security IPsec SA option
> 
> Announce addition of new security IPsec SA option to enable
> out of place processing in Ingress Inline inbound SA's.
> 
> Signed-off-by: Nithin Dabilpuram 
> ---
>  doc/guides/rel_notes/deprecation.rst | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 8e1cdd677a..20ce0a51af 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -156,3 +156,8 @@ Deprecation Notices
>The new port library API (functions rte_swx_port_*)
>will gradually transition from experimental to stable status
>starting with DPDK 23.07 release.
> +
> +* security: New sa option ``ingress_oop`` would be added in structure
> +  ``rte_security_ipsec_sa_options`` to support out of place processing
> +  for inline inbound SA's. ``reserved_opts`` size would be reduced by
> +  1 bit from DPDK 23.11.

As discussed in techboard meetings, reserved fields should not be added.
Hence we can update the above note to remove reserved_opts as well.

With that fixed.
Acked-by: Akhil Goyal 

++ more people for acks.

Re: [PATCH] regex/cn9k: remove rule compiler

[Thomas Monjalon]

21/06/2023 17:33, Jerin Jacob:
> On Wed, Jun 21, 2023 at 7:36 PM Thomas Monjalon  wrote:
> >
> > Nobody knows how to build the feature.
> > When the dependency "rxp_compiler" is found,
> > the header file is not available:
> >
> > drivers/regex/cn9k/cn9k_regexdev_compiler.c:12:10: fatal error:
> > rxp-compiler.h: No such file or directory
> >
> > It seems that it depends on a proprietay library.
> 
> Yes. it depended on proprietary library owned by NVIDIA now. Not sure
> Marvell has rights to publish it "freely available".
> In order to avoid forking this library, better option to make this
> library as public. Also, it looks like the library itself won't have
> proper installation procedures that is the
> reason for conflict as documented here in
> https://bugs.dpdk.org/show_bug.cgi?id=1232.
> 
> If that is not an option for other original owner, I think, it should
> be removed and accept this patch in the true sprint of open source.
> 
> Acked-by: Jerin Jacob 

Applied

Re: [PATCH] member: fix PRNG seed reset in NitroSketch mode

[Thomas Monjalon]

Any comment?

20/06/2023 23:17, Dmitry Kozlyuk:
> Sketch creation seeded the global PRNG
> using the supplied seed for hashing.
> The use of this seed by SKETCH set summary was not documented.
> SKETCH set summary does not require two independent hash seeds,
> unlike other set summary types.
> Seeding the global PRNG at sketch creation
> does not make the sketch operation deterministic:
> it uses rte_rand() later, the PRNG may be seeded again by that point.
> On the other hand, seeding the global PRNG with a hash seed,
> is likely undesired, because it may be low-entropy or even constant.
> Deterministic operation can be achieved by seeding the PRNG externally.
> 
> Remove the call to rte_srand() at sketch creation.
> Document that hash seeds are not used by SKETCH set summary type.
> 
> Fixes: db354bd2e1f8 ("member: add NitroSketch mode")
> Cc: leyi.r...@intel.com
> 
> Signed-off-by: Dmitry Kozlyuk 
> ---
>  lib/member/rte_member.h| 1 +
>  lib/member/rte_member_sketch.c | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/member/rte_member.h b/lib/member/rte_member.h
> index 072a253c89..d08b143e51 100644
> --- a/lib/member/rte_member.h
> +++ b/lib/member/rte_member.h
> @@ -314,6 +314,7 @@ struct rte_member_parameters {
>* for bucket location.
>* For vBF type, these two hashes and their combinations are used as
>* hash locations to index the bit array.
> +  * For Sketch type, these seeds are not used.
>*/
>   uint32_t prim_hash_seed;
>  
> diff --git a/lib/member/rte_member_sketch.c b/lib/member/rte_member_sketch.c
> index 524ba77620..d5f35aabe9 100644
> --- a/lib/member/rte_member_sketch.c
> +++ b/lib/member/rte_member_sketch.c
> @@ -227,7 +227,6 @@ rte_member_create_sketch(struct rte_member_setsum *ss,
>   goto error_runtime;
>   }
>  
> - rte_srand(ss->prim_hash_seed);
>   for (i = 0; i < ss->num_row; i++)
>   ss->hash_seeds[i] = rte_rand();
>  
> 

Re: [EXT] Re: [PATCH v3] net/bnx2x: offer maintainership for bnx2x

[Thomas Monjalon]

30/06/2023 04:27, Alok Prasad:
> > 02/06/2023 09:52, Julien Aube:
> > > This is an offer to maintain the code for bnx2x-based
> > > cards. It may not be possible on the long run due to
> > > the old design of this chipset.
> > >
> > > Note that I'm not affiliated with LSI nor Broadcom and
> > > do not have access to documentation or other NDA-based
> > > code.
[...]
> > >  Marvell QLogic bnx2x
> > > -M: Rasesh Mody 
> > > -M: Shahed Shaikh 
> > > +M: Julien Aube 
> 
> Acked-by: Alok Prasad 

Applied, thanks.

Re: [PATCH v5] build: prevent accidentally building without NUMA support

[Thomas Monjalon]

28/06/2023 05:03, Tu, Lijuan:
> From: Thomas Monjalon 
> > 15/06/2023 16:38, Bruce Richardson:
> > Is the test ci/Intel-compilation fixed?
> > Could you send a new version for testing the CI?
> > 
> 
> Sorry, this is caused by intel testbeds lack of dep libnuma, Installed it and 
> re-run the CI, result is PASSED.

Applied, thanks.

Re: [PATCH v2] docs: freebsd: Update to 20.11

[Thomas Monjalon]

30/06/2023 18:41, David Young:
> This patch updates the installation instructions for DPDK on FreeBSD.
> It specifies the explicit version of DPDK (20.11) to be installed.
> This change is important as the 'dpdk' package is an alias and doesn't
> always point to the latest version. By specifying the explicit version,
> we make it clear which version is to be installed. The page previously
> showed 'pkg install dpdk' without specifying the version.

I understand it can be helpful to choose a specific version.
But dpdk20.11 is not necessarily the latest one,
and it could be useful to show both approaches in the doc.

> @@ -123,3 +123,4 @@ via the contigmem module, and 4 NIC ports bound to the 
> nic_uio module::
>  
> For an explanation of the command-line parameters that can be passed to an
> DPDK application, see section :ref:`running_sample_app`.
> +

This last line looks like an extra unnneeded blank line.

Re: [PATCH] doc: ensure sphinx output is reproducible

[Thomas Monjalon]

29/06/2023 14:58, christian.ehrha...@canonical.com:
> From: Christian Ehrhardt 
> 
> By adding -j we build in parallel, to make building on multiprocessor
> machines more effective. While that works it does also break
> reproducible builds as the order of the sphinx generated searchindex.js
> is depending on execution speed of the individual processes.
[...]
> -if Version(ver) >= Version('1.7'):
> -sphinx_cmd += ['-j', 'auto']

What is the impact on build speed on an average machine?

Re: [PATCH] eal/interrupts: Allow UIO interrupts when using igb_uio

[Thomas Monjalon]

14/06/2023 18:46, Stephen Hemminger:
> On Wed, 14 Jun 2023 13:40:18 +
> Vladimir Ratnikov  wrote:
> 
> >  Some drivers and devices(ex: igc + i225/i226) use
> > RTE_INTR_HANDLE_UIO handler when captured under igb_uio
> > so just let them use it.
> > 
> > Signed-off-by: Vladimir Ratnikov 
> 
> This doesn't look right.
> 
> With UIO only a single interrupt is possible, there is no MSI-X support.

Please Vladimir, could you reply to Stephen?
I think he is suggesting a better fix in the igc driver.

[PATCH] fib: fix adding a default route

[Vladimir Medvedkin]

Fixed an issue that occurs when
adding a default route as the first route.

Bugzilla ID: 1160
Fixes: 7dc7868b200d ("fib: add DIR24-8 dataplane algorithm")
Cc: sta...@dpdk.org

Signed-off-by: Vladimir Medvedkin 
---

v2:
 - remove unnecessary parenthesis

---
 lib/fib/dir24_8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fib/dir24_8.c b/lib/fib/dir24_8.c
index a8ba4f64ca..3efdcb533c 100644
--- a/lib/fib/dir24_8.c
+++ b/lib/fib/dir24_8.c
@@ -390,7 +390,7 @@ modify_fib(struct dir24_8_tbl *dp, struct rte_rib *rib, 
uint32_t ip,
(uint32_t)(1ULL << (32 - tmp_depth));
} else {
redge = ip + (uint32_t)(1ULL << (32 - depth));
-   if (ledge == redge)
+   if (ledge == redge && ledge != 0)
break;
ret = install_to_fib(dp, ledge, redge,
next_hop);
-- 
2.25.1

Re: [PATCH v2] raw/ntb: add check for disabling interrupt in dev close ops

[Thomas Monjalon]

03/07/2023 08:53, Wu, Jingjing:
> 
> > -Original Message-
> > From: Guo, Junfeng 
> > Sent: Wednesday, June 28, 2023 5:12 PM
> > To: Wu, Jingjing 
> > Cc: dev@dpdk.org; sta...@dpdk.org; He, Xingguang ; 
> > Laatz, Kevin
> > ; Guo, Junfeng 
> > Subject: [PATCH v2] raw/ntb: add check for disabling interrupt in dev close 
> > ops
> > 
> > During EAL cleanup stage, all bus devices are cleaned up properly.
> > In the meantime, the ntb example app will also do the device cleanup
> > process, which may call the dev ops '*dev->dev_ops->dev_close' twice.
> > 
> > If this dev ops for ntb was called twice, the interrupt handle for
> > EAL will be disabled twice and will lead to error for the seconde
> > time. Like this: "EAL: Error disabling MSI-X interrupts for fd xx"
> > 
> > Thus, this patch added the check process for disabling interrupt in
> > dev_close ops, to ensure that interrupt only be disabled once.
> > 
> > Fixes: 1cab1a40ea9b ("bus: cleanup devices on shutdown")
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Junfeng Guo 
> 
> Acked-by: Jingjing Wu 

Applied, thanks.

Re: [PATCH] member: fix PRNG seed reset in NitroSketch mode

[Stephen Hemminger]

On Wed, 21 Jun 2023 00:17:20 +0300
Dmitry Kozlyuk  wrote:

> Seeding the global PRNG at sketch creation
> does not make the sketch operation deterministic:
> it uses rte_rand() later, the PRNG may be seeded again by that point.
> On the other hand, seeding the global PRNG with a hash seed,
> is likely undesired, because it may be low-entropy or even constant.
> Deterministic operation can be achieved by seeding the PRNG externally.
> 
> Remove the call to rte_srand() at sketch creation.
> Document that hash seeds are not used by SKETCH set summary type.
> 
> Fixes: db354bd2e1f8 ("member: add NitroSketch mode")
> Cc: leyi.r...@intel.com
> 
> Signed-off-by: Dmitry Kozlyuk 

This raises a more global issue.
rte_srand() overrides the system seed which is set during startup.
This is a bad thing, it reduces the entropy in the random number generator.

There are two possible solutions to this:
1. Remove all all calls to rte_srand() and deprecate it.
2. Make rte_srand() add a fixed value to existing entropy. This is what the
   kernel PRNG does. It adds any user supplied additional entropy to original
   state.

Looking at current source.
  - code in tests seeding PRNG with TSC. This is unnecessary and can be removed.
  - this code in member library. Should be removed.

Acked-by: Stephen Hemminger 

Re: [PATCH] doc: fix missing release note for GVE PMD DQO

[Rushil Gupta]

On Sun, Jul 2, 2023 at 8:00 PM Junfeng Guo  wrote:
>
> Add missing release note for GVE PMD enabling for DQO queue format.
>
> Fixes: a14d391c7d99 ("net/gve: add Tx queue setup for DQO")
>
> Signed-off-by: Junfeng Guo 
> ---
>  doc/guides/rel_notes/release_23_07.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_23_07.rst 
> b/doc/guides/rel_notes/release_23_07.rst
> index 4459144140..28c538acc9 100644
> --- a/doc/guides/rel_notes/release_23_07.rst
> +++ b/doc/guides/rel_notes/release_23_07.rst
> @@ -200,6 +200,9 @@ New Features
>
>Enhanced the GRO library to support TCP packets over IPv6 network.
>
> +* **Added GVE PMD enabling for DQO.**
> +
> +  Added GVE PMD enabling for DQO queue format.
>
>  Removed Items
>  -
> --
> 2.34.1
>
Acked-by: Rushil Gupta 

[PATCH] net/mlx5: fix non-ip packets are not delivered when RSS hash type ESP is used.

[Maayan Kashani]

Non-ip packets such as ARP or LACP are not delivered if you use RTE flow rule 
with empty pattern and rss action with specific combination of RSS hash types: 
"ipv4-tcp ipv4-udp ipv4-other ipv6-tcp ipv6-udp ipv6-other esp".

The stack which used for RSS expansion was overflowed and trashed rss 
expanstion data(buf->entry[MLX5_RSS_EXP_ELT_N]). Use bigger stack size instead. 
And add relevant ASSERT for the future.

Signed-off-by: Maayan Kashani
Acked-by: Ori Kam
---
 drivers/net/mlx5/mlx5_flow.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index cf83db7b60..41e298855b 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -374,7 +374,7 @@ mlx5_flow_expand_rss_skip_explicit(const struct 
mlx5_flow_expand_node graph[],
return next;
 }
 
-#define MLX5_RSS_EXP_ELT_N 16
+#define MLX5_RSS_EXP_ELT_N 32
 
 /**
  * Expand RSS flows into several possible flows according to the RSS hash
@@ -539,6 +539,7 @@ mlx5_flow_expand_rss(struct mlx5_flow_expand_rss *buf, 
size_t size,
if (lsize > size)
return -EINVAL;
n = elt * sizeof(*item);
+   MLX5_ASSERT((buf->entries) < MLX5_RSS_EXP_ELT_N);
buf->entry[buf->entries].priority =
stack_pos + 1 + missed;
buf->entry[buf->entries].pattern = addr;
-- 
2.25.1

[PATCH] test: remove unnecessary rte_srand

[Stephen Hemminger]

The random number is already initialized to a better random
seed during starup process. The calls to rte_srand() are redundant
and actually make entropy worse.

Signed-off-by: Stephen Hemminger 
---
 app/test/test_fib6_perf.c| 2 --
 app/test/test_fib_perf.c | 2 --
 app/test/test_hash_multiwriter.c | 2 --
 app/test/test_lpm6_perf.c| 2 --
 app/test/test_lpm_perf.c | 2 --
 app/test/test_malloc.c   | 2 --
 app/test/test_memzone.c  | 1 -
 app/test/test_reciprocal_division.c  | 1 -
 app/test/test_reciprocal_division_perf.c | 2 --
 9 files changed, 16 deletions(-)

diff --git a/app/test/test_fib6_perf.c b/app/test/test_fib6_perf.c
index add20c2331b1..f5c06b4fc9d0 100644
--- a/app/test/test_fib6_perf.c
+++ b/app/test/test_fib6_perf.c
@@ -83,8 +83,6 @@ test_fib6_perf(void)
conf.trie.nh_sz = RTE_FIB6_TRIE_4B;
conf.trie.num_tbl8 = RTE_MIN(get_max_nh(conf.trie.nh_sz), 100U);
 
-   rte_srand(rte_rdtsc());
-
printf("No. routes = %u\n", (unsigned int) NUM_ROUTE_ENTRIES);
 
print_route_distribution(large_route_table,
diff --git a/app/test/test_fib_perf.c b/app/test/test_fib_perf.c
index b56293e64f41..fcf8d222d90a 100644
--- a/app/test/test_fib_perf.c
+++ b/app/test/test_fib_perf.c
@@ -334,8 +334,6 @@ test_fib_perf(void)
int status = 0;
int64_t count = 0;
 
-   rte_srand(rte_rdtsc());
-
generate_large_route_rule_table();
 
printf("No. routes = %u\n", (unsigned int) NUM_ROUTE_ENTRIES);
diff --git a/app/test/test_hash_multiwriter.c b/app/test/test_hash_multiwriter.c
index 0c5a8ca18607..3b70157b433b 100644
--- a/app/test/test_hash_multiwriter.c
+++ b/app/test/test_hash_multiwriter.c
@@ -146,8 +146,6 @@ test_hash_multiwriter(void)
tbl_multiwriter_test_params.nb_tsx_insertion)
* tbl_multiwriter_test_params.nb_tsx_insertion;
 
-   rte_srand(rte_rdtsc());
-
keys = rte_malloc(NULL, sizeof(uint32_t) * nb_entries, 0);
 
if (keys == NULL) {
diff --git a/app/test/test_lpm6_perf.c b/app/test/test_lpm6_perf.c
index 5b684686a687..2e79655aa89c 100644
--- a/app/test/test_lpm6_perf.c
+++ b/app/test/test_lpm6_perf.c
@@ -66,8 +66,6 @@ test_lpm6_perf(void)
config.number_tbl8s = NUMBER_TBL8S;
config.flags = 0;
 
-   rte_srand(rte_rdtsc());
-
printf("No. routes = %u\n", (unsigned) NUM_ROUTE_ENTRIES);
 
print_route_distribution(large_route_table, (uint32_t) 
NUM_ROUTE_ENTRIES);
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index e72437ba3850..dcc2eb375ae9 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -605,8 +605,6 @@ test_lpm_perf(void)
uint64_t cache_line_counter = 0;
int64_t count = 0;
 
-   rte_srand(rte_rdtsc());
-
generate_large_route_rule_table();
 
printf("No. routes = %u\n", (unsigned) NUM_ROUTE_ENTRIES);
diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
index ff081dd93139..b1d8be1e0491 100644
--- a/app/test/test_malloc.c
+++ b/app/test/test_malloc.c
@@ -692,8 +692,6 @@ test_random_alloc_free(void *_ __rte_unused)
unsigned i;
unsigned count = 0;
 
-   rte_srand((unsigned)rte_rdtsc());
-
for (i = 0; i < N; i++){
unsigned free_mem = 0;
size_t allocated_size;
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index f10f4fd9cd39..dd42f783c7ce 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -573,7 +573,6 @@ test_memzone_reserve_max_aligned(void)
socket = rte_socket_id_by_idx(i);
 
/* random alignment */
-   rte_srand((unsigned int)rte_rdtsc());
const unsigned int align = 1 << ((rte_rand() % 8) + 5); /* from 
128 up to 4k alignment */
 
/* memzone size may be between size and size - align */
diff --git a/app/test/test_reciprocal_division.c 
b/app/test/test_reciprocal_division.c
index 8ea9b1d24d27..c70b90d2f4d7 100644
--- a/app/test/test_reciprocal_division.c
+++ b/app/test/test_reciprocal_division.c
@@ -32,7 +32,6 @@ test_reciprocal(void)
struct rte_reciprocal reci_u32 = {0};
struct rte_reciprocal_u64 reci_u64 = {0};
 
-   rte_srand(rte_rdtsc());
printf("Validating unsigned 32bit division.\n");
for (i = 0; i < MAX_ITERATIONS; i++) {
/* Change divisor every DIVIDE_ITER iterations. */
diff --git a/app/test/test_reciprocal_division_perf.c 
b/app/test/test_reciprocal_division_perf.c
index 4f625873e53a..3d25be71cae5 100644
--- a/app/test/test_reciprocal_division_perf.c
+++ b/app/test/test_reciprocal_division_perf.c
@@ -37,8 +37,6 @@ test_reciprocal_division_perf(void)
struct rte_reciprocal reci_u32 = {0};
struct rte_reciprocal_u64 reci_u64 = {0};
 
-   rte_srand(rte_rdtsc());
-
printf("Validating unsigned 32bit division.\n");
for (i = 0; i

[PATCH] eal: avoid issues in macro expansion of alignment

[Stephen Hemminger]

RTE_ALIGN_MUL_NEAR is a macro so the cycle arguement could
get evaluated twice causing some potential skew.  Fix by
computing value once.

Suggested by patch to fix side effects.

Fixes: 5cbd14b3e5f9 ("eal: roundup TSC frequency when estimating")
Cc: pbhagavat...@marvell.com
Signed-off-by: Stephen Hemminger 
---
 lib/eal/common/eal_common_timer.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_timer.c 
b/lib/eal/common/eal_common_timer.c
index 5686a5102b66..05614b0503cf 100644
--- a/lib/eal/common/eal_common_timer.c
+++ b/lib/eal/common/eal_common_timer.c
@@ -42,10 +42,14 @@ estimate_tsc_freq(void)
RTE_LOG(WARNING, EAL, "WARNING: TSC frequency estimated roughly"
" - clock timings may be less accurate.\n");
/* assume that the rte_delay_us_sleep() will sleep for 1 second */
-   uint64_t start = rte_rdtsc();
+   uint64_t start, elapsed;
+
+   start = rte_rdtsc();
rte_delay_us_sleep(US_PER_S);
+   elapsed = rte_rdtsc() - start;
+
/* Round up to 10Mhz. 1E7 ~ 10Mhz */
-   return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);
+   return RTE_ALIGN_MUL_NEAR(elapsed, CYC_PER_10MHZ);
 }
 
 void
-- 
2.39.2

[PATCH] net/mlx5: forbid MPRQ restart

[Alexander Kozyrev]

The queue restart is only supported by the non-vectorized
single-packet receive queue today. Restarting MPRQ will
result in corrupted packets because of CQE and WQE mismatch.
Prevent this by not allowing the MPRQ Rx queue stop.

Fixes: 161d103b23 ("net/mlx5: add queue start and stop")
Cc: sta...@dpdk.org

Signed-off-by: Alexander Kozyrev 
---
 drivers/net/mlx5/mlx5_rxq.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index ad8fd13cbe..b314c0482b 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -531,12 +531,12 @@ mlx5_rx_queue_stop(struct rte_eth_dev *dev, uint16_t idx)
 * synchronized, that might be broken on RQ restart
 * and cause Rx malfunction, so queue stopping is
 * not supported if vectorized Rx burst is engaged.
-* The routine pointer depends on the process
-* type, should perform check there.
+* The routine pointer depends on the process type,
+* should perform check there. MPRQ is not supported as well.
 */
-   if (pkt_burst == mlx5_rx_burst_vec) {
-   DRV_LOG(ERR, "Rx queue stop is not supported "
-   "for vectorized Rx");
+   if (pkt_burst != mlx5_rx_burst) {
+   DRV_LOG(ERR, "Rx queue stop is only supported "
+   "for non-vectorized single-packet Rx");
rte_errno = EINVAL;
return -EINVAL;
}
-- 
2.18.2

Re: [dpdk-dev] [PATCH V1 0/2] examples/ethtool: fix MTU set and add MTU query

[Stephen Hemminger]

On Mon, 28 Jun 2021 11:23:12 +0800
"Min Hu (Connor)"  wrote:

> Hi, all,
>   any comments?
> 
> 在 2021/4/29 18:53, Min Hu (Connor) 写道:
> > From: Huisong Li 
> > 
> > This patchset fixes MTU data type when set MTU, and supports the query
> > of MTU.
> > 
> > Huisong Li (2):
> >examples/ethtool: fix data type of MTU
> >examples/ethtool: support the query of MTU
> > 
> >   examples/ethtool/ethtool-app/ethapp.c | 54 ++--
> >   examples/ethtool/lib/rte_ethtool.c| 16 ---
> >   examples/ethtool/lib/rte_ethtool.h| 16 ++-
> >   3 files changed, 63 insertions(+), 23 deletions(-)
> >   

There were several review comments.
In patch 1, the comment was that strtoul will return unsigned long.
Therefore new_mtu should be of type unsigned long, and check that is
is less than UINT16_MAX.

For the second patch, David's comment was that get and set should
logically be separate functions. The overlap was poor design in original
ethtool program, and lets not repeat that.

Overall, not many people looked at this patch because the ethtool
example is one of those "throw it over the wall and forget it" applications
that originally came from Cisco, and has seen little interest since then.

Re: [PATCH v2] examples/ethtool: update rxmode to increase functionality

[Stephen Hemminger]

On Thu, 11 Aug 2022 17:58:40 +0500
Muhammad Jawad Hussain  wrote:

> @@ -142,7 +183,6 @@ pcmd_quit_callback(__rte_unused void *ptr_params,
>   cmdline_quit(ctx);
>  }
>  
> -
>  static void
>  pcmd_drvinfo_callback(__rte_unused void *ptr_params,
>   __rte_unused struct cmdline *ctx,

Please don't do unrelated whitespace changes.

>  
> -
>  static void
> -pcmd_rxmode_callback(void *ptr_params,
> - __rte_unused struct cmdline *ctx,
> - __rte_unused void *ptr_data)
> +pcmd_rxmode_callback(void *parsed_result,
> +__rte_unused struct cmdline *cl,
> +__rte_unused void *data)
>  {
> - struct pcmd_intstr_params *params = ptr_params;
> - int stat;
> + int ret = -ENOTSUP;
> + uint16_t vf_rxmode = 0;
> + struct cmd_set_vf_rxmode *res = parsed_result;
> +
> + int is_on = (strcmp(res->on, "on") == 0) ? 1 : 0;

Simpler as:
bool is_on = !strcmp(res->on, "on");

Also what if use gives bogus value for on/off?

> + if (!strcmp(res->what, "rxmode")) {
> + if (!strcmp(res->mode, "AUPE"))
> + vf_rxmode |= RTE_ETH_VMDQ_ACCEPT_UNTAG;
> + else if (!strcmp(res->mode, "ROPE"))
> + vf_rxmode |= RTE_ETH_VMDQ_ACCEPT_HASH_UC;
> + else if (!strcmp(res->mode, "BAM"))
> + vf_rxmode |= RTE_ETH_VMDQ_ACCEPT_BROADCAST;
> + else if (!strncmp(res->mode, "MPE", 3))
> + vf_rxmode |= RTE_ETH_VMDQ_ACCEPT_MULTICAST;
> + }

You need to handle the "none of the above" case.

>  
> - if (!rte_eth_dev_is_valid_port(params->port)) {
> - printf("Error: Invalid port number %i\n", params->port);
> - return;
> + RTE_SET_USED(is_on);
> + RTE_SET_USED(vf_rxmode);
> +
> +#ifdef RTE_NET_IXGBE
> + if (ret == -ENOTSUP) {
> + ret = rte_pmd_ixgbe_set_vf_rxmode(res->port_id, res->vf_id,
> +   vf_rxmode, (uint8_t)is_on);
> + if (ret == -ENOTSUP)
> + printf("ixgbe not supported\n");
>   }
> - stat = rte_ethtool_net_set_rx_mode(params->port);
> - if (stat == 0)
> - return;
> - else if (stat == -ENOTSUP)
> - printf("Port %i: Operation not supported\n", params->port);
> - else
> - printf("Port %i: Error setting rx mode\n", params->port);
> +#endif
> +#ifdef RTE_NET_BNXT
> + if (ret == -ENOTSUP) {
> + ret = rte_pmd_bnxt_set_vf_rxmode(res->port_id, res->vf_id,
> +  vf_rxmode, (uint8_t)is_on);
> + if (ret == -ENOTSUP)
> + printf("bnxt not supported\n");
> + }
> +#endif


This is a mess. And it shows missing ethdev functionality.
Calling a driver with some unrelated device may break it.

Not sure if anyone really cares about ethtool?
But if they do please fixup and resubmit

Re: [PATCH] ethtool: added list command to list all available commands

[Stephen Hemminger]

On Mon, 21 Mar 2022 19:25:47 +0500
"huzaifa.rahman"  wrote:

> From: Huzaifa696 
> 
> help command is needed so user can see all the available commands directly
> from the command line along with the formats.
> 
> Signed-off-by: Huzaifa696 

Developer Certificate of Origin is intended to a legal assertion.
Therefore you must use your legal name (not alias here).

> ---
>  doc/guides/sample_app_ug/ethtool.rst  |  1 +
>  examples/ethtool/ethtool-app/ethapp.c | 38 +++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/doc/guides/sample_app_ug/ethtool.rst 
> b/doc/guides/sample_app_ug/ethtool.rst
> index 159e9e0639..6e57015170 100644
> --- a/doc/guides/sample_app_ug/ethtool.rst
> +++ b/doc/guides/sample_app_ug/ethtool.rst
> @@ -58,6 +58,7 @@ they do as follows:
>  * ``validate``: Check that given MAC address is valid unicast address
>  * ``vlan``: Add/remove VLAN id
>  * ``quit``: Exit program
> +* ``help``: List all available commands
>  
>  
>  Explanation
> diff --git a/examples/ethtool/ethtool-app/ethapp.c 
> b/examples/ethtool/ethtool-app/ethapp.c
> index 78e86534e8..361e2daf9b 100644
> --- a/examples/ethtool/ethtool-app/ethapp.c
> +++ b/examples/ethtool/ethtool-app/ethapp.c
> @@ -57,6 +57,8 @@ cmdline_parse_token_string_t pcmd_stats_token_cmd =
>   TOKEN_STRING_INITIALIZER(struct pcmd_get_params, cmd, "stats");
>  cmdline_parse_token_string_t pcmd_drvinfo_token_cmd =
>   TOKEN_STRING_INITIALIZER(struct pcmd_get_params, cmd, "drvinfo");
> +cmdline_parse_token_string_t pcmd_list_token_cmd =
> + TOKEN_STRING_INITIALIZER(struct pcmd_get_params, cmd, "help");
>  cmdline_parse_token_string_t pcmd_link_token_cmd =
>   TOKEN_STRING_INITIALIZER(struct pcmd_get_params, cmd, "link");
>  
> @@ -133,6 +135,11 @@ cmdline_parse_token_string_t pcmd_vlan_token_mode =
>  cmdline_parse_token_num_t pcmd_vlan_token_vid =
>   TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, RTE_UINT16);
>  
> +void
> +list_cmd(unsigned int sr, const char *name, const char *format, const char 
> *description)
> +{
> + printf("%-4d%-17s%-45s%-50s\n", sr, name, format, description);
> +}
>  
>  static void
>  pcmd_quit_callback(__rte_unused void *ptr_params,
> @@ -142,6 +149,30 @@ pcmd_quit_callback(__rte_unused void *ptr_params,
>   cmdline_quit(ctx);
>  }
>  
> +static void
> +pcmd_list_callback(__rte_unused void *ptr_params,
> + struct cmdline *ctx,
> + __rte_unused void *ptr_data)
> +{
> + printf("%-4s%-17s%-45s%-50s\n\n", "Sr.", "Name", "Format", 
> "Description");
> + list_cmd(1, "drvinfo", "drvinfo", "Print driver info");
> + list_cmd(2, "open", "open ", "Open port");
> + list_cmd(3, "pause", "pause  ", "Get/set port 
> pause state");
> + list_cmd(4, "stop", "stop ", "Stop port");
> + list_cmd(5, "portstats", "portstats ", "Print port 
> statistics");
> + list_cmd(6, "link", "link", "Print port link states");
> + list_cmd(7, "macaddr", "macaddr  ", "Gets/sets MAC 
> address");
> + list_cmd(8, "mtu", "mtu  ", "Set NIC MTU");
> + list_cmd(9, "regs", "regs  ", "Dump port register(s) 
> to file");
> + list_cmd(10, "ringparam", "ringparam   ", 
> "Get/set ring parameters");
> + list_cmd(11, "rxmode", "rxmode ", "Toggle port Rx mode");
> + list_cmd(12, "validate", "validate ", "Check that given MAC 
> address is valid unicast address");
> + list_cmd(13, "vlan", "vlan   ", "Add/remove 
> VLAN id");
> + list_cmd(14, "eeprom", "eeprom  ", "Dump EEPROM to 
> file");
> + list_cmd(15, "module-eeprom", "module-eeprom  ", 
> "Dump plugin module EEPROM to file");
> + list_cmd(16, "quit", "quit", "Exit program");
> + list_cmd(17, "help", "help", "List all available commands");
> +}


I think with some additional programming effort.
The help command could extract the existing help command strings for this.

Re: [PATCH] ethtool: remove a redundant call to rte_eth_dev_stop()

[Stephen Hemminger]

On Thu, 18 Aug 2022 15:18:36 +0500
Usman Tanveer  wrote:

> Hi,
> 
> Can you please have a look and update the status?

Looks OK to me.

Acked-by: Stephen Hemminger 

Re: [PATCH] ethtool: correct format strings according to the arguments

[Stephen Hemminger]

On Thu, 24 Mar 2022 10:31:24 +0500
"huzaifa.rahman"  wrote:

> The corrected format strings are not consistent with the
> given arguments. So they are changed accordingly.
> 
> Signed-off-by: huzaifa.rahman 
> ---
>  examples/ethtool/ethtool-app/main.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/examples/ethtool/ethtool-app/main.c 
> b/examples/ethtool/ethtool-app/main.c
> index 1f011a9321..ea8332e49c 100644
> --- a/examples/ethtool/ethtool-app/main.c
> +++ b/examples/ethtool/ethtool-app/main.c
> @@ -208,7 +208,7 @@ static int worker_main(__rte_unused void *ptr_data)
>   &ptr_port->mac_addr);
>   if (ret != 0) {
>   rte_spinlock_unlock(&ptr_port->lock);
> - printf("Failed to get MAC address (port 
> %u): %s",
> + printf("Failed to get MAC address (port 
> %i): %s",
>  ptr_port->idx_port,

It is a bigger change, but idx_port should be uint16_t not int.


>  rte_strerror(-ret));
>   return ret;
> @@ -284,11 +284,11 @@ int main(int argc, char **argv)
>   rte_exit(EXIT_FAILURE, "rte_eal_init(): Failed");
>  
>   cnt_ports = rte_eth_dev_count_avail();
> - printf("Number of NICs: %i\n", cnt_ports);
> + printf("Number of NICs: %u\n", cnt_ports);

Correct

>   if (cnt_ports == 0)
>   rte_exit(EXIT_FAILURE, "No available NIC ports!\n");
>   if (cnt_ports > MAX_PORTS) {
> - printf("Info: Using only %i of %i ports\n",
> + printf("Info: Using only %u of %i ports\n",
>   cnt_ports, MAX_PORTS

Both can be %u


>   );
>   cnt_ports = MAX_PORTS;

Re: [dpdk-dev] [PATCH] examples/ethtool: fix pause configuration

[Stephen Hemminger]

On Wed, 28 Apr 2021 16:42:59 +0800
"Min Hu (Connor)"  wrote:

> From: Huisong Li 
> 
> Currently, the pause command in ethtool to enable Rx/Tx pause has the
> following problem. Namely, Assume that the device supports flow control
> auto-negotiation to set pause parameters, which will the device that does
> not support flow control auto-negotiation fails to run this command.
> 
> This patch supports the configuration of flow control auto-negotiation
> and fixes the print format and style of the pause cmd to make it more
> readable.
> 
> Fixes: bda68ab9d1e7 ("examples/ethtool: add user-space ethtool sample 
> application")
> 
> Signed-off-by: Huisong Li 
> Signed-off-by: Min Hu (Connor) 

Overall, this looks good.
DPDK is mainly used in devices 1G and above where I think that
auto negotiation is required by IEEE spec.

Acked-by: Stephen Hemminger 

[PATCH v2] test: remove unnecessary rte_srand

[Stephen Hemminger]

The random number is already initialized to a better random
seed during startup process. The calls to rte_srand() are redundant
and actually make entropy worse.

Signed-off-by: Stephen Hemminger 
---
v2 - fix spelling error in commit message

 app/test/test_fib6_perf.c| 2 --
 app/test/test_fib_perf.c | 2 --
 app/test/test_hash_multiwriter.c | 2 --
 app/test/test_lpm6_perf.c| 2 --
 app/test/test_lpm_perf.c | 2 --
 app/test/test_malloc.c   | 2 --
 app/test/test_memzone.c  | 1 -
 app/test/test_reciprocal_division.c  | 1 -
 app/test/test_reciprocal_division_perf.c | 2 --
 9 files changed, 16 deletions(-)

diff --git a/app/test/test_fib6_perf.c b/app/test/test_fib6_perf.c
index add20c2331b1..f5c06b4fc9d0 100644
--- a/app/test/test_fib6_perf.c
+++ b/app/test/test_fib6_perf.c
@@ -83,8 +83,6 @@ test_fib6_perf(void)
conf.trie.nh_sz = RTE_FIB6_TRIE_4B;
conf.trie.num_tbl8 = RTE_MIN(get_max_nh(conf.trie.nh_sz), 100U);
 
-   rte_srand(rte_rdtsc());
-
printf("No. routes = %u\n", (unsigned int) NUM_ROUTE_ENTRIES);
 
print_route_distribution(large_route_table,
diff --git a/app/test/test_fib_perf.c b/app/test/test_fib_perf.c
index b56293e64f41..fcf8d222d90a 100644
--- a/app/test/test_fib_perf.c
+++ b/app/test/test_fib_perf.c
@@ -334,8 +334,6 @@ test_fib_perf(void)
int status = 0;
int64_t count = 0;
 
-   rte_srand(rte_rdtsc());
-
generate_large_route_rule_table();
 
printf("No. routes = %u\n", (unsigned int) NUM_ROUTE_ENTRIES);
diff --git a/app/test/test_hash_multiwriter.c b/app/test/test_hash_multiwriter.c
index 0c5a8ca18607..3b70157b433b 100644
--- a/app/test/test_hash_multiwriter.c
+++ b/app/test/test_hash_multiwriter.c
@@ -146,8 +146,6 @@ test_hash_multiwriter(void)
tbl_multiwriter_test_params.nb_tsx_insertion)
* tbl_multiwriter_test_params.nb_tsx_insertion;
 
-   rte_srand(rte_rdtsc());
-
keys = rte_malloc(NULL, sizeof(uint32_t) * nb_entries, 0);
 
if (keys == NULL) {
diff --git a/app/test/test_lpm6_perf.c b/app/test/test_lpm6_perf.c
index 5b684686a687..2e79655aa89c 100644
--- a/app/test/test_lpm6_perf.c
+++ b/app/test/test_lpm6_perf.c
@@ -66,8 +66,6 @@ test_lpm6_perf(void)
config.number_tbl8s = NUMBER_TBL8S;
config.flags = 0;
 
-   rte_srand(rte_rdtsc());
-
printf("No. routes = %u\n", (unsigned) NUM_ROUTE_ENTRIES);
 
print_route_distribution(large_route_table, (uint32_t) 
NUM_ROUTE_ENTRIES);
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index e72437ba3850..dcc2eb375ae9 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -605,8 +605,6 @@ test_lpm_perf(void)
uint64_t cache_line_counter = 0;
int64_t count = 0;
 
-   rte_srand(rte_rdtsc());
-
generate_large_route_rule_table();
 
printf("No. routes = %u\n", (unsigned) NUM_ROUTE_ENTRIES);
diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
index ff081dd93139..b1d8be1e0491 100644
--- a/app/test/test_malloc.c
+++ b/app/test/test_malloc.c
@@ -692,8 +692,6 @@ test_random_alloc_free(void *_ __rte_unused)
unsigned i;
unsigned count = 0;
 
-   rte_srand((unsigned)rte_rdtsc());
-
for (i = 0; i < N; i++){
unsigned free_mem = 0;
size_t allocated_size;
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index f10f4fd9cd39..dd42f783c7ce 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -573,7 +573,6 @@ test_memzone_reserve_max_aligned(void)
socket = rte_socket_id_by_idx(i);
 
/* random alignment */
-   rte_srand((unsigned int)rte_rdtsc());
const unsigned int align = 1 << ((rte_rand() % 8) + 5); /* from 
128 up to 4k alignment */
 
/* memzone size may be between size and size - align */
diff --git a/app/test/test_reciprocal_division.c 
b/app/test/test_reciprocal_division.c
index 8ea9b1d24d27..c70b90d2f4d7 100644
--- a/app/test/test_reciprocal_division.c
+++ b/app/test/test_reciprocal_division.c
@@ -32,7 +32,6 @@ test_reciprocal(void)
struct rte_reciprocal reci_u32 = {0};
struct rte_reciprocal_u64 reci_u64 = {0};
 
-   rte_srand(rte_rdtsc());
printf("Validating unsigned 32bit division.\n");
for (i = 0; i < MAX_ITERATIONS; i++) {
/* Change divisor every DIVIDE_ITER iterations. */
diff --git a/app/test/test_reciprocal_division_perf.c 
b/app/test/test_reciprocal_division_perf.c
index 4f625873e53a..3d25be71cae5 100644
--- a/app/test/test_reciprocal_division_perf.c
+++ b/app/test/test_reciprocal_division_perf.c
@@ -37,8 +37,6 @@ test_reciprocal_division_perf(void)
struct rte_reciprocal reci_u32 = {0};
struct rte_reciprocal_u64 reci_u64 = {0};
 
-   rte_srand(rte_rdtsc());
-
printf("Validating unsigne

[PATCH v2] eal: avoid issues in macro expansion of alignment

[Stephen Hemminger]

RTE_ALIGN_MUL_NEAR is a macro so the cycle argument could
get evaluated twice causing some potential skew.  Fix by
computing value once.

Suggested by patch to fix side effects.

Fixes: 5cbd14b3e5f9 ("eal: roundup TSC frequency when estimating")
Cc: pbhagavat...@marvell.com
Signed-off-by: Stephen Hemminger 
---
v2 - fix spelling error in commit message

 lib/eal/common/eal_common_timer.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/eal/common/eal_common_timer.c 
b/lib/eal/common/eal_common_timer.c
index 5686a5102b66..05614b0503cf 100644
--- a/lib/eal/common/eal_common_timer.c
+++ b/lib/eal/common/eal_common_timer.c
@@ -42,10 +42,14 @@ estimate_tsc_freq(void)
RTE_LOG(WARNING, EAL, "WARNING: TSC frequency estimated roughly"
" - clock timings may be less accurate.\n");
/* assume that the rte_delay_us_sleep() will sleep for 1 second */
-   uint64_t start = rte_rdtsc();
+   uint64_t start, elapsed;
+
+   start = rte_rdtsc();
rte_delay_us_sleep(US_PER_S);
+   elapsed = rte_rdtsc() - start;
+
/* Round up to 10Mhz. 1E7 ~ 10Mhz */
-   return RTE_ALIGN_MUL_NEAR(rte_rdtsc() - start, CYC_PER_10MHZ);
+   return RTE_ALIGN_MUL_NEAR(elapsed, CYC_PER_10MHZ);
 }
 
 void
-- 
2.39.2

Re: [dpdk-dev] [PATCH 1/2] doc: add policy for adding vendor PMD specific examples

[Stephen Hemminger]

On Wed, 17 Nov 2021 11:57:34 +0100
Thomas Monjalon  wrote:

> 26/05/2021 09:47, Hemant Agrawal:
> > This patch update the dpdk sample app policy to support
> > vendor PMD specific test examples in the respective drivers
> > sub-directory in examples.  
> 
> Please could you add a link to the decision in techboard minutes?
> 
> > Signed-off-by: Hemant Agrawal 
> > ---
> >  doc/guides/sample_app_ug/intro.rst | 16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/doc/guides/sample_app_ug/intro.rst 
> > b/doc/guides/sample_app_ug/intro.rst
> > index 8ff223b16c..fd34e7790d 100644
> > --- a/doc/guides/sample_app_ug/intro.rst
> > +++ b/doc/guides/sample_app_ug/intro.rst
> > @@ -58,10 +58,6 @@ examples are highlighted below.
> >forwarding Graph, or ``l3fwd_graph`` application does forwarding based 
> > on IPv4
> >like a simple router with DPDK Graph framework.
> >  
> > -* :doc:`Hardware packet copying`: The Hardware packet copying,
> > -  or ``ioatfwd`` application demonstrates how to use IOAT rawdev driver for
> > -  copying packets between two threads.
> > -
> >  * :doc:`Packet Distributor`: The Packet Distributor
> >demonstrates how to distribute packets arriving on an Rx port to 
> > different
> >cores for processing and transmission.
> > @@ -94,3 +90,15 @@ examples are highlighted below.
> >  There are many more examples shown in the following chapters. Each of the
> >  documented sample applications show how to compile, configure and run the
> >  application as well as explaining the main functionality of the code.
> > +
> > +Driver specific Sample Application
> > +--
> > +
> > +There are case where exiting sample applications may not be suitable to 
> > test  
> 
> typo: existing
> 
> > +a new driver contribution. In such cases a new driver specific sample 
> > application
> > +can be added to specific drivers sub-directory in the examples folder with 
> > prior
> > +approval from DPDK technical board. e.g.
> > +
> > +* :doc:`Hardware packet copying`: The Hardware packet copying,
> > +  or ``ioat`` application demonstrates how to use IOAT rawdev driver for
> > +  copying packets between two threads.  
> 
> This example is now generic and renamed as examples/dma.
> 
> 

This patch never got an update.
Please resubmit, would be good to get renames in by 23.11 release

Re: [dpdk-dev] [PATCH v2 2/2] examples/flow_classify: add an ACL table for tcp

[Stephen Hemminger]

On Thu, 19 Aug 2021 12:34:46 -0700
Sowmini Varadhan  wrote:

> On (08/19/21 16:21), Iremonger, Bernard wrote:
> > 
> > Looking closer at this patchset, I am not sure that a second ACL table is 
> > needed.
> > The existing ACL table handles UDP, TCP and SCP, however it is not 
> > processing the TCP flags.
> > I think it just needs to be modified to process the TCP flags.
> > Could you take another look to see if the above proposed solution will work 
> > for you.  
> 
> I'm not sure it would. As I pointed out in the original rfc  at
> https://inbox.dpdk.org/dev/cover.1578936382.git.sowmini.varad...@microsoft.com/
> 
> we need to add a key for the 8 bit flags, but the multibit
> trie lookup moves in steps of 4 bytes.
> 
> However, it has admittedly been a while since I tinkereed with this,
> and I can give it a shot and get back.
> 
> Thanks
> --Sowmini
> 

Doing a cleanup of patch backlog prior to next LTS release.
The patch never got updated based on comments.
Please resubmit if you still want to pursue it.

Re: [PATCH] test/ipsec: fix TAP default MAC address

[Stephen Hemminger]

On Wed, 28 Jun 2023 19:12:35 +
Vladimir Medvedkin  wrote:

> default TAP mac address was changed in commit id:
> c3006be2acab49c6b77ae9c9ef04b061e5dacbd6
> reflect changes in ipsec test scripts.
> 
> Fixes: c3006be2acab ("net/tap: set locally administered bit for fixed MAC 
> address")
> Cc: d...@linux.vnet.ibm.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Vladimir Medvedkin 

Acked-by: Stephen Hemminger 

Re: [dpdk-dev] [PATCH v2 1/1] vfio: add page-by-page mapping API

[Stephen Hemminger]

On Thu, 2 Jun 2022 10:23:07 +0200
David Marchand  wrote:

> Hello Anatoly,
> 
> On Tue, Nov 2, 2021 at 4:54 PM Burakov, Anatoly
>  wrote:
> >
> > On 28-Oct-21 3:09 PM, Anatoly Burakov wrote:  
> > > Currently, there is no way to map memory for DMA in a way that allows
> > > unmapping it partially later, because some IOMMU's do not support
> > > partial unmapping. There is a workaround of mapping all of these
> > > segments separately, but this is inconvenient and silly, so this
> > > commit adds a proper API that does it.
> > >
> > > This commit relies on earlier infrastructure that was built out to
> > > support "chunking", as the concept of "chunks" is essentially the same
> > > as page size.
> > >
> > > Signed-off-by: Anatoly Burakov 
> > > ---
> > >
> > > Notes:
> > >  v2:
> > >  - Added checks for page alignment of supplied values
> > >  - Added rte_errno values (similar to patch 103165 [1])
> > >
> > >  [1] 
> > > http://patches.dpdk.org/project/dpdk/patch/e8c5e7ba089e2283c3cd67e4529e52fe49390eb9.1635428963.git.anatoly.bura...@intel.com/
> > >   
> >
> > I think this API also needs VA and IOVA addresses in an array, so that
> > it's possible to map IOVA-discontiguous segments. This is too late for
> > this release, so let's postpone it till 22.02.  
> 
> It seems this patch fell through the cracks.
> Any update?
> 
> Thanks.

It is not clear what problem this is trying to solve.
Is it for some hardware platform that is not available?
Any updates on this patch or should it just be dropped?

Re: [dpdk-dev] [RFC 0/3] Add mdev (Mediated device) support in DPDK

[Stephen Hemminger]

On Wed, 10 Apr 2019 12:02:28 +0200
Francois Ozog  wrote:

> Hi all,
> 
> I presented an approach in Fosdem
> (https://archive.fosdem.org/2018/schedule/event/netmdev/) and feel
> happy someone is picking up.

After reading through this old patch set, it looks like there are a number
of loose ends. If it is still valid and can be used with current upstream
LTS kernel, the please rebase and resubmit it please.

Re: [PATCH 2/2] known_issues: drop note about UIO with really old kernels

[Stephen Hemminger]

On Thu, 17 Feb 2022 08:45:17 -0800
Stephen Hemminger  wrote:

> The DPDK has not supported 3.9 kernel for a long time so the
> release note about UIO kernel bug in older versions is no
> longer relevant.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  doc/guides/rel_notes/known_issues.rst | 21 -
>  1 file changed, 21 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/known_issues.rst 
> b/doc/guides/rel_notes/known_issues.rst
> index 187d9c942e56..56fc38a0edd1 100644
> --- a/doc/guides/rel_notes/known_issues.rst
> +++ b/doc/guides/rel_notes/known_issues.rst
> @@ -415,27 +415,6 @@ Differences in how different Intel NICs handle maximum 
> packet length for jumbo f
> Poll Mode Driver (PMD).
>  
>  
> -Binding PCI devices to igb_uio fails on Linux kernel 3.9 when more than one 
> device is used
> ---
> -
> -**Description**:
> -   A known bug in the UIO driver included in Linux kernel version 3.9 
> prevents more than one PCI device to be
> -   bound to the igb_uio driver.
> -
> -**Implication**:
> -   The Poll Mode Driver (PMD) will crash on initialization.
> -
> -**Resolution/Workaround**:
> -   Use earlier or later kernel versions, or apply the following
> -   `patch  
> `_.
> -
> -**Affected Environment/Platform**:
> -   Linux systems with kernel version 3.9
> -
> -**Driver/Module**:
> -   igb_uio module
> -
> -
>  GCC might generate Intel® AVX instructions for processors without Intel® AVX 
> support
>  
> 
>  

Could someone review this patch? It been stuck for a long time.

Re: [PATCH v5 00/14] add FreeBSD support to VMBUS & NetVSC PMDs

[Stephen Hemminger]

On Thu, 06 Oct 2022 16:58:01 +0200
Thomas Monjalon  wrote:

> 18/05/2022 10:18, Thomas Monjalon:
> > 23/04/2022 06:28, Srikanth Kaka:  
> > > This patchset requires FreeBSD VMBus kernel changes and
> > > HV_UIO driver. Both are currently under review at
> > > https://reviews.freebsd.org/D32184  
> > 
> > What is the status of the dependencies on FreeBSD side?
> > 
> > Should we have another review of the DPDK series here?  
> 
> No reply? No progress?

Will this work with upstream FreeBSD?
Will it work with current DPDK 23.08?
Is someone going to maintain it and test it?

If so please resubmit a new version rebased on current tree.
Marking the patch series as "Awaiting Upstream"