Re: [PATCH] dts: automatically bring up link on interfaces

[Paul Szczepanek]

Reviewed-by: Paul Szczepanek 

Re: compilation|FAILURE| pw(150482) sid(34444) job(PER_PATCH_BUILD14715)[v6, 25/25] net/intel: extract common Rx vector criteria

[Bruce Richardson]

On Sun, Jan 26, 2025 at 01:45:54AM +, Liao, TingtingX wrote:
>Sorry. There is no error with this series.
> 
>The error is caused by the CI doesn't apply any changes with doc/*.
> 
>Community decided to exclude doc/*,  as doc/* change frequently,
>especially the release notes, cause a lot of conflict with main tree.
> 
Can the Intel CI be changed to only exclude release notes changes rather
than all doc changes? Outside of the release notes, conflicts are not very
common.

Regards,
/Bruce

Re: [PATCH dpdk] telemetry-exporter: listen on loopback by default

[Bruce Richardson]

On Mon, Jan 27, 2025 at 12:51:44PM +0100, Robin Jarry wrote:
> Fix the following warning reported by Coverity:
> 
> Defect type: SIGMA.insecure_network_bind:
> > dpdk-stable-24.11.1/usertools/dpdk-telemetry-exporter.py:278:
> > Sigma main event: The HTTP server binds to all network interfaces by
> > setting the IP address to "", `0.0.0.0`, `::`, or `::0`.
> > This may expose the server to unintended traffic.
> 
> Avoid listening to all interfaces by default to avoid exposing private
> information unwillingly.
> 
> Unrelated: The Python stdlib TCP server listens on IPv4 only by default.
> Changing this requires creating a subclass that overrides address_family
> to socket.AF_INET6.
> 
> Fixes: d94ebd627a86 ("usertools: add telemetry exporter")
> Cc: sta...@dpdk.org
> Signed-off-by: Robin Jarry 
> ---
>  usertools/dpdk-telemetry-exporter.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/usertools/dpdk-telemetry-exporter.py 
> b/usertools/dpdk-telemetry-exporter.py
> index 6eca0db2e80a..6f66d4ecaab1 100755
> --- a/usertools/dpdk-telemetry-exporter.py
> +++ b/usertools/dpdk-telemetry-exporter.py
> @@ -75,7 +75,7 @@ def cmd(self, uri, arg=None) -> dict | list:
>  "/usr/local/share/dpdk/telemetry-endpoints",
>  "/usr/share/dpdk/telemetry-endpoints",
>  ]
> -DEFAULT_OUTPUT = "openmetrics://:9876"
> +DEFAULT_OUTPUT = "openmetrics://127.0.0.1:9876"
>  

Minor nit, but would it be better to use "localhost" rather than the
hardcoded IP here and below?

>  
>  def main():
> @@ -275,11 +275,11 @@ def serve_openmetrics(
>  Start an HTTP server and serve requests in the openmetrics/prometheus
>  format.
>  """
> -listen = (args.output.hostname or "", int(args.output.port or 80))
> +listen = (args.output.hostname or "127.0.0.1", int(args.output.port or 
> 80))
>  with server.HTTPServer(listen, OpenmetricsHandler) as httpd:
>  httpd.dpdk_socket_path = args.socket_path
>  httpd.telemetry_endpoints = endpoints
> -LOG.info("listening on port %s", httpd.server_port)
> +LOG.info("listening on %s", httpd.socket.getsockname())
>  try:
>  httpd.serve_forever()
>  except KeyboardInterrupt:
> -- 
> 2.48.1
> 

Re: [PATCH v2] build: force gcc to initialize padding bits

[Bruce Richardson]

On Fri, Jan 24, 2025 at 10:26:48AM -0800, Stephen Hemminger wrote:
> With GCC 15, the compiler has changed the default behavior when
> initialization is used for aggregate variables. The new default
> is to follow the standard (C23) and not initialize everything by
> default. This breaks assumptions in some drivers and can be
> lead to other bugs. Use the new zero initialization flag to
> force of all fields to zero.
> 
> Note: other compilers always initialize to zero in these cases.
> Only GCC seems to have decided to start initializing less as
> a silly attempt at optimization.
> 
> Signed-off-by: Stephen Hemminger 
> Acked-by: Morten Brørup 
Acked-by: Bruce Richardson 

Re: [PATCH] build: force gcc to initialize padding bits

[Bruce Richardson]

On Fri, Jan 24, 2025 at 10:37:48AM -0800, Stephen Hemminger wrote:
> On Fri, 24 Jan 2025 09:38:20 +
> Bruce Richardson  wrote:
> 
> > >   
> > 
> > Does this flag give us additional guarantees of padding being
> > zero-initialized that were there before? From my reading of the gcc doc[1],
> > "..padding-bits=union" corresponds to the old behaviour, right?
> > 
> > This also means we will have different padding behaviour on clang and gcc,
> > since clang (at least v18 on my board) doesn't support this flag. Do we see
> > any issues with that?
> > 
> > /Bruce
> 
> I chose the setting based on some email with the Linux kernel hardening
> project and their choice.
> 
> Clang decided to fix and just do the right thing.
> 
> 
> https://github.com/llvm/llvm-project/commit/7a086e1b2dc05f54afae3591614feede727601fa

Excellent. Agree on initializing everything being "the right thing".

[PATCH] net/mlx5: fix leak in HWS flow counter action

[David Marchand]

This was caught by our internal covscan.
mp_name can be leaked in case of errors.

Fixes: 4d368e1da3a4 ("net/mlx5: support flow counter action for HWS")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
 drivers/net/mlx5/mlx5_hws_cnt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_hws_cnt.c b/drivers/net/mlx5/mlx5_hws_cnt.c
index 0197c098f6..eaceedd5ba 100644
--- a/drivers/net/mlx5/mlx5_hws_cnt.c
+++ b/drivers/net/mlx5/mlx5_hws_cnt.c
@@ -723,7 +723,7 @@ mlx5_hws_cnt_pool_create(struct rte_eth_dev *dev,
if (priv->sh->cnt_svc == NULL) {
ret = mlx5_hws_cnt_svc_init(priv->sh, error);
if (ret)
-   return ret;
+   goto error;
}
cparam.fetch_sz = HWS_CNT_CACHE_FETCH_DEFAULT;
cparam.preload_sz = HWS_CNT_CACHE_PRELOAD_DEFAULT;
@@ -767,6 +767,7 @@ mlx5_hws_cnt_pool_create(struct rte_eth_dev *dev,
MLX5_ASSERT(ret);
mlx5_hws_cnt_pool_destroy(priv->sh, cpool);
priv->hws_cpool = NULL;
+   mlx5_free(mp_name);
return ret;
 }
 
-- 
2.47.1

[PATCH dpdk] telemetry-exporter: listen on loopback by default

[Robin Jarry]

Fix the following warning reported by Coverity:

Defect type: SIGMA.insecure_network_bind:
> dpdk-stable-24.11.1/usertools/dpdk-telemetry-exporter.py:278:
> Sigma main event: The HTTP server binds to all network interfaces by
> setting the IP address to "", `0.0.0.0`, `::`, or `::0`.
> This may expose the server to unintended traffic.

Avoid listening to all interfaces by default to avoid exposing private
information unwillingly.

Unrelated: The Python stdlib TCP server listens on IPv4 only by default.
Changing this requires creating a subclass that overrides address_family
to socket.AF_INET6.

Fixes: d94ebd627a86 ("usertools: add telemetry exporter")
Cc: sta...@dpdk.org
Signed-off-by: Robin Jarry 
---
 usertools/dpdk-telemetry-exporter.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/usertools/dpdk-telemetry-exporter.py 
b/usertools/dpdk-telemetry-exporter.py
index 6eca0db2e80a..6f66d4ecaab1 100755
--- a/usertools/dpdk-telemetry-exporter.py
+++ b/usertools/dpdk-telemetry-exporter.py
@@ -75,7 +75,7 @@ def cmd(self, uri, arg=None) -> dict | list:
 "/usr/local/share/dpdk/telemetry-endpoints",
 "/usr/share/dpdk/telemetry-endpoints",
 ]
-DEFAULT_OUTPUT = "openmetrics://:9876"
+DEFAULT_OUTPUT = "openmetrics://127.0.0.1:9876"
 
 
 def main():
@@ -275,11 +275,11 @@ def serve_openmetrics(
 Start an HTTP server and serve requests in the openmetrics/prometheus
 format.
 """
-listen = (args.output.hostname or "", int(args.output.port or 80))
+listen = (args.output.hostname or "127.0.0.1", int(args.output.port or 80))
 with server.HTTPServer(listen, OpenmetricsHandler) as httpd:
 httpd.dpdk_socket_path = args.socket_path
 httpd.telemetry_endpoints = endpoints
-LOG.info("listening on port %s", httpd.server_port)
+LOG.info("listening on %s", httpd.socket.getsockname())
 try:
 httpd.serve_forever()
 except KeyboardInterrupt:
-- 
2.48.1

RE: [PATCH 1/2] common/idpf: enable AVX2 for single queue Rx

[Wani, Shaiq]

Hi, 

Thanks for the review and feedback.

Below I have addressed your comments inline.

-Original Message-
From: Richardson, Bruce  
Sent: Monday, January 20, 2025 7:46 PM
To: Wani, Shaiq 
Cc: dev@dpdk.org; Singh, Aman Deep 
Subject: Re: [PATCH 1/2] common/idpf: enable AVX2 for single queue Rx

On Wed, Jan 08, 2025 at 05:47:56PM +0530, Shaiq Wani wrote:
> In case some CPUs don't support AVX512. Enable AVX2 for them to get 
> better per-core performance.
> 
> Signed-off-by: Shaiq Wani 

Hi,

some review comments inline below.

/Bruce

> ---
>  drivers/common/idpf/idpf_common_device.h|   1 +
>  drivers/common/idpf/idpf_common_rxtx.h  |   4 +
>  drivers/common/idpf/idpf_common_rxtx_avx2.c | 590 
>  drivers/common/idpf/meson.build |  15 +
>  drivers/common/idpf/version.map |   1 +
>  drivers/net/idpf/idpf_rxtx.c|  12 +
>  6 files changed, 623 insertions(+)
>  create mode 100644 drivers/common/idpf/idpf_common_rxtx_avx2.c
> 
> diff --git a/drivers/common/idpf/idpf_common_device.h 
> b/drivers/common/idpf/idpf_common_device.h
> index bfa927a5ff..734be1c88a 100644
> --- a/drivers/common/idpf/idpf_common_device.h
> +++ b/drivers/common/idpf/idpf_common_device.h
> @@ -123,6 +123,7 @@ struct idpf_vport {
>  
>   bool rx_vec_allowed;
>   bool tx_vec_allowed;
> + bool rx_use_avx2;
>   bool rx_use_avx512;
>   bool tx_use_avx512;
>  
> diff --git a/drivers/common/idpf/idpf_common_rxtx.h 
> b/drivers/common/idpf/idpf_common_rxtx.h
> index ed12e2..f50cf5ef46 100644
> --- a/drivers/common/idpf/idpf_common_rxtx.h
> +++ b/drivers/common/idpf/idpf_common_rxtx.h
> @@ -302,5 +302,9 @@ uint16_t idpf_dp_splitq_xmit_pkts_avx512(void 
> *tx_queue, struct rte_mbuf **tx_pk  __rte_internal  uint16_t 
> idpf_dp_singleq_recv_scatter_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
> uint16_t nb_pkts);
> +__rte_internal
> +uint16_t idpf_dp_singleq_recv_pkts_avx2(void *rx_queue,
> + struct rte_mbuf **rx_pkts,
> + uint16_t nb_pkts);
>  

I'm a little confused by the "singleq" part of the name here, can you explain a 
little (in the commit message, perhaps) what is the "single"
referring to? Does the driver have the ability to poll multiple queues at once 
or something?
[SHAIQ] - Idpf supports singleq and splitq models. In the singleq model, 
packets are processed and stored in order within a single RX queue. This will 
be explicitly mentioned in v2 of the patch.

>  #endif /* _IDPF_COMMON_RXTX_H_ */
> diff --git a/drivers/common/idpf/idpf_common_rxtx_avx2.c 
> b/drivers/common/idpf/idpf_common_rxtx_avx2.c
> new file mode 100644
> index 00..a05b26c68a
> --- /dev/null
> +++ b/drivers/common/idpf/idpf_common_rxtx_avx2.c
> @@ -0,0 +1,590 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2023 Intel Corporation  */
> +
> +#include 
> +
> +#include "idpf_common_rxtx.h"
> +#include "idpf_common_device.h"
> +
> +#ifndef __INTEL_COMPILER
> +#pragma GCC diagnostic ignored "-Wcast-qual"
> +#endif

There is work ongoing to stop using this warning removal [1]. This code may 
need to be rebased on top of that if it's applied soon.

[1] https://patches.dpdk.org/project/dpdk/list/?series=34390
[SHAIQ]- As for the warnings, we will address them once the patchset 
[https://patches.dpdk.org/project/dpdk/list/?series=34390] is merged.

> +
> +static __rte_always_inline void
> +idpf_singleq_rx_rearm(struct idpf_rx_queue *rxq) {
> + int i;
> + uint16_t rx_id;
> + volatile union virtchnl2_rx_desc *rxdp = rxq->rx_ring;
> + struct rte_mbuf **rxep = &rxq->sw_ring[rxq->rxrearm_start];
> +
> + rxdp += rxq->rxrearm_start;
> +
> + /* Pull 'n' more MBUFs into the software ring */
> + if (rte_mempool_get_bulk(rxq->mp,
> +  (void *)rxep,
> +  IDPF_RXQ_REARM_THRESH) < 0) {
> + if (rxq->rxrearm_nb + IDPF_RXQ_REARM_THRESH >=
> + rxq->nb_rx_desc) {
> + __m128i dma_addr0;
> +
> + dma_addr0 = _mm_setzero_si128();
> + for (i = 0; i < IDPF_VPMD_DESCS_PER_LOOP; i++) {
> + rxep[i] = &rxq->fake_mbuf;
> + _mm_store_si128((__m128i *)&rxdp[i].read,
> + dma_addr0);
> + }
> + }
> + rte_atomic_fetch_add_explicit(&rxq->rx_stats.mbuf_alloc_failed,
> +IDPF_RXQ_REARM_THRESH, 
> rte_memory_order_relaxed);
> +
> + return;
> + }
> +
> + struct rte_mbuf *mb0, *mb1;
> + __m128i dma_addr0, dma_addr1;
> + __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
> + RTE_PKTMBUF_HEADROOM);
> + /* Initialize the mbufs in vector, process 2 mbufs in one loop */
> + for (i = 0; i < IDPF_RXQ_REAR

RE: [PATCH 2/2] common/idpf: enable AVX2 for single queue Tx

[Wani, Shaiq]

Hi,

Thanks for your review and feedback.

Below I have addressed your comments inline.

-Original Message-
From: Richardson, Bruce  
Sent: Monday, January 20, 2025 7:53 PM
To: Wani, Shaiq 
Cc: dev@dpdk.org; Singh, Aman Deep 
Subject: Re: [PATCH 2/2] common/idpf: enable AVX2 for single queue Tx

On Wed, Jan 08, 2025 at 05:47:57PM +0530, Shaiq Wani wrote:
> In case some CPUs don't support AVX512. Enable AVX2 for them to get 
> better per-core performance.
> 
> Signed-off-by: Shaiq Wani 
> ---

Hi,

some review comments inline below.

/Bruce

>  doc/guides/rel_notes/release_25_03.rst  |   3 +
>  drivers/common/idpf/idpf_common_device.h|   1 +
>  drivers/common/idpf/idpf_common_rxtx.h  |   4 +
>  drivers/common/idpf/idpf_common_rxtx_avx2.c | 225 
>  drivers/common/idpf/version.map |   1 +
>  drivers/net/idpf/idpf_rxtx.c|  14 ++
>  6 files changed, 248 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_25_03.rst 
> b/doc/guides/rel_notes/release_25_03.rst
> index 426dfcd982..7ded85dac4 100644
> --- a/doc/guides/rel_notes/release_25_03.rst
> +++ b/doc/guides/rel_notes/release_25_03.rst
> @@ -55,6 +55,9 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   ===
>  
> +   * **Added support of vector instructions on IDPF.**
> +
> + Added support of AVX2 instructions in IDPF single queue RX and TX path.
>  

Driver already had vector instructions so title is a little misleading.
Clarify the title to be AVX2-specific. For the body, please clarify singleq vs 
splitq and what the differences are and when one might get the benefit of the 
AVX2 code path.
[SHAIQ]- Will address the change in v2 of the patch.
>  Removed Items
>  -
> diff --git a/drivers/common/idpf/idpf_common_device.h 
> b/drivers/common/idpf/idpf_common_device.h
> index 734be1c88a..5f3e4a4fcf 100644
> --- a/drivers/common/idpf/idpf_common_device.h
> +++ b/drivers/common/idpf/idpf_common_device.h
> @@ -124,6 +124,7 @@ struct idpf_vport {
>   bool rx_vec_allowed;
>   bool tx_vec_allowed;

Do we have vector paths other than the 2 AVX ones below. If not, why do we need 
this flag?
[SHAIQ]- Some processors, e.g., Denverton, support SSE but not AVX.

>   bool rx_use_avx2;
> + bool tx_use_avx2;
>   bool rx_use_avx512;
>   bool tx_use_avx512;
>  
> diff --git a/drivers/common/idpf/idpf_common_rxtx.h 
> b/drivers/common/idpf/idpf_common_rxtx.h
> index f50cf5ef46..e19e1878f3 100644
> --- a/drivers/common/idpf/idpf_common_rxtx.h
> +++ b/drivers/common/idpf/idpf_common_rxtx.h
> @@ -306,5 +306,9 @@ __rte_internal
>  uint16_t idpf_dp_singleq_recv_pkts_avx2(void *rx_queue,
>   struct rte_mbuf **rx_pkts,
>   uint16_t nb_pkts);
> +__rte_internal
> +uint16_t idpf_dp_singleq_xmit_pkts_avx2(void *tx_queue,
> + struct rte_mbuf **tx_pkts,
> + uint16_t nb_pkts);
>  
>  #endif /* _IDPF_COMMON_RXTX_H_ */
> diff --git a/drivers/common/idpf/idpf_common_rxtx_avx2.c 
> b/drivers/common/idpf/idpf_common_rxtx_avx2.c
> index a05b26c68a..a4bc8e2bef 100644
> --- a/drivers/common/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/common/idpf/idpf_common_rxtx_avx2.c
> @@ -588,3 +588,228 @@ idpf_dp_singleq_recv_pkts_avx2(void *rx_queue, 
> struct rte_mbuf **rx_pkts,  {
>   return _idpf_singleq_recv_raw_pkts_vec_avx2(rx_queue, rx_pkts, 
> nb_pkts, NULL);  }
> +
> +static __rte_always_inline void
> +idpf_tx_backlog_entry(struct idpf_tx_entry *txep,
> +  struct rte_mbuf **tx_pkts, uint16_t nb_pkts) {
> + int i;
> +
> + for (i = 0; i < (int)nb_pkts; ++i)
> + txep[i].mbuf = tx_pkts[i];
> +}
> +
> +static __rte_always_inline int
> +idpf_singleq_tx_free_bufs_vec(struct idpf_tx_queue *txq) {
> + struct idpf_tx_entry *txep;
> + uint32_t n;
> + uint32_t i;
> + int nb_free = 0;
> + struct rte_mbuf *m, *free[txq->rs_thresh];
> +
> + /* check DD bits on threshold descriptor */
> + if ((txq->tx_ring[txq->next_dd].qw1 &
> + rte_cpu_to_le_64(IDPF_TXD_QW1_DTYPE_M)) !=
> + rte_cpu_to_le_64(IDPF_TX_DESC_DTYPE_DESC_DONE))
> + return 0;
> +
> + n = txq->rs_thresh;
> +
> +  /* first buffer to free from S/W ring is at index
> +   * next_dd - (rs_thresh-1)
> +   */
> + txep = &txq->sw_ring[txq->next_dd - (n - 1)];
> + m = rte_pktmbuf_prefree_seg(txep[0].mbuf);
> + if (likely(m)) {
> + free[0] = m;
> + nb_free = 1;
> + for (i = 1; i < n; i++) {
> + m = rte_pktmbuf_prefree_seg(txep[i].mbuf);
> + if (likely(m)) {
> + if (likely(m->pool == free[0]->pool)) {
> + free[nb_free++] = m;
> +   

RE: [EXTERNAL] [PATCH 1/2] trace: support expression for blob length

[Jerin Jacob]

> -Original Message-
> From: David Marchand 
> Sent: Friday, January 24, 2025 9:44 PM
> To: dev@dpdk.org
> Cc: Jerin Jacob ; Sunil Kumar Kori ;
> Tyler Retzlaff ; Thomas Monjalon
> ; Ferruh Yigit ; Andrew
> Rybchenko 
> Subject: [EXTERNAL] [PATCH 1/2] trace: support expression for blob length
> 
> Support any expression as a blob length by using an intermediate variable in
> the trace point emitter itself. This also avoids any side effect on the passed
> variable. Signed-off-by: David Marchand  ---
> lib/eal/include/rte_trace_point. h 
> Support any expression as a blob length by using an intermediate variable in
> the trace point emitter itself.
> 
> This also avoids any side effect on the passed variable.
> 
> Signed-off-by: David Marchand 

Acked-by: Jerin Jacob 

RE: [PATCH v2 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number

[Morten Brørup]

> From: Andre Muezerie [mailto:andre...@linux.microsoft.com]
> Sent: Monday, 27 January 2025 17.04
> 
> MSVC issues the warning below:
> 
> ../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<':
> result of 32-bit shift implicitly converted to 64 bits
> (was 64-bit shift intended?)
> 
> The code would be better off by using 64 bit numbers to begin with.
> That eliminates the need for a conversion to 64 bits later.
> 
> Signed-off-by: Andre Muezerie 
> Acked-by: Akhil Goyal 
> ---
>  lib/cryptodev/rte_cryptodev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/cryptodev/rte_cryptodev.c
> b/lib/cryptodev/rte_cryptodev.c
> index 85a4b46ac9..a49b0662f3 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -620,7 +620,7 @@ rte_cryptodev_asym_xform_capability_check_hash(
>  {
>   bool ret = false;
> 
> - if (capability->hash_algos & (1 << hash))
> + if (capability->hash_algos & RTE_BIT64(hash))
>   ret = true;

If I'm not mistaken, the last of the hash enums RTE_CRYPTO_AUTH_SM3_HMAC has 
the value 32, so this patch actually fixes a bug.
If you agree with my analysis, a Fixes tag should be added, so the patch can be 
backported. (RTE_CRYPTO_AUTH_SM3_HMAC also exists in previous DPDK versions.)

Furthermore, driver initializations of hash_algos should also use RTE_BIT64():
https://elixir.bootlin.com/dpdk/v24.11.1/C/ident/hash_algos
Specifically, OpenSSL and CNXK crypto drivers have the same bug, and need to be 
fixed too:
https://elixir.bootlin.com/dpdk/v24.11.1/source/drivers/crypto/openssl/rte_openssl_pmd_ops.c#L633
https://elixir.bootlin.com/dpdk/v24.11.1/source/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c#L1210

With Fixes tag added,
Reviewed-by: Morten Brørup 

RE: [PATCH v2 2/2] lib/hash: avoid implicit conversion to 64 bit number

[Morten Brørup]

> From: Andre Muezerie [mailto:andre...@linux.microsoft.com]
> Sent: Monday, 27 January 2025 17.04
> 
> MSVC issues the warnings below:
> 
> 1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<':
> result of 32-bit shift implicitly converted to 64 bits
> (was 64-bit shift intended?)
> 
> The code would be better off by using 64 bit numbers to begin with.
> That eliminates the need for a conversion to 64 bits later.
> 
> 2) ../lib/hash/rte_thash.c(568): warning C4334: '<<':
> result of 32-bit shift implicitly converted to 64 bits
> (was 64-bit shift intended?)
> 
> Instead of multiplying sizeof(uint32_t) by the result of shifting
> "1", sizeof(uint32_t) can be shifted directly.
> 
> Signed-off-by: Andre Muezerie 
> Acked-by: Vladimir Medvedkin 
> Acked-by: Bruce Richardson 
> ---

Reviewed-by: Morten Brørup 

[RFC 0/7] Introduce FreeBSD macros for SAFE iteration

[Stephen Hemminger]

This series adds common macros for safe iteration over lists.
It is a subset copy of the macros from FreeBSD that are
missing from the Linux header sys/queue.h

Chose this over several other options:
  - let each driver define their own as needed.
One Intel driver got it wrong, others will as well.
  - rename all the queue macros to RTE_XXX variants.
Seems like useless renaming and confusion.
  - Several distros have libbsd package with the correct macros.
But adding yet another dependency to DPDK would be annoying
for something this basic.

There are more macros in FreeBSD header that could be useful,
but we can add those later as needed here.

Stephen Hemminger (7):
  eal: add queue macro extensions from FreeBSD
  net/qede: fix use after free
  bus/fslmc: fix use after free
  net/bnxt: fix use after free
  net/iavf: replace local version of TAILQ_FOREACH_SAFE
  vhost: replace open coded TAILQ_FOREACH_SAFE
  raw/ifpga: use EAL version of TAILQ_FOREACH_SAFE

 drivers/bus/fslmc/portal/dpaa2_hw_dpio.c |   5 +-
 drivers/net/bnxt/bnxt_filter.c   |   8 +-
 drivers/net/iavf/iavf_vchnl.c|   8 +-
 drivers/net/qede/qede_ethdev.h   |   3 +-
 drivers/net/qede/qede_filter.c   |  13 +-
 drivers/raw/ifpga/base/opae_osdep.h  |   1 +
 lib/eal/include/meson.build  |   3 +-
 lib/eal/include/rte_queue.h  | 174 +++
 lib/vhost/socket.c   |  11 +-
 9 files changed, 193 insertions(+), 33 deletions(-)
 create mode 100644 lib/eal/include/rte_queue.h

-- 
2.45.2

Re: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

[Bruce Richardson]

On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote:
> This series adds common macros for safe iteration over lists.
> It is a subset copy of the macros from FreeBSD that are
> missing from the Linux header sys/queue.h
> 
> Chose this over several other options:
>   - let each driver define their own as needed.
> One Intel driver got it wrong, others will as well.
>   - rename all the queue macros to RTE_XXX variants.
> Seems like useless renaming and confusion.
>   - Several distros have libbsd package with the correct macros.
> But adding yet another dependency to DPDK would be annoying
> for something this basic.
> 

Actually, I wouldn't be that quick to eliminate the last option. It may
give us some additional options for simplification. For example, the
strlcpy and strlcat functions are in libbsd too, and if we had that as
mandatory dependency, perhaps we could remove some extra code there too?

/Bruce

Re: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

[Stephen Hemminger]

On Mon, 27 Jan 2025 18:16:18 +
Bruce Richardson  wrote:

> On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote:
> > This series adds common macros for safe iteration over lists.
> > It is a subset copy of the macros from FreeBSD that are
> > missing from the Linux header sys/queue.h
> > 
> > Chose this over several other options:
> >   - let each driver define their own as needed.
> > One Intel driver got it wrong, others will as well.
> >   - rename all the queue macros to RTE_XXX variants.
> > Seems like useless renaming and confusion.
> >   - Several distros have libbsd package with the correct macros.
> > But adding yet another dependency to DPDK would be annoying
> > for something this basic.
> >   
> 
> Actually, I wouldn't be that quick to eliminate the last option. It may
> give us some additional options for simplification. For example, the
> strlcpy and strlcat functions are in libbsd too, and if we had that as
> mandatory dependency, perhaps we could remove some extra code there too?
> 
> /Bruce
> 

I would be ok with using libbsd but only if we didn't have to keep a parallel
copy for all the other compiler and OS variants. And would it be global or
a per-driver dependency?

Re: [PATCH dpdk] telemetry-exporter: listen on loopback by default

[Robin Jarry]

Bruce Richardson, Jan 27, 2025 at 15:39:
> On Mon, Jan 27, 2025 at 12:51:44PM +0100, Robin Jarry wrote:
>> Fix the following warning reported by Coverity:
>> 
>> Defect type: SIGMA.insecure_network_bind:
>> > dpdk-stable-24.11.1/usertools/dpdk-telemetry-exporter.py:278:
>> > Sigma main event: The HTTP server binds to all network interfaces by
>> > setting the IP address to "", `0.0.0.0`, `::`, or `::0`.
>> > This may expose the server to unintended traffic.
>> 
>> Avoid listening to all interfaces by default to avoid exposing private
>> information unwillingly.
>> 
>> Unrelated: The Python stdlib TCP server listens on IPv4 only by default.
>> Changing this requires creating a subclass that overrides address_family
>> to socket.AF_INET6.
>> 
>> Fixes: d94ebd627a86 ("usertools: add telemetry exporter")
>> Cc: sta...@dpdk.org
>> Signed-off-by: Robin Jarry 
>> ---
>>  usertools/dpdk-telemetry-exporter.py | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/usertools/dpdk-telemetry-exporter.py 
>> b/usertools/dpdk-telemetry-exporter.py
>> index 6eca0db2e80a..6f66d4ecaab1 100755
>> --- a/usertools/dpdk-telemetry-exporter.py
>> +++ b/usertools/dpdk-telemetry-exporter.py
>> @@ -75,7 +75,7 @@ def cmd(self, uri, arg=None) -> dict | list:
>>  "/usr/local/share/dpdk/telemetry-endpoints",
>>  "/usr/share/dpdk/telemetry-endpoints",
>>  ]
>> -DEFAULT_OUTPUT = "openmetrics://:9876"
>> +DEFAULT_OUTPUT = "openmetrics://127.0.0.1:9876"
>>  
>
> Minor nit, but would it be better to use "localhost" rather than the
> hardcoded IP here and below?

That's a good point. I had considered it but as I wrote in the commit
message:

>> Unrelated: The Python stdlib TCP server listens on IPv4 only by default.
>> Changing this requires creating a subclass that overrides address_family
>> to socket.AF_INET6.

On certain systems and depending on the libc implementation, localhost
may resolve to ::1 which causes an error on startup:

  socket.gaierror: [Errno -9] Address family for hostname not supported

I dug a bit and it happens that the python standard TCPServer
implementation explicitly uses AF_INET when creating the socket. Hence
bind() fails with IPv6 addresses.

[PATCH v2 2/2] lib/hash: avoid implicit conversion to 64 bit number

[Andre Muezerie]

MSVC issues the warnings below:

1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)

The code would be better off by using 64 bit numbers to begin with.
That eliminates the need for a conversion to 64 bits later.

2) ../lib/hash/rte_thash.c(568): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)

Instead of multiplying sizeof(uint32_t) by the result of shifting
"1", sizeof(uint32_t) can be shifted directly.

Signed-off-by: Andre Muezerie 
Acked-by: Vladimir Medvedkin 
Acked-by: Bruce Richardson 
---
 lib/hash/rte_thash.c   | 2 +-
 lib/hash/rte_thash_gf2_poly_math.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c
index 336c228e64..429b895d6c 100644
--- a/lib/hash/rte_thash.c
+++ b/lib/hash/rte_thash.c
@@ -565,7 +565,7 @@ rte_thash_add_helper(struct rte_thash_ctx *ctx, const char 
*name, uint32_t len,
offset;
 
ent = rte_zmalloc(NULL, sizeof(struct rte_thash_subtuple_helper) +
-   sizeof(uint32_t) * (1 << ctx->reta_sz_log),
+   (sizeof(uint32_t) << ctx->reta_sz_log),
RTE_CACHE_LINE_SIZE);
if (ent == NULL)
return -ENOMEM;
diff --git a/lib/hash/rte_thash_gf2_poly_math.c 
b/lib/hash/rte_thash_gf2_poly_math.c
index 1c62974e71..a28f2495a5 100644
--- a/lib/hash/rte_thash_gf2_poly_math.c
+++ b/lib/hash/rte_thash_gf2_poly_math.c
@@ -118,16 +118,16 @@ static uint32_t
 gf2_mul(uint32_t a, uint32_t b, uint32_t r, int degree)
 {
uint64_t product = 0;
-   uint64_t r_poly = r|(1ULL << degree);
+   uint64_t r_poly = r | RTE_BIT64(degree);
 
for (; b; b &= (b - 1))
product ^= (uint64_t)a << (rte_bsf32(b));
 
for (int i = degree * 2 - 1; i >= degree; i--)
-   if (product & (1 << i))
+   if (product & RTE_BIT64(i))
product ^= r_poly << (i - degree);
 
-   return product;
+   return (uint32_t)product;
 }
 
 static uint32_t
-- 
2.47.2.vfs.0.1

[PATCH v2 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number

[Andre Muezerie]

MSVC issues the warning below:

../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)

The code would be better off by using 64 bit numbers to begin with.
That eliminates the need for a conversion to 64 bits later.

Signed-off-by: Andre Muezerie 
Acked-by: Akhil Goyal 
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 85a4b46ac9..a49b0662f3 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -620,7 +620,7 @@ rte_cryptodev_asym_xform_capability_check_hash(
 {
bool ret = false;
 
-   if (capability->hash_algos & (1 << hash))
+   if (capability->hash_algos & RTE_BIT64(hash))
ret = true;
 
rte_cryptodev_trace_asym_xform_capability_check_hash(
-- 
2.47.2.vfs.0.1

[PATCH] doc: reword sample application guides

[Nandini Persad]

I have revised these sections to suit the template, but also,
for punctuation, clarity, and removing repitition when necessary.

Signed-off-by: Nandini Persad 
---
 doc/guides/sample_app_ug/dist_app.rst |  24 +--
 .../sample_app_ug/eventdev_pipeline.rst   |  20 +--
 doc/guides/sample_app_ug/fips_validation.rst  | 139 +-
 doc/guides/sample_app_ug/ip_pipeline.rst  |  12 +-
 doc/guides/sample_app_ug/ipsec_secgw.rst  |  95 ++--
 doc/guides/sample_app_ug/multi_process.rst|  66 +
 doc/guides/sample_app_ug/packet_ordering.rst  |  19 ++-
 doc/guides/sample_app_ug/pipeline.rst |  10 +-
 doc/guides/sample_app_ug/ptpclient.rst|  56 +++
 doc/guides/sample_app_ug/qos_metering.rst |  11 +-
 doc/guides/sample_app_ug/qos_scheduler.rst|  10 +-
 doc/guides/sample_app_ug/service_cores.rst|  41 +++---
 doc/guides/sample_app_ug/test_pipeline.rst|   2 +-
 doc/guides/sample_app_ug/timer.rst|  13 +-
 doc/guides/sample_app_ug/vdpa.rst |  39 ++---
 doc/guides/sample_app_ug/vhost.rst|  51 ---
 doc/guides/sample_app_ug/vhost_blk.rst|  21 +--
 doc/guides/sample_app_ug/vhost_crypto.rst |  15 +-
 .../sample_app_ug/vm_power_management.rst | 138 -
 .../sample_app_ug/vmdq_dcb_forwarding.rst |  77 +-
 doc/guides/sample_app_ug/vmdq_forwarding.rst  |  28 ++--
 21 files changed, 456 insertions(+), 431 deletions(-)

diff --git a/doc/guides/sample_app_ug/dist_app.rst 
b/doc/guides/sample_app_ug/dist_app.rst
index 5c80561187..7a841bff8a 100644
--- a/doc/guides/sample_app_ug/dist_app.rst
+++ b/doc/guides/sample_app_ug/dist_app.rst
@@ -4,7 +4,7 @@
 Distributor Sample Application
 ==
 
-The distributor sample application is a simple example of packet distribution
+The distributor sample application is an example of packet distribution
 to cores using the Data Plane Development Kit (DPDK). It also makes use of
 Intel Speed Select Technology - Base Frequency (Intel SST-BF) to pin the
 distributor to the higher frequency core if available.
@@ -31,7 +31,7 @@ generator as shown in the figure below.
 Compiling the Application
 -
 
-To compile the sample application see :doc:`compiling`.
+To compile the sample application, see :doc:`compiling`.
 
 The application is located in the ``distributor`` sub-directory.
 
@@ -66,7 +66,7 @@ The distributor application consists of four types of 
threads: a receive
 thread (``lcore_rx()``), a distributor thread (``lcore_dist()``), a set of
 worker threads (``lcore_worker()``), and a transmit thread(``lcore_tx()``).
 How these threads work together is shown in :numref:`figure_dist_app` below.
-The ``main()`` function launches  threads of these four types.  Each thread
+The ``main()`` function launches threads of these four types. Each thread
 has a while loop which will be doing processing and which is terminated
 only upon SIGINT or ctrl+C.
 
@@ -86,7 +86,7 @@ the distributor, doing a simple XOR operation on the input 
port mbuf field
 (to indicate the output port which will be used later for packet transmission)
 and then finally returning the packets back to the distributor thread.
 
-The distributor thread will then call the distributor api
+The distributor thread will then call the distributor API
 ``rte_distributor_returned_pkts()`` to get the processed packets, and will 
enqueue
 them to another rte_ring for transfer to the TX thread for transmission on the
 output port. The transmit thread will dequeue the packets from the ring and
@@ -105,7 +105,7 @@ final statistics to the user.
 
 
 Intel SST-BF Support
-
+
 
 In DPDK 19.05, support was added to the power management library for
 Intel-SST-BF, a technology that allows some cores to run at a higher
@@ -114,20 +114,20 @@ and is entitled
 `Intel Speed Select Technology – Base Frequency - Enhancing Performance 
`_
 
 The distributor application was also enhanced to be aware of these higher
-frequency SST-BF cores, and when starting the application, if high frequency
+frequency SST-BF cores. When starting the application, if high frequency
 SST-BF cores are present in the core mask, the application will identify these
 cores and pin the workloads appropriately. The distributor core is usually
 the bottleneck, so this is given first choice of the high frequency SST-BF
-cores, followed by the rx core and the tx core.
+cores, followed by the Rx core and the Tx core.
 
 Debug Logging Support
--
+~
 
 Debug logging is provided as part of the application; the user needs to 
uncomment
 the line "#define DEBUG" defined in start of the application in main.c to 
enable debug logs.
 
 Statistics
---
+~~
 
 The main function will print stat

Re: [PATCH v1 0/2] Update Base code for TXPP Implementation

[Bruce Richardson]

On Fri, Jan 17, 2025 at 09:39:36AM +, Soumyadeep Hore wrote:
> Updating Base Code for TXPP Feature Implementation.
> 
> Paul Greenwalt (2):
>   net/ice: add tstamp descriptor
>   net/ice: add Tx Time queue context configuration support
> 
>  drivers/net/ice/base/ice_adminq_cmd.h | 55 +++
>  drivers/net/ice/base/ice_common.c | 96 +++
>  drivers/net/ice/base/ice_common.h |  9 +++
>  drivers/net/ice/base/ice_lan_tx_rx.h  | 43 
>  4 files changed, 203 insertions(+)
> 
Series-acked-by: Bruce Richardson 

Applied to dpdk-next-net-intel.

Thanks,
/Bruce

RE: [PATCH v3] mbuf: add fast free bulk and raw alloc bulk functions

[Konstantin Ananyev]

> When putting an mbuf back into its mempool, there are certain requirements
> to the mbuf. Specifically, some of its fields must be initialized.
> 
> These requirements are in fact invariants about free mbufs, held in
> mempools, and thus also apply when allocating an mbuf from a mempool.
> With this in mind, the additional assertions in rte_mbuf_raw_free() were
> moved to __rte_mbuf_raw_sanity_check().
> Furthermore, the assertion regarding pinned external buffer was enhanced;
> it now also asserts that the referenced pinned external buffer has
> refcnt == 1.
> 
> The description of RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE was updated to
> include the remaining requirements, which were missing here.
> 
> And finally:
> A new rte_mbuf_fast_free_bulk() inline function was added for the benefit
> of ethdev drivers supporting fast release of mbufs.
> It asserts these requirements and that the mbufs belong to the specified
> mempool, and then calls rte_mempool_put_bulk().
> 
> For symmetry, a new rte_mbuf_raw_alloc_bulk() inline function was also
> added.
> 
> Signed-off-by: Morten Brørup 
> Acked-by: Dengdui Huang 
> ---
> v2:
> * Fixed missing inline.
> v3:
> * Fixed missing experimental warning. (Stephen)
> * Added raw alloc bulk function.
> ---
>  lib/ethdev/rte_ethdev.h |  6 ++--
>  lib/mbuf/rte_mbuf.h | 80 +++--
>  2 files changed, 82 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 1f71cad244..e9267fca79 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1612,8 +1612,10 @@ struct rte_eth_conf {
>  #define RTE_ETH_TX_OFFLOAD_MULTI_SEGS   RTE_BIT64(15)
>  /**
>   * Device supports optimization for fast release of mbufs.
> - * When set application must guarantee that per-queue all mbufs comes from
> - * the same mempool and has refcnt = 1.
> + * When set application must guarantee that per-queue all mbufs come from 
> the same mempool,
> + * are direct, have refcnt=1, next=NULL and nb_segs=1, as done by 
> rte_pktmbuf_prefree_seg().
> + *
> + * @see rte_mbuf_fast_free_bulk()
>   */
>  #define RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE   RTE_BIT64(16)
>  #define RTE_ETH_TX_OFFLOAD_SECURITY RTE_BIT64(17)
> diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> index 0d2e0e64b3..1e40e7fcf7 100644
> --- a/lib/mbuf/rte_mbuf.h
> +++ b/lib/mbuf/rte_mbuf.h
> @@ -568,6 +568,10 @@ __rte_mbuf_raw_sanity_check(__rte_unused const struct 
> rte_mbuf *m)
>   RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
>   RTE_ASSERT(m->next == NULL);
>   RTE_ASSERT(m->nb_segs == 1);
> + RTE_ASSERT(!RTE_MBUF_CLONED(m));
> + RTE_ASSERT(!RTE_MBUF_HAS_EXTBUF(m) ||
> + (RTE_MBUF_HAS_PINNED_EXTBUF(m) &&
> + rte_mbuf_ext_refcnt_read(m->shinfo) == 1));
>   __rte_mbuf_sanity_check(m, 0);
>  }
> 
> @@ -606,6 +610,43 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct 
> rte_mempool *mp)
>   return ret.m;
>  }
> 
> +/**
> + * @warning
> + * @b EXPERIMENTAL: This API may change, or be removed, without prior notice.
> + *
> + * Allocate a bulk of uninitialized mbufs from mempool *mp*.
> + *
> + * This function can be used by PMDs (especially in RX functions) to
> + * allocate a bulk of uninitialized mbufs. The driver is responsible of
> + * initializing all the required fields. See rte_pktmbuf_reset().
> + * For standard needs, prefer rte_pktmbuf_alloc_bulk().
> + *
> + * The caller can expect that the following fields of the mbuf structure
> + * are initialized: buf_addr, buf_iova, buf_len, refcnt=1, nb_segs=1,
> + * next=NULL, pool, priv_size. The other fields must be initialized
> + * by the caller.
> + *
> + * @param mp
> + *   The mempool from which mbufs are allocated.
> + * @param mbufs
> + *   Array of pointers to mbufs.
> + * @param count
> + *   Array size.
> + * @return
> + *   - 0: Success.
> + *   - -ENOENT: Not enough entries in the mempool; no mbufs are retrieved.
> + */
> +__rte_experimental
> +static __rte_always_inline int
> +rte_mbuf_raw_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf **mbufs, 
> unsigned int count)
> +{
> + int rc = rte_mempool_get_bulk(mp, (void **)mbufs, count);
> + if (likely(rc == 0))
> + for (unsigned int idx = 0; idx < count; idx++)
> + __rte_mbuf_raw_sanity_check(mbufs[idx]);
> + return rc;
> +}
> +
>  /**
>   * Put mbuf back into its original mempool.
>   *
> @@ -623,12 +664,47 @@ static inline struct rte_mbuf 
> *rte_mbuf_raw_alloc(struct rte_mempool *mp)
>  static __rte_always_inline void
>  rte_mbuf_raw_free(struct rte_mbuf *m)
>  {
> - RTE_ASSERT(!RTE_MBUF_CLONED(m) &&
> -   (!RTE_MBUF_HAS_EXTBUF(m) || RTE_MBUF_HAS_PINNED_EXTBUF(m)));
>   __rte_mbuf_raw_sanity_check(m);
>   rte_mempool_put(m->pool, m);
>  }
> 
> +/**
> + * @warning
> + * @b EXPERIMENTAL: This API may change, or be removed, without prior notice.
> + *
> + * Put a bulk of mb

[RFC 7/7] raw/ifpga: use EAL version of TAILQ_FOREACH_SAFE

[Stephen Hemminger]

Prefer the EAL version over local version of macro.

Signed-off-by: Stephen Hemminger 
---
 drivers/raw/ifpga/base/opae_osdep.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/raw/ifpga/base/opae_osdep.h 
b/drivers/raw/ifpga/base/opae_osdep.h
index e35a21c80e..b483d00a54 100644
--- a/drivers/raw/ifpga/base/opae_osdep.h
+++ b/drivers/raw/ifpga/base/opae_osdep.h
@@ -11,6 +11,7 @@
 
 #ifdef RTE_LIB_EAL
 #include "osdep_rte/osdep_generic.h"
+#include 
 #else
 #include "osdep_raw/osdep_generic.h"
 #endif
-- 
2.45.2

[RFC 1/7] eal: add queue macro extensions from FreeBSD

[Stephen Hemminger]

The Linux version of sys/queue.h is frozen at an older version
and is missing the _SAFE macro variants. Several drivers started
introducing the own workarounds for this. Should be handled in EAL.

Signed-off-by: Stephen Hemminger 
---
 lib/eal/include/meson.build |   3 +-
 lib/eal/include/rte_queue.h | 174 
 2 files changed, 176 insertions(+), 1 deletion(-)
 create mode 100644 lib/eal/include/rte_queue.h

diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
index d903577caa..75bf09381f 100644
--- a/lib/eal/include/meson.build
+++ b/lib/eal/include/meson.build
@@ -19,8 +19,8 @@ headers += files(
 'rte_eal.h',
 'rte_eal_memconfig.h',
 'rte_eal_trace.h',
-'rte_errno.h',
 'rte_epoll.h',
+'rte_errno.h',
 'rte_fbarray.h',
 'rte_hexdump.h',
 'rte_hypervisor.h',
@@ -38,6 +38,7 @@ headers += files(
 'rte_pci_dev_features.h',
 'rte_per_lcore.h',
 'rte_pflock.h',
+'rte_queue.h',
 'rte_random.h',
 'rte_reciprocal.h',
 'rte_seqcount.h',
diff --git a/lib/eal/include/rte_queue.h b/lib/eal/include/rte_queue.h
new file mode 100644
index 00..7ec807b15d
--- /dev/null
+++ b/lib/eal/include/rte_queue.h
@@ -0,0 +1,174 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Original Copyright (c) 1991, 1993
+ * The Regents of the University of California.  All rights reserved.
+ */
+
+#ifndef _RTE_QUEUE_H_
+#define _RTE_QUEUE_H_
+
+/**
+ * @file
+ *  Defines macro's that exist in the FreeBSD version of queue.h
+ *  which are missing in other versions.
+ */
+
+#include 
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * Below is a summary of implemented functions where:
+ *  o  means the macro exists in original version
+ *  +  means the macro is added here
+ *  -  means the macro is not available
+ *  s  means the macro is available but is slow (runs in O(n) time)
+ *
+ * SLIST   LISTSTAILQ  TAILQ
+ * _HEAD   o   o   o   o
+ * _HEAD_INITIALIZER   o   o   o   o
+ * _ENTRY  o   o   o   o
+ * _INIT   o   o   o   o
+ * _EMPTY  o   o   o   o
+ * _FIRST  o   o   o   o
+ * _NEXT   o   o   o   o
+ * _FOREACHo   o   o   o
+ * _FOREACH_FROM   +   +   +   +
+ * _FOREACH_SAFE   +   +   +   +
+ * _FOREACH_FROM_SAFE  +   +   +   +
+ * _FOREACH_REVERSE-   -   -   o
+ * _FOREACH_REVERSE_FROM   -   -   -   +
+ * _FOREACH_REVERSE_SAFE   -   -   -   +
+ * _FOREACH_REVERSE_FROM_SAFE  -   -   -   +
+ * _INSERT_HEADo   o   o   o
+ * _INSERT_BEFORE  -   o   -   o
+ * _INSERT_AFTER   o   o   o   o
+ * _INSERT_TAIL-   -   o   o
+ * _CONCAT s   s   o   o
+ * _REMOVE_AFTER   o   -   o   -
+ * _REMOVE_HEADo   o   o   o
+ * _REMOVE s   o   s   o
+ *
+ */
+
+
+/*
+ * Singly-linked List declarations.
+ */
+#ifndef SLIST_FOREACH_FROM
+#defineSLIST_FOREACH_FROM(var, head, field)
\
+   for ((var) = ((var) ? (var) : SLIST_FIRST((head))); \
+   (var);  \
+   (var) = SLIST_NEXT((var), field))
+#endif
+
+#ifndef SLIST_FOREACH_SAFE
+#defineSLIST_FOREACH_SAFE(var, head, field, tvar)  
\
+   for ((var) = SLIST_FIRST((head));   \
+   (var) && ((tvar) = SLIST_NEXT((var), field), 1);\
+   (var) = (tvar))
+#endif
+
+#ifndef SLIST_FOREACH_FROM_SAFE
+#defineSLIST_FOREACH_FROM_SAFE(var, head, field, tvar) 
\
+   for ((var) = ((var) ? (var) : SLIST_FIRST((head))); \
+   (var) && ((tvar) = SLIST_NEXT((var), field), 1);\
+   (var) = (tvar))
+#endif
+
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#ifndef STAILQ_FOREACH_FROM
+#defineSTAILQ_FOREACH_FROM(var, head, field)   
\
+   for ((var) = ((var) ? (var) : STAILQ_FIRST((head)));\
+  (var);   \
+  (var) = STAILQ_NEXT((var), field))
+#endif
+
+#ifndef STAILQ_FOREACH_SAFE
+#defineSTAILQ_FOREACH_SAFE(var, head, field, tvar) 
\
+   for ((var) = STAILQ_FIRST((head));

[RFC 2/7] net/qede: fix use after free

[Stephen Hemminger]

The loop cleaning up flowdir resources was using SLIST_FOREACH
but the inner loop would call rte_free. Found by building with
address sanitizer undefined check.

Also remove needless initialization, and null check.

Fixes: f5765f66f9bb ("net/qede: refactor flow director into generic aRFS")
Cc: shahed.sha...@cavium.com
Cc: sta...@dpdk.org

Signed-off-by: Stephen Hemminger 
---
 drivers/net/qede/qede_ethdev.h |  3 +--
 drivers/net/qede/qede_filter.c | 13 +
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/net/qede/qede_ethdev.h b/drivers/net/qede/qede_ethdev.h
index 3015c18504..b502658425 100644
--- a/drivers/net/qede/qede_ethdev.h
+++ b/drivers/net/qede/qede_ethdev.h
@@ -8,8 +8,7 @@
 #ifndef _QEDE_ETHDEV_H_
 #define _QEDE_ETHDEV_H_
 
-#include 
-
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/qede/qede_filter.c b/drivers/net/qede/qede_filter.c
index 14fb4338e9..c3f74c89d9 100644
--- a/drivers/net/qede/qede_filter.c
+++ b/drivers/net/qede/qede_filter.c
@@ -154,15 +154,12 @@ int qede_check_fdir_support(struct rte_eth_dev *eth_dev)
 void qede_fdir_dealloc_resc(struct rte_eth_dev *eth_dev)
 {
struct qede_dev *qdev = QEDE_INIT_QDEV(eth_dev);
-   struct qede_arfs_entry *tmp = NULL;
+   struct qede_arfs_entry *tmp, *tmp2;
 
-   SLIST_FOREACH(tmp, &qdev->arfs_info.arfs_list_head, list) {
-   if (tmp) {
-   rte_memzone_free(tmp->mz);
-   SLIST_REMOVE(&qdev->arfs_info.arfs_list_head, tmp,
-qede_arfs_entry, list);
-   rte_free(tmp);
-   }
+   SLIST_FOREACH_SAFE(tmp, &qdev->arfs_info.arfs_list_head, list, tmp2) {
+   rte_memzone_free(tmp->mz);
+   SLIST_REMOVE(&qdev->arfs_info.arfs_list_head, tmp, 
qede_arfs_entry, list);
+   rte_free(tmp);
}
 }
 
-- 
2.45.2

[RFC 5/7] net/iavf: replace local version of TAILQ_FOREACH_SAFE

[Stephen Hemminger]

Now in EAL as rte_queue.h

Signed-off-by: Stephen Hemminger 
---
 drivers/net/iavf/iavf_vchnl.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 065ab3594c..c9684ae189 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -52,13 +53,6 @@ static struct iavf_event_handler event_handler = {
.fd = {-1, -1},
 };
 
-#ifndef TAILQ_FOREACH_SAFE
-#define TAILQ_FOREACH_SAFE(var, head, field, tvar) \
-   for ((var) = TAILQ_FIRST((head)); \
-   (var) && ((tvar) = TAILQ_NEXT((var), field), 1); \
-   (var) = (tvar))
-#endif
-
 static uint32_t
 iavf_dev_event_handle(void *param __rte_unused)
 {
-- 
2.45.2

[RFC 3/7] bus/fslmc: fix use after free

[Stephen Hemminger]

The cleanup loop would deference the dpio_dev after freeing.
Use TAILQ_FOREACH_SAFE to fix that.
Found by building with sanitizer undefined flag.

Fixes: e55d0494ab98 ("bus/fslmc: support secondary process")
Cc: shreyansh.j...@nxp.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger 
---
 drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c 
b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
index 2dfcf7a498..6ae15c2054 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -27,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -403,6 +403,7 @@ dpaa2_create_dpio_device(int vdev_fd,
struct rte_dpaa2_device *obj)
 {
struct dpaa2_dpio_dev *dpio_dev = NULL;
+   struct dpaa2_dpio_dev *dpio_tmp;
struct vfio_region_info reg_info = { .argsz = sizeof(reg_info)};
struct qbman_swp_desc p_des;
struct dpio_attr attr;
@@ -588,7 +589,7 @@ dpaa2_create_dpio_device(int vdev_fd,
rte_free(dpio_dev);
 
/* For each element in the list, cleanup */
-   TAILQ_FOREACH(dpio_dev, &dpio_dev_list, next) {
+   TAILQ_FOREACH_SAFE(dpio_dev, &dpio_dev_list, next, dpio_tmp) {
if (dpio_dev->dpio) {
dpio_disable(dpio_dev->dpio, CMD_PRI_LOW,
dpio_dev->token);
-- 
2.45.2

[RFC 6/7] vhost: replace open coded TAILQ_FOREACH_SAFE

[Stephen Hemminger]

Proper macro is now in EAL rte_queue.h use it instead.

Signed-off-by: Stephen Hemminger 
---
 lib/vhost/socket.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c
index 05a7e5902f..625ed08b7c 100644
--- a/lib/vhost/socket.c
+++ b/lib/vhost/socket.c
@@ -10,10 +10,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -458,14 +458,7 @@ vhost_user_client_reconnect(void *arg __rte_unused)
while (1) {
pthread_mutex_lock(&reconn_list.mutex);
 
-   /*
-* An equal implementation of TAILQ_FOREACH_SAFE,
-* which does not exist on all platforms.
-*/
-   for (reconn = TAILQ_FIRST(&reconn_list.head);
-reconn != NULL; reconn = next) {
-   next = TAILQ_NEXT(reconn, next);
-
+   TAILQ_FOREACH_SAFE(reconn, &reconn_list.head, next, next) {
ret = 
vhost_user_connect_nonblock(reconn->vsocket->path, reconn->fd,
(struct sockaddr *)&reconn->un,
sizeof(reconn->un));
-- 
2.45.2

[RFC 4/7] net/bnxt: fix use after free

[Stephen Hemminger]

The filter cleanup loop was using STAILQ_FOREACH and rte_free
and would dereference the filter after free.

Found by build with -Dbsanitize=address,undefined

Fixes: e8fe0e067b68 ("net/bnxt: fix allocation of PF info struct")
Cc: ajit.khapa...@broadcom.com
Cc: sta...@dpdk.org

Signed-off-by: Stephen Hemminger 
---
 drivers/net/bnxt/bnxt_filter.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/bnxt/bnxt_filter.c b/drivers/net/bnxt/bnxt_filter.c
index 7b90ba651f..f083f3aa94 100644
--- a/drivers/net/bnxt/bnxt_filter.c
+++ b/drivers/net/bnxt/bnxt_filter.c
@@ -3,14 +3,12 @@
  * All rights reserved.
  */
 
-#include 
-
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "bnxt.h"
 #include "bnxt_filter.h"
@@ -151,7 +149,9 @@ void bnxt_free_filter_mem(struct bnxt *bp)
bp->filter_info = NULL;
 
for (i = 0; i < bp->pf->max_vfs; i++) {
-   STAILQ_FOREACH(filter, &bp->pf->vf_info[i].filter, next) {
+   struct bnxt_filter_info *tmp;
+
+   STAILQ_FOREACH_SAFE(filter, &bp->pf->vf_info[i].filter, next, 
tmp) {
rte_free(filter);
STAILQ_REMOVE(&bp->pf->vf_info[i].filter, filter,
  bnxt_filter_info, next);
-- 
2.45.2

Re: [RFC 4/7] net/bnxt: fix use after free

[Ajit Khaparde]

On Mon, Jan 27, 2025 at 10:08 AM Stephen Hemminger
 wrote:
>
> The filter cleanup loop was using STAILQ_FOREACH and rte_free
> and would dereference the filter after free.
>
> Found by build with -Dbsanitize=address,undefined
>
> Fixes: e8fe0e067b68 ("net/bnxt: fix allocation of PF info struct")
> Cc: ajit.khapa...@broadcom.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Stephen Hemminger 
Acked-by: Ajit Khaparde 
> ---
>  drivers/net/bnxt/bnxt_filter.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_filter.c b/drivers/net/bnxt/bnxt_filter.c
> index 7b90ba651f..f083f3aa94 100644
> --- a/drivers/net/bnxt/bnxt_filter.c
> +++ b/drivers/net/bnxt/bnxt_filter.c
> @@ -3,14 +3,12 @@
>   * All rights reserved.
>   */
>
> -#include 
> -
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "bnxt.h"
>  #include "bnxt_filter.h"
> @@ -151,7 +149,9 @@ void bnxt_free_filter_mem(struct bnxt *bp)
> bp->filter_info = NULL;
>
> for (i = 0; i < bp->pf->max_vfs; i++) {
> -   STAILQ_FOREACH(filter, &bp->pf->vf_info[i].filter, next) {
> +   struct bnxt_filter_info *tmp;
> +
> +   STAILQ_FOREACH_SAFE(filter, &bp->pf->vf_info[i].filter, next, 
> tmp) {
> rte_free(filter);
> STAILQ_REMOVE(&bp->pf->vf_info[i].filter, filter,
>   bnxt_filter_info, next);
> --
> 2.45.2
>


smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH v3 1/3] lib/cryptodev: avoid implicit conversion to 64 bit number

[Andre Muezerie]

MSVC issues the warning below:

../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)

The code would be better off by using 64 bit numbers to begin with.
That eliminates the need for a conversion to 64 bits later.

This patch actually fixes a bug present in previous DPDK versions
because the last of the hash enums RTE_CRYPTO_AUTH_SM3_HMAC in
rte_crypto_auth_algorithm has value 32.

Fixes: 6f8ef8b68edb ("cryptodev: add hash algorithms in asymmetric capability")
Cc: sta...@dpdk.org

Signed-off-by: Andre Muezerie 
Acked-by: Akhil Goyal 
Reviewed-by: Morten Brørup 
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 85a4b46ac9..a49b0662f3 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -620,7 +620,7 @@ rte_cryptodev_asym_xform_capability_check_hash(
 {
bool ret = false;
 
-   if (capability->hash_algos & (1 << hash))
+   if (capability->hash_algos & RTE_BIT64(hash))
ret = true;
 
rte_cryptodev_trace_asym_xform_capability_check_hash(
-- 
2.47.2.vfs.0.1

[PATCH v3 3/3] drivers/crypto: use RTE_BIT64 in initializations of hash_algos

[Andre Muezerie]

This was found during code review of similar issues.

Signed-off-by: Andre Muezerie 
---
 drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c | 4 ++--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c 
b/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
index 4394513002..e78bc37c37 100644
--- a/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
+++ b/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
@@ -1207,8 +1207,8 @@ static const struct rte_cryptodev_capabilities 
caps_eddsa[] = {
{.asym = {
.xform_capa = {
.xform_type = RTE_CRYPTO_ASYM_XFORM_EDDSA,
-   .hash_algos = (1 << RTE_CRYPTO_AUTH_SHA512 |
-  1 << RTE_CRYPTO_AUTH_SHAKE_256),
+   .hash_algos = 
(RTE_BIT64(RTE_CRYPTO_AUTH_SHA512) |
+  
RTE_BIT64(RTE_CRYPTO_AUTH_SHAKE_256)),
.op_types = ((1 << RTE_CRYPTO_ASYM_OP_SIGN) |
 (1 << RTE_CRYPTO_ASYM_OP_VERIFY))
}
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c 
b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 18f096abfd..04e018f3df 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -630,8 +630,8 @@ static const struct rte_cryptodev_capabilities 
openssl_pmd_capabilities[] = {
{.asym = {
.xform_capa = {
.xform_type = RTE_CRYPTO_ASYM_XFORM_EDDSA,
-   .hash_algos = (1 << RTE_CRYPTO_AUTH_SHA512 |
-  1 << RTE_CRYPTO_AUTH_SHAKE_256),
+   .hash_algos = 
(RTE_BIT64(RTE_CRYPTO_AUTH_SHA512) |
+  
RTE_BIT64(RTE_CRYPTO_AUTH_SHAKE_256)),
.op_types =
((1<

[PATCH v3 2/3] lib/hash: avoid implicit conversion to 64 bit number

[Andre Muezerie]

MSVC issues the warnings below:

1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)

The code would be better off by using 64 bit numbers to begin with.
That eliminates the need for a conversion to 64 bits later.

2) ../lib/hash/rte_thash.c(568): warning C4334: '<<':
result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)

Instead of multiplying sizeof(uint32_t) by the result of shifting
"1", sizeof(uint32_t) can be shifted directly.

Signed-off-by: Andre Muezerie 
Acked-by: Vladimir Medvedkin 
Acked-by: Bruce Richardson 
Reviewed-by: Morten Brørup 
---
 lib/hash/rte_thash.c   | 2 +-
 lib/hash/rte_thash_gf2_poly_math.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c
index 336c228e64..429b895d6c 100644
--- a/lib/hash/rte_thash.c
+++ b/lib/hash/rte_thash.c
@@ -565,7 +565,7 @@ rte_thash_add_helper(struct rte_thash_ctx *ctx, const char 
*name, uint32_t len,
offset;
 
ent = rte_zmalloc(NULL, sizeof(struct rte_thash_subtuple_helper) +
-   sizeof(uint32_t) * (1 << ctx->reta_sz_log),
+   (sizeof(uint32_t) << ctx->reta_sz_log),
RTE_CACHE_LINE_SIZE);
if (ent == NULL)
return -ENOMEM;
diff --git a/lib/hash/rte_thash_gf2_poly_math.c 
b/lib/hash/rte_thash_gf2_poly_math.c
index 1c62974e71..a28f2495a5 100644
--- a/lib/hash/rte_thash_gf2_poly_math.c
+++ b/lib/hash/rte_thash_gf2_poly_math.c
@@ -118,16 +118,16 @@ static uint32_t
 gf2_mul(uint32_t a, uint32_t b, uint32_t r, int degree)
 {
uint64_t product = 0;
-   uint64_t r_poly = r|(1ULL << degree);
+   uint64_t r_poly = r | RTE_BIT64(degree);
 
for (; b; b &= (b - 1))
product ^= (uint64_t)a << (rte_bsf32(b));
 
for (int i = degree * 2 - 1; i >= degree; i--)
-   if (product & (1 << i))
+   if (product & RTE_BIT64(i))
product ^= r_poly << (i - degree);
 
-   return product;
+   return (uint32_t)product;
 }
 
 static uint32_t
-- 
2.47.2.vfs.0.1

Re: [PATCH v2 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number

[Andre Muezerie]

On Mon, Jan 27, 2025 at 06:14:47PM +0100, Morten Brørup wrote:
> > From: Andre Muezerie [mailto:andre...@linux.microsoft.com]
> > Sent: Monday, 27 January 2025 17.04
> > 
> > MSVC issues the warning below:
> > 
> > ../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<':
> > result of 32-bit shift implicitly converted to 64 bits
> > (was 64-bit shift intended?)
> > 
> > The code would be better off by using 64 bit numbers to begin with.
> > That eliminates the need for a conversion to 64 bits later.
> > 
> > Signed-off-by: Andre Muezerie 
> > Acked-by: Akhil Goyal 
> > ---
> >  lib/cryptodev/rte_cryptodev.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/cryptodev/rte_cryptodev.c
> > b/lib/cryptodev/rte_cryptodev.c
> > index 85a4b46ac9..a49b0662f3 100644
> > --- a/lib/cryptodev/rte_cryptodev.c
> > +++ b/lib/cryptodev/rte_cryptodev.c
> > @@ -620,7 +620,7 @@ rte_cryptodev_asym_xform_capability_check_hash(
> >  {
> > bool ret = false;
> > 
> > -   if (capability->hash_algos & (1 << hash))
> > +   if (capability->hash_algos & RTE_BIT64(hash))
> > ret = true;
> 
> If I'm not mistaken, the last of the hash enums RTE_CRYPTO_AUTH_SM3_HMAC has 
> the value 32, so this patch actually fixes a bug.
> If you agree with my analysis, a Fixes tag should be added, so the patch can 
> be backported. (RTE_CRYPTO_AUTH_SM3_HMAC also exists in previous DPDK 
> versions.)
> 
> Furthermore, driver initializations of hash_algos should also use RTE_BIT64():
> https://elixir.bootlin.com/dpdk/v24.11.1/C/ident/hash_algos
> Specifically, OpenSSL and CNXK crypto drivers have the same bug, and need to 
> be fixed too:
> https://elixir.bootlin.com/dpdk/v24.11.1/source/drivers/crypto/openssl/rte_openssl_pmd_ops.c#L633
> https://elixir.bootlin.com/dpdk/v24.11.1/source/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c#L1210
> 
> With Fixes tag added,
> Reviewed-by: Morten Brørup 

Great observation. I agree that this is indeed fixing a bug.
I also fixed the two drivers as suggested and sent out v3 of this series.

RE: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

[Morten Brørup]

> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, 27 January 2025 19.44
> 
> On Mon, 27 Jan 2025 18:16:18 +
> Bruce Richardson  wrote:
> 
> > On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote:
> > > This series adds common macros for safe iteration over lists.
> > > It is a subset copy of the macros from FreeBSD that are
> > > missing from the Linux header sys/queue.h
> > >
> > > Chose this over several other options:
> > >   - let each driver define their own as needed.
> > > One Intel driver got it wrong, others will as well.
> > >   - rename all the queue macros to RTE_XXX variants.
> > > Seems like useless renaming and confusion.
> > >   - Several distros have libbsd package with the correct macros.
> > > But adding yet another dependency to DPDK would be annoying
> > > for something this basic.
> > >
> >
> > Actually, I wouldn't be that quick to eliminate the last option. It
> may
> > give us some additional options for simplification. For example, the
> > strlcpy and strlcat functions are in libbsd too, and if we had that
> as
> > mandatory dependency, perhaps we could remove some extra code there
> too?
> >
> > /Bruce
> >
> 
> I would be ok with using libbsd but only if we didn't have to keep a
> parallel
> copy for all the other compiler and OS variants. And would it be global
> or
> a per-driver dependency?

+1 to providing our own implementations of relevant libbsd features in the DPDK 
EAL, rather than depending on the entire libbsd (and libbsd-dev for 
development). Providing these features as part of a "utilities library" (which 
is currently integrated into the EAL) is better for non-Unix environments.

Furthermore, libbsd has plenty of stuff we don't need:
https://manpages.debian.org/testing/libbsd-dev/index.html

Re: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

[Stephen Hemminger]

On Mon, 27 Jan 2025 20:29:55 +0100
Morten Brørup  wrote:

> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Monday, 27 January 2025 19.44
> > 
> > On Mon, 27 Jan 2025 18:16:18 +
> > Bruce Richardson  wrote:
> >   
> > > On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote:  
> > > > This series adds common macros for safe iteration over lists.
> > > > It is a subset copy of the macros from FreeBSD that are
> > > > missing from the Linux header sys/queue.h
> > > >
> > > > Chose this over several other options:
> > > >   - let each driver define their own as needed.
> > > > One Intel driver got it wrong, others will as well.
> > > >   - rename all the queue macros to RTE_XXX variants.
> > > > Seems like useless renaming and confusion.
> > > >   - Several distros have libbsd package with the correct macros.
> > > > But adding yet another dependency to DPDK would be annoying
> > > > for something this basic.
> > > >  
> > >
> > > Actually, I wouldn't be that quick to eliminate the last option. It  
> > may  
> > > give us some additional options for simplification. For example, the
> > > strlcpy and strlcat functions are in libbsd too, and if we had that  
> > as  
> > > mandatory dependency, perhaps we could remove some extra code there  
> > too?  
> > >
> > > /Bruce
> > >  
> > 
> > I would be ok with using libbsd but only if we didn't have to keep a
> > parallel
> > copy for all the other compiler and OS variants. And would it be global
> > or
> > a per-driver dependency?  
> 
> +1 to providing our own implementations of relevant libbsd features in the 
> DPDK EAL, rather than depending on the entire libbsd (and libbsd-dev for 
> development). Providing these features as part of a "utilities library" 
> (which is currently integrated into the EAL) is better for non-Unix 
> environments.
> 
> Furthermore, libbsd has plenty of stuff we don't need:
> https://manpages.debian.org/testing/libbsd-dev/index.html

The red-black tries in libbsd are very useful. In one product we used it as a 
way
to manage LPM rules, since the current DPDK model is O(N^2) and works terribly 
in
a router with 3M routes.

[PATCH 2/4] net/netvsc: remove RTE device if all its net devices are removed

[longli]

From: Long Li 

An RTE device can have multiple Ethernet devices. On hot plug events, it
can't be removed until all its Ethernet devices have been removed.

Fixes: a2a23a794b3a ("net/netvsc: support VF device hot add/remove")
Cc: sta...@dpdk.org
Signed-off-by: Long Li 
---
 drivers/net/netvsc/hn_vf.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/netvsc/hn_vf.c b/drivers/net/netvsc/hn_vf.c
index b664beaa5d..5d8058774d 100644
--- a/drivers/net/netvsc/hn_vf.c
+++ b/drivers/net/netvsc/hn_vf.c
@@ -102,6 +102,7 @@ static void hn_remove_delayed(void *args)
uint16_t port_id = hv->vf_ctx.vf_port;
struct rte_device *dev = rte_eth_devices[port_id].device;
int ret;
+   bool all_eth_removed;
 
/* Tell VSP to switch data path to synthetic */
hn_vf_remove(hv);
@@ -138,7 +139,17 @@ static void hn_remove_delayed(void *args)
PMD_DRV_LOG(ERR, "rte_eth_dev_close failed port_id=%u ret=%d",
port_id, ret);
 
-   ret = rte_dev_remove(dev);
+   /* Remove the rte device when all its eth devices are removed */
+   all_eth_removed = true;
+   RTE_ETH_FOREACH_DEV_OF(port_id, dev) {
+   if (rte_eth_devices[port_id].state != RTE_ETH_DEV_UNUSED) {
+   all_eth_removed = false;
+   break;
+   }
+   }
+   if (all_eth_removed)
+   ret = rte_dev_remove(dev);
+
hv->vf_ctx.vf_state = vf_removed;
 
rte_rwlock_write_unlock(&hv->vf_lock);
-- 
2.34.1

[PATCH 4/4] net/netvsc: cache device parameters for hot plug events

[longli]

From: Long Li 

If a device is hot removed and hot plugged, it needs the same driver
parameters that are passed to EAL. However, during device removal, all
EAL driver parameters are freed as part of the cleanup.

Cache those driver parameters for future hot plug events. Because we don't
know which device will show up, cache all the PCI driver parameters.

Signed-off-by: Long Li 
---
 drivers/net/netvsc/hn_ethdev.c | 107 +
 drivers/net/netvsc/hn_var.h|   1 -
 drivers/net/netvsc/hn_vf.c |   4 --
 3 files changed, 94 insertions(+), 18 deletions(-)

diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index f848157b49..afbbccd822 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -95,6 +95,16 @@ static const uint8_t 
rss_default_key[NDIS_HASH_KEYSIZE_TOEPLITZ] = {
0x06, 0x3c, 0x25, 0xf3, 0xfc, 0x1f, 0xdc, 0x2a,
 };
 
+static rte_spinlock_t netvsc_lock = RTE_SPINLOCK_INITIALIZER;
+struct da_cache {
+   LIST_ENTRY(da_cache) list;
+   char name[RTE_DEV_NAME_MAX_LEN];
+   char *drv_str;
+};
+
+LIST_HEAD(da_cache_list, da_cache) da_cache_list;
+static unsigned int da_cache_usage;
+
 static struct rte_eth_dev *
 eth_dev_vmbus_allocate(struct rte_vmbus_device *dev, size_t private_data_size)
 {
@@ -623,16 +633,21 @@ static void netvsc_hotplug_retry(void *args)
   RTE_DIM(eth_addr.addr_bytes));
 
if (rte_is_same_ether_addr(ð_addr, dev->data->mac_addrs)) {
+   struct da_cache *cache;
+
+   LIST_FOREACH(cache, &da_cache_list, list) {
+   if (strcmp(cache->name, d->name) == 0)
+   break;
+   }
+
PMD_DRV_LOG(NOTICE,
-   "Found matching MAC address, adding device 
%s network name %s",
-   d->name, dir->d_name);
+   "Found matching MAC address, adding device 
%s network name %s args %s",
+   d->name, dir->d_name, cache ? 
cache->drv_str : "");
 
/* If this device has been hot removed from this
 * parent device, restore its args.
 */
-   ret = rte_eal_hotplug_add(d->bus->name, d->name,
- hv->vf_devargs ?
- hv->vf_devargs : "");
+   ret = rte_eal_hotplug_add(d->bus->name, d->name, cache 
? cache->drv_str : "");
if (ret) {
PMD_DRV_LOG(ERR,
"Failed to add PCI device %s",
@@ -1409,9 +1424,6 @@ eth_hn_dev_uninit(struct rte_eth_dev *eth_dev)
ret_stop = hn_dev_stop(eth_dev);
hn_dev_close(eth_dev);
 
-   free(hv->vf_devargs);
-   hv->vf_devargs = NULL;
-
hn_detach(hv);
hn_chim_uninit(eth_dev);
rte_vmbus_chan_close(hv->channels[0]);
@@ -1423,6 +1435,61 @@ eth_hn_dev_uninit(struct rte_eth_dev *eth_dev)
return ret_stop;
 }
 
+static int populate_cache_list(void)
+{
+   int ret;
+   struct rte_devargs *da;
+
+   rte_spinlock_lock(&netvsc_lock);
+   da_cache_usage++;
+   if (da_cache_usage > 1) {
+   ret = 0;
+   goto out;
+   }
+
+   LIST_INIT(&da_cache_list);
+   RTE_EAL_DEVARGS_FOREACH("pci", da) {
+   struct da_cache *cache;
+
+   cache = rte_zmalloc("NETVSC-HOTADD", sizeof(*cache), 
rte_mem_page_size());
+   if (!cache) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   strncpy(cache->name, da->name, sizeof(da->name));
+   cache->drv_str = strdup(da->drv_str);
+   if (!cache->drv_str) {
+   rte_free(cache);
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   LIST_INSERT_HEAD(&da_cache_list, cache, list);
+   }
+out:
+   rte_spinlock_unlock(&netvsc_lock);
+   return ret;
+}
+
+static void remove_cache_list(void)
+{
+   struct da_cache *cache;
+
+   rte_spinlock_lock(&netvsc_lock);
+   da_cache_usage--;
+   if (da_cache_usage)
+   goto out;
+
+   LIST_FOREACH(cache, &da_cache_list, list) {
+   LIST_REMOVE(cache, list);
+   free(cache->drv_str);
+   rte_free(cache);
+   }
+out:
+   rte_spinlock_unlock(&netvsc_lock);
+}
+
 static int eth_hn_probe(struct rte_vmbus_driver *drv __rte_unused,
struct rte_vmbus_device *dev)
 {
@@ -1431,24 +1498,35 @@ static int eth_hn_probe(struct rte_vmbus_driver *drv 
__rte_unused,
 
PMD_INIT_FUNC_TRACE();
 
+   ret = populate_cache_list();
+   if (ret)
+  

[PATCH 3/4] net/netvsc: log error on failure to switch data path

[longli]

From: Long Li 

There is no recovery code path if netvsc failed to switch data path.

Log an error in this case for troubleshooting.

Signed-off-by: Long Li 
---
 drivers/net/netvsc/hn_vf.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/netvsc/hn_vf.c b/drivers/net/netvsc/hn_vf.c
index 5d8058774d..4ff766ec8b 100644
--- a/drivers/net/netvsc/hn_vf.c
+++ b/drivers/net/netvsc/hn_vf.c
@@ -316,8 +316,9 @@ static void hn_vf_remove(struct hn_data *hv)
} else {
/* Stop incoming packets from arriving on VF */
ret = hn_nvs_set_datapath(hv, NVS_DATAPATH_SYNTHETIC);
-   if (ret == 0)
-   hv->vf_ctx.vf_vsc_switched = false;
+   if (ret)
+   PMD_DRV_LOG(ERR, "Failed to switch to synthetic");
+   hv->vf_ctx.vf_vsc_switched = false;
}
rte_rwlock_write_unlock(&hv->vf_lock);
 }
-- 
2.34.1

[PATCH 1/4] net/netvsc: scan all net devices under the PCI device

[longli]

From: Long Li 

The current code has the wrong assumption that a PCI device can have only
one Ethernet device. This is not correct as a PCI device can be multi
functional and have multiple Ethernet devices.

Fix this by scanning all the devices under a PCI device.

Fixes: a2a23a794b3a ("net/netvsc: support VF device hot add/remove")
Cc: sta...@dpdk.org
Signed-off-by: Long Li 
---
 drivers/net/netvsc/hn_ethdev.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 1736cb5d07..f848157b49 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -570,7 +570,7 @@ static void netvsc_hotplug_retry(void *args)
struct rte_devargs *d = &hot_ctx->da;
char buf[256];
 
-   DIR *di;
+   DIR *di = NULL;
struct dirent *dir;
struct ifreq req;
struct rte_ether_addr eth_addr;
@@ -590,7 +590,9 @@ static void netvsc_hotplug_retry(void *args)
if (!di) {
PMD_DRV_LOG(DEBUG, "%s: can't open directory %s, "
"retrying in 1 second", __func__, buf);
-   goto retry;
+   /* The device is still being initialized, retry after 1 second 
*/
+   rte_eal_alarm_set(100, netvsc_hotplug_retry, hot_ctx);
+   return;
}
 
while ((dir = readdir(di))) {
@@ -614,10 +616,9 @@ static void netvsc_hotplug_retry(void *args)
dir->d_name);
break;
}
-   if (req.ifr_hwaddr.sa_family != ARPHRD_ETHER) {
-   closedir(di);
-   goto free_hotadd_ctx;
-   }
+   if (req.ifr_hwaddr.sa_family != ARPHRD_ETHER)
+   continue;
+
memcpy(eth_addr.addr_bytes, req.ifr_hwaddr.sa_data,
   RTE_DIM(eth_addr.addr_bytes));
 
@@ -636,22 +637,16 @@ static void netvsc_hotplug_retry(void *args)
PMD_DRV_LOG(ERR,
"Failed to add PCI device %s",
d->name);
-   break;
}
+
+   break;
}
-   /* When the code reaches here, we either have already added
-* the device, or its MAC address did not match.
-*/
-   closedir(di);
-   goto free_hotadd_ctx;
}
-   closedir(di);
-retry:
-   /* The device is still being initialized, retry after 1 second */
-   rte_eal_alarm_set(100, netvsc_hotplug_retry, hot_ctx);
-   return;
 
 free_hotadd_ctx:
+   if (di)
+   closedir(di);
+
rte_spinlock_lock(&hv->hotadd_lock);
LIST_REMOVE(hot_ctx, list);
rte_spinlock_unlock(&hv->hotadd_lock);
-- 
2.34.1

RE: [PATCH v6 00/25] Reduce code duplication across Intel NIC drivers

[Shetty, Praveen]

This patchset attempts to reduce the amount of code duplication across a number 
of Intel NIC drivers, specifically: ixgbe, i40e, iavf, and ice.
As part of this process of deduplication, and in preparation for further 
cleanup work, it moves all existing Intel drivers to a net/intel directory, 
with a "common" subdirectory being created there for the code shared between 
drivers.

The first deduplication patch extracts a function from the Rx side, otherwise 
the majority of the changes are on the Tx side, leading to a converged Tx queue 
structure across the 4 drivers, and a large number of common functions.

v5->v6:
* Added release note entry for configuration changes
* Fixed build issue with -Denable_drivers=net/intel/*
* Added MAINTAINERS file entry for new net/intel/common directory
* Improved prefix heuristics in check-git-log.sh
* Sorted common Tx queue structure elements on add, rather than sorting 
afterwards

v4->v5:
* moved drivers to net/intel and rebased patchset with new paths.

v3->v4:
* Add patches 23 & 24 to set, to do a little more dedupliation on
  Rx side

v2->v3:
* Fix incorrect/unadjusted memset in patch 8, leading to incorrect
  threshold tracking in ixgbe.

v1->v2:
* Fix two additional checkpatch issues that were flagged.
* Added in patch 21, which performs additional cleanup that is possible
  once all vector drivers use the same mbuf free/release process.
  [This brings the patchset to having over twice as many lines removed
  as added (1887 vs 930), and close to having a net removal of 1kloc]

RFC->v1:
* Moved the location of the common code from "common/intel_eth" to
  "net/_common_intel", and added only ".." to the driver include path so
  that the paths included "_common_intel" in them, to make it clear it's
  not driver-local headers.
* Due to change in location, structure/fn prefix changes from "ieth" to
  "ci" for "common intel".
* Removed the seeming-arbitrary split of vector and non-vector code -
  since much of the code taken from vector files was scalar code which
  was used by the vector drivers.
* Split code into separate Rx and Tx files.
* Fixed multiple checkpatch issues (but not all).
* Attempted to improve name standardization, by using "_vec" as a common
  suffix for all vector-related fns and data. Previously, some names had
  "vec" in the middle, others had just "_v" suffix or full word "vector"
  as suffix.
* Other minor changes...

Bruce Richardson (25):
  net: move intel drivers to intel subdirectory
  net/intel: create common pkt reassembly fn
  net/intel: provide common Tx entry structures
  net/intel: create common Tx mbuf ring replenish fn
  net/intel: align Tx queue struct field names
  net/intel: add prefix for driver-specific structs
  net/intel: merge ice and i40e Tx queue struct
  net/iavf: use common Tx queue structure
  net/ixgbe: convert Tx queue context cache field to ptr
  net/ixgbe: use common Tx queue structure
  net/intel: pack Tx queue structure
  net/intel: create common post-Tx buffer free function
  net/intel: create common Tx buffer free fn for AVX-512
  net/iavf: use common Tx free fn for AVX-512
  net/intel: create common Tx queue mbuf cleanup fn
  net/i40e: use common Tx queue mbuf cleanup fn
  net/ixgbe: use common Tx queue mbuf cleanup fn
  net/iavf: use common Tx queue mbuf cleanup fn
  net/ice: use vector SW ring for all vector paths
  net/i40e: use vector SW ring for all vector paths
  net/iavf: use vector SW ring for all vector paths
  net/intel: remove unneeded vector flags and cleanup code
  net/ixgbe: use common Tx backlog entry fn
  net/intel: create common mbuf initializer fn
  net/intel: extract common Rx vector criteria

 MAINTAINERS   |  25 +-
 devtools/check-git-log.sh |   9 +
 doc/api/doxy-api.conf.in  |   6 +-
 doc/guides/nics/ice.rst   |   2 +-
 doc/guides/rel_notes/release_25_03.rst|   7 +
 drivers/meson.build   |   6 +-
 drivers/net/i40e/i40e_rxtx_vec_common.h   | 263 ---
 drivers/net/ice/ice_rxtx_vec_common.h | 426 --
 drivers/net/intel/common/rx.h | 112 +
 drivers/net/intel/common/tx.h | 249 ++
 drivers/net/{ => intel}/cpfl/cpfl_actions.h   |   0
 drivers/net/{ => intel}/cpfl/cpfl_controlq.c  |   0
 drivers/net/{ => intel}/cpfl/cpfl_controlq.h  |   0
 drivers/net/{ => intel}/cpfl/cpfl_cpchnl.h|   0
 drivers/net/{ => intel}/cpfl/cpfl_ethdev.c|   0
 drivers/net/{ => intel}/cpfl/cpfl_ethdev.h|   0
 drivers/net/{ => intel}/cpfl/cpfl_flow.c  |   0
 drivers/net/{ => intel}/cpfl/cpfl_flow.h  |   0
 .../{ => intel}/cpfl/cpfl_flow_engine_fxp.c   |   0
 .../net/{ => intel}/cpfl/cpfl_flow_parser.c   |   0
 .../net/{ => intel}/cpfl/cpfl_flow_parser.h   |   0
 drivers/net/{ => intel}/cpfl/cpfl_fxp_rule.c  |   0
 drivers/net/{ => intel}/cpfl/cpfl_fxp_rule.h  |   0
 drivers/net/{ => intel}/cpfl/cpfl_logs.h

[PATCH 3/3] net/mlx5: fix flow flush for non-template flows

[Maayan Kashani]

Fix flow flush for non template flows on top of HWS,
in another fix it was added return after releasing template flows.
Need to drop the return in order to release non template list of flows.

Fixes: 1ea333d2de22 ("net/mlx5: fix Rx queue reference count in flushing flows")
Cc: sta...@dpdk.org
Signed-off-by: Maayan Kashani 
Acked-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 9203643300d..3d3b422f057 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -8121,7 +8121,6 @@ mlx5_flow_list_flush(struct rte_eth_dev *dev, enum 
mlx5_flow_type type,
priv->hws_rule_flushing = true;
flow_hw_q_flow_flush(dev, NULL);
priv->hws_rule_flushing = false;
-   return;
}
 #endif
MLX5_IPOOL_FOREACH(priv->flows[type], fidx, flow) {
-- 
2.21.0

[PATCH 0/3] Non template to HWS fixes

[Maayan Kashani]

Few fixes for non template mode on top of HWS.

Maayan Kashani (3):
  net/mlx5: fix limitation of actions per rule
  net/mlx5: fix crash in non template metadata split
  net/mlx5: fix flow flush for non-template flows

 drivers/net/mlx5/mlx5_flow.c  |  1 -
 drivers/net/mlx5/mlx5_flow.h  |  2 +-
 drivers/net/mlx5/mlx5_flow_hw.c   |  3 ---
 drivers/net/mlx5/mlx5_nta_split.c | 28 +++-
 4 files changed, 16 insertions(+), 18 deletions(-)

-- 
2.21.0

[PATCH 1/3] net/mlx5: fix limitation of actions per rule

[Maayan Kashani]

HWS implementation added a limitation of 16 actions per rule,
which was incompatible with SWS limitation of 32 actions per rule.

Changing the hard coded limitation in PMD to 32.

Fixes: f13fab23922b ("net/mlx5: add flow jump action")
Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow.h| 2 +-
 drivers/net/mlx5/mlx5_flow_hw.c | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 93c2406abc9..445c9cdb4bf 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1583,7 +1583,7 @@ struct mlx5_hw_modify_header_action {
 };
 
 /* The maximum actions support in the flow. */
-#define MLX5_HW_MAX_ACTS 16
+#define MLX5_HW_MAX_ACTS 32
 
 /* DR action set struct. */
 struct mlx5_hw_actions {
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 2b627114131..501bf33f941 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -21,9 +21,6 @@
 /** Fast path async flow API functions. */
 static struct rte_flow_fp_ops mlx5_flow_hw_fp_ops;
 
-/* The maximum actions support in the flow. */
-#define MLX5_HW_MAX_ACTS 16
-
 /*
  * The default ipool threshold value indicates which per_core_cache
  * value to set.
-- 
2.21.0

[PATCH 2/3] net/mlx5: fix crash in non template metadata split

[Maayan Kashani]

For switch dev mode, there is a rule split in case of using mark action.
First rule will have the mark action, tag it with rule ID number
and jump to the second rule that matches the tag and perform
the rest of the actions (like RSS or queue).

First, fix the crash when accessing RSS queue[0] instead of
queue index, same as for queue action handling for
hairpin RX queue check.
Second, set tag action is not supported in HWS,
so, replaced set tag action with modify field action.
Used same tag index for both action and matching.

Fixes: 821a6a5cc495 ("net/mlx5: add metadata split for compatibility")
Cc: sta...@dpdk.org
Signed-off-by: Maayan Kashani 
Acked-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_nta_split.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_nta_split.c 
b/drivers/net/mlx5/mlx5_nta_split.c
index b26f305bcab..6a85ab7fd12 100644
--- a/drivers/net/mlx5/mlx5_nta_split.c
+++ b/drivers/net/mlx5/mlx5_nta_split.c
@@ -13,6 +13,8 @@
 
 #ifdef HAVE_MLX5_HWS_SUPPORT
 
+#define BITS_PER_BYTE  8
+
 /*
  * Generate new actions lists for prefix and suffix flows.
  *
@@ -44,11 +46,10 @@ mlx5_flow_nta_split_qrss_actions_prep(struct rte_eth_dev 
*dev,
  struct rte_flow_error *error)
 {
struct mlx5_priv *priv = dev->data->dev_private;
-   struct mlx5_rte_flow_action_set_tag *set_tag;
+   struct rte_flow_action_modify_field *set_tag;
struct rte_flow_action_jump *jump;
const int qrss_idx = qrss - actions;
uint32_t flow_id = 0;
-   int ret = 0;
 
/* Allocate the new subflow ID and used to be matched later. */
mlx5_ipool_malloc(priv->sh->ipool[MLX5_IPOOL_RSS_EXPANTION_FLOW_ID], 
&flow_id);
@@ -67,16 +68,16 @@ mlx5_flow_nta_split_qrss_actions_prep(struct rte_eth_dev 
*dev,
/* Count MLX5_RTE_FLOW_ACTION_TYPE_TAG. */
actions_n++;
set_tag = (void *)(prefix_act + actions_n);
-   /* Reuse ASO reg, should always succeed. Consider to use REG_C_6. */
-   ret = flow_hw_get_reg_id_by_domain(dev, RTE_FLOW_ITEM_TYPE_METER_COLOR,
-  MLX5DR_TABLE_TYPE_NIC_RX, 0);
-   MLX5_ASSERT(ret != (int)REG_NON);
-   set_tag->id = (enum modify_reg)ret;
/* Internal SET_TAG action to set flow ID. */
-   set_tag->data = flow_id;
+   set_tag->operation = RTE_FLOW_MODIFY_SET;
+   set_tag->width = sizeof(flow_id) * BITS_PER_BYTE;
+   set_tag->src.field = RTE_FLOW_FIELD_VALUE;
+   memcpy(&set_tag->src.value, &flow_id, sizeof(flow_id));
+   set_tag->dst.field = RTE_FLOW_FIELD_TAG;
+   set_tag->dst.tag_index = RTE_PMD_MLX5_LINEAR_HASH_TAG_INDEX;
/* Construct new actions array and replace QUEUE/RSS action. */
prefix_act[qrss_idx] = (struct rte_flow_action) {
-   .type = (enum 
rte_flow_action_type)MLX5_RTE_FLOW_ACTION_TYPE_TAG,
+   .type = RTE_FLOW_ACTION_TYPE_MODIFY_FIELD,
.conf = set_tag,
};
/* JUMP action to jump to mreg copy table (CP_TBL). */
@@ -132,8 +133,9 @@ mlx5_flow_nta_split_qrss_items_prep(struct rte_eth_dev *dev,
split_items[1].type = RTE_FLOW_ITEM_TYPE_END;
q_tag_spec->data = qrss_id;
q_tag_spec->id = (enum modify_reg)
-flow_hw_get_reg_id_by_domain(dev, 
RTE_FLOW_ITEM_TYPE_METER_COLOR,
- MLX5DR_TABLE_TYPE_NIC_RX, 
0);
+flow_hw_get_reg_id_by_domain(dev, 
RTE_FLOW_ITEM_TYPE_TAG,
+ MLX5DR_TABLE_TYPE_NIC_RX,
+ 
RTE_PMD_MLX5_LINEAR_HASH_TAG_INDEX);
MLX5_ASSERT(q_tag_spec->id != REG_NON);
 }
 
@@ -211,12 +213,12 @@ mlx5_flow_nta_split_metadata(struct rte_eth_dev *dev,
return 0;
} else if (action_flags & MLX5_FLOW_ACTION_RSS) {
rss = (const struct rte_flow_action_rss *)actions->conf;
-   if (mlx5_rxq_is_hairpin(dev, rss->queue[0]))
+   if (mlx5_rxq_is_hairpin(dev, rss->queue_num))
return 0;
}
/* The prefix and suffix flows' actions. */
pefx_act_size = sizeof(struct rte_flow_action) * (actions_n + 1) +
-   sizeof(struct rte_flow_action_set_tag) +
+   sizeof(struct rte_flow_action_modify_field) +
sizeof(struct rte_flow_action_jump);
sfx_act_size = sizeof(struct rte_flow_action) * 2;
/* The suffix attribute. */
-- 
2.21.0

RE: [PATCH v3 3/3] drivers/crypto: use RTE_BIT64 in initializations of hash_algos

[Morten Brørup]

> From: Andre Muezerie [mailto:andre...@linux.microsoft.com]
> Sent: Monday, 27 January 2025 20.33
> 
> This was found during code review of similar issues.
> 
> Signed-off-by: Andre Muezerie 
> ---

Reviewed-by: Morten Brørup 

CNXK crypto & OpenSSL crypto driver maintainers, please review/ack.


>  drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c | 4 ++--
>  drivers/crypto/openssl/rte_openssl_pmd_ops.c  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
> b/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
> index 4394513002..e78bc37c37 100644
> --- a/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
> +++ b/drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c
> @@ -1207,8 +1207,8 @@ static const struct rte_cryptodev_capabilities
> caps_eddsa[] = {
>   {.asym = {
>   .xform_capa = {
>   .xform_type = RTE_CRYPTO_ASYM_XFORM_EDDSA,
> - .hash_algos = (1 << RTE_CRYPTO_AUTH_SHA512 |
> -1 << RTE_CRYPTO_AUTH_SHAKE_256),
> + .hash_algos =
> (RTE_BIT64(RTE_CRYPTO_AUTH_SHA512) |
> +
> RTE_BIT64(RTE_CRYPTO_AUTH_SHAKE_256)),
>   .op_types = ((1 << RTE_CRYPTO_ASYM_OP_SIGN) |
>(1 << RTE_CRYPTO_ASYM_OP_VERIFY))
>   }
> diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
> b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
> index 18f096abfd..04e018f3df 100644
> --- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
> +++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
> @@ -630,8 +630,8 @@ static const struct rte_cryptodev_capabilities
> openssl_pmd_capabilities[] = {
>   {.asym = {
>   .xform_capa = {
>   .xform_type = RTE_CRYPTO_ASYM_XFORM_EDDSA,
> - .hash_algos = (1 << RTE_CRYPTO_AUTH_SHA512 |
> -1 << RTE_CRYPTO_AUTH_SHAKE_256),
> + .hash_algos =
> (RTE_BIT64(RTE_CRYPTO_AUTH_SHA512) |
> +
> RTE_BIT64(RTE_CRYPTO_AUTH_SHAKE_256)),
>   .op_types =
>   ((1<(1 << RTE_CRYPTO_ASYM_OP_VERIFY)),
> --
> 2.47.2.vfs.0.1

RE: [PATCH v3 3/3] drivers/crypto: use RTE_BIT64 in initializations of hash_algos

[Anoob Joseph]

> > From: Andre Muezerie [mailto:andre...@linux.microsoft.com]
> > Sent: Monday, 27 January 2025 20.33
> > 
> > This was found during code review of similar issues.
> > 
> > Signed-off-by: Andre Muezerie 
> > ---
>
> Reviewed-by: Morten Brørup 
>
> CNXK crypto & OpenSSL crypto driver maintainers, please review/ack.

Acked-by: Anoob Joseph