RE: [PATCH 1/2] net/txgbe: add vectorized functions for Rx/Tx

[Jiawen Wu]

On Wed, Feb 7, 2024 11:13 AM, ferruh.yi...@amd.com wrote:
> On 2/1/2024 3:00 AM, Jiawen Wu wrote:
> > To optimize Rx/Tx burst process, add SSE/NEON vector instructions on
> > x86/arm architecture.
> >
> 
> Do you have any performance improvement number with vector
> implementation, if so can you put it into commit log for record?

On our local x86 platforms, the performance was at full speed without
using vector. So we don't have the performance improvement number
with SSE yet. But I will add the test result for arm.

> > @@ -2198,8 +2220,15 @@ txgbe_set_tx_function(struct rte_eth_dev *dev, 
> > struct txgbe_tx_queue *txq)
> >  #endif
> > txq->tx_free_thresh >= RTE_PMD_TXGBE_TX_MAX_BURST) {
> > PMD_INIT_LOG(DEBUG, "Using simple tx code path");
> > -   dev->tx_pkt_burst = txgbe_xmit_pkts_simple;
> > dev->tx_pkt_prepare = NULL;
> > +   if (txq->tx_free_thresh <= RTE_TXGBE_TX_MAX_FREE_BUF_SZ &&
> > +   (rte_eal_process_type() != RTE_PROC_PRIMARY ||
> >
> 
> Why vector Tx enable only for secondary process?

It is not only for secondary process. The constraint is

(rte_eal_process_type() != RTE_PROC_PRIMARY || txgbe_txq_vec_setup(txq) == 0)

This code references ixgbe, which explains:
"When using multiple processes, the TX function used in all processes
 should be the same, otherwise the secondary processes cannot transmit
 more than tx-ring-size - 1 packets.
 To achieve this, we extract out the code to select the ixgbe TX function
 to be used into a separate function inside the ixgbe driver, and call
 that from a secondary process when it is attaching to an
 already-configured NIC."

> > +++ b/drivers/net/txgbe/txgbe_rxtx_vec_neon.c
> > @@ -0,0 +1,604 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2015-2024 Beijing WangXun Technology Co., Ltd.
> > + * Copyright(c) 2010-2015 Intel Corporation
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "txgbe_ethdev.h"
> > +#include "txgbe_rxtx.h"
> > +#include "txgbe_rxtx_vec_common.h"
> > +
> > +#pragma GCC diagnostic ignored "-Wcast-qual"
> > +
> 
> Is this pragma really required?

Yes. Otherwise, there are warnings in the compilation:

[1909/2921] Compiling C object 
drivers/libtmp_rte_net_txgbe.a.p/net_txgbe_txgbe_rxtx_vec_neon.c.o
../drivers/net/txgbe/txgbe_rxtx_vec_neon.c: In function ‘txgbe_rxq_rearm’:
../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:37:15: warning: cast discards 
‘volatile’ qualifier from pointer target type [-Wcast-qual]
 vst1q_u64((uint64_t *)&rxdp[i], zero);
   ^
../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:60:13: warning: cast discards 
‘volatile’ qualifier from pointer target type [-Wcast-qual]
   vst1q_u64((uint64_t *)rxdp++, dma_addr0);
 ^
../drivers/net/txgbe/txgbe_rxtx_vec_neon.c:65:13: warning: cast discards 
‘volatile’ qualifier from pointer target type [-Wcast-qual]
   vst1q_u64((uint64_t *)rxdp++, dma_addr1);

[RFC] net/gve: add IPv4 checksum offloading capability

[Rushil Gupta]

Gvnic's DQO format allows offloading IPv4 checksum.
Made changes to Tx and Rx path to translate DPDK flags
to descriptor for offloading (and vice-versa).
Added ptype adminq support to only add this flags for
supported L3/L4 packet-types.
---
 drivers/net/gve/gve_ethdev.c | 29 +--
 drivers/net/gve/gve_ethdev.h |  5 +
 drivers/net/gve/gve_rx_dqo.c | 38 ++--
 drivers/net/gve/gve_tx_dqo.c |  2 +-
 4 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index 3b8ec5872d..ef0116218e 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -434,8 +434,14 @@ gve_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
RTE_ETH_TX_OFFLOAD_SCTP_CKSUM   |
RTE_ETH_TX_OFFLOAD_TCP_TSO;
 
-   if (priv->queue_format == GVE_DQO_RDA_FORMAT)
-   dev_info->rx_offload_capa |= RTE_ETH_RX_OFFLOAD_TCP_LRO;
+   if (!gve_is_gqi(priv)) {
+   dev_info->tx_offload_capa |= RTE_ETH_TX_OFFLOAD_IPV4_CKSUM;
+   dev_info->rx_offload_capa |=
+   RTE_ETH_RX_OFFLOAD_IPV4_CKSUM   |
+   RTE_ETH_RX_OFFLOAD_UDP_CKSUM|
+   RTE_ETH_RX_OFFLOAD_TCP_CKSUM|
+   RTE_ETH_RX_OFFLOAD_TCP_LRO;
+   }
 
dev_info->default_rxconf = (struct rte_eth_rxconf) {
.rx_free_thresh = GVE_DEFAULT_RX_FREE_THRESH,
@@ -938,6 +944,8 @@ gve_teardown_device_resources(struct gve_priv *priv)
if (err)
PMD_DRV_LOG(ERR, "Could not deconfigure device 
resources: err=%d", err);
}
+   rte_free(priv->ptype_lut_dqo);
+   priv->ptype_lut_dqo = NULL;
gve_free_counter_array(priv);
gve_free_irq_db(priv);
gve_clear_device_resources_ok(priv);
@@ -997,8 +1005,25 @@ gve_setup_device_resources(struct gve_priv *priv)
PMD_DRV_LOG(ERR, "Could not config device resources: err=%d", 
err);
goto free_irq_dbs;
}
+
+   priv->ptype_lut_dqo = rte_zmalloc("gve_ptype_lut_dqo",
+   sizeof(struct gve_ptype_lut), 0);
+   if (priv->ptype_lut_dqo == NULL) {
+   PMD_DRV_LOG(ERR, "Failed to alloc ptype lut.");
+   err = -ENOMEM;
+   goto free_irq_dbs;
+   }
+   err = gve_adminq_get_ptype_map_dqo(priv, priv->ptype_lut_dqo);
+   if (unlikely(err)) {
+   PMD_DRV_LOG(ERR, "Failed to get ptype map: err=%d", err);
+   goto free_ptype_lut;
+   }
+
return 0;
 
+free_ptype_lut:
+   rte_free(priv->ptype_lut_dqo);
+   priv->ptype_lut_dqo = NULL;
 free_irq_dbs:
gve_free_irq_db(priv);
 free_cnt_array:
diff --git a/drivers/net/gve/gve_ethdev.h b/drivers/net/gve/gve_ethdev.h
index d713657d10..9b19fc55e3 100644
--- a/drivers/net/gve/gve_ethdev.h
+++ b/drivers/net/gve/gve_ethdev.h
@@ -36,6 +36,10 @@
RTE_MBUF_F_TX_L4_MASK  |\
RTE_MBUF_F_TX_TCP_SEG)
 
+#define GVE_TX_CKSUM_OFFLOAD_MASK_DQO (\
+   GVE_TX_CKSUM_OFFLOAD_MASK | \
+   RTE_MBUF_F_TX_IP_CKSUM)
+
 #define GVE_RTE_RSS_OFFLOAD_ALL (  \
RTE_ETH_RSS_IPV4 |  \
RTE_ETH_RSS_NONFRAG_IPV4_TCP |  \
@@ -295,6 +299,7 @@ struct gve_priv {
uint16_t stats_end_idx; /* end index of array of stats written by NIC */
 
struct gve_rss_config rss_config;
+   struct gve_ptype_lut *ptype_lut_dqo;
 };
 
 static inline bool
diff --git a/drivers/net/gve/gve_rx_dqo.c b/drivers/net/gve/gve_rx_dqo.c
index 7c7a8c48d0..1c37c54cb7 100644
--- a/drivers/net/gve/gve_rx_dqo.c
+++ b/drivers/net/gve/gve_rx_dqo.c
@@ -75,6 +75,40 @@ gve_rx_refill_dqo(struct gve_rx_queue *rxq)
rxq->bufq_tail = next_avail;
 }
 
+static inline uint16_t
+gve_parse_csum_ol_flags(volatile struct gve_rx_compl_desc_dqo *rx_desc,
+   struct gve_priv *priv) {
+   uint64_t ol_flags = 0;
+   struct gve_ptype ptype =
+   priv->ptype_lut_dqo->ptypes[rx_desc->packet_type];
+
+   if(!rx_desc->l3_l4_processed)
+   return ol_flags;
+
+   if (ptype.l3_type == GVE_L3_TYPE_IPV4) {
+   if (rx_desc->csum_ip_err)
+   ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
+   else
+   ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
+   }
+
+   if (rx_desc->csum_l4_err) {
+   ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
+   return ol_flags;
+   }
+   switch (ptype.l4_type) {
+   case GVE_L4_TYPE_TCP:
+   case GVE_L4_TYPE_UDP:
+   case GVE_L4_TYPE_ICMP:
+   case GVE_L4_TYPE_SCTP:
+   ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
+   break;
+   default:
+   break;
+   }
+   return ol_flags;
+}
+
 uint16_t
 g

Re: [PATCH v4] vhost: enhance virtqueue access lock asserts

[David Marchand]

On Tue, Feb 27, 2024 at 11:39 AM David Marchand
 wrote:
>
> A simple comment in vhost_user_msg_handler() is not that robust.
>
> Add a lock_all_qps property to message handlers so that their
> implementation can add a build check and assert a vq is locked.
>
> Signed-off-by: David Marchand 
> Reviewed-by: Maxime Coquelin 
> ---
> Changes since v3:
> - directly called static_assert() with improved message,
>
> Changes since v2:
> - dropped review tags,
> - following use of static_assert() in RTE_BUILD_BUG_ON, reworked build
>   check by using enums (one enum is now defined per message type),
> - as the added enums must be defined early, moved the definitions of
>   handlers at the top of the file,
>
> Changes since v1:
> - moved this patch as the last of the series,

Applied, thanks.


-- 
David Marchand

Re: [PATCH v2] vhost: fix VDUSE device destruction failure

[David Marchand]

On Mon, Mar 4, 2024 at 11:36 AM David Marchand
 wrote:
>
> From: Maxime Coquelin 
>
> VDUSE_DESTROY_DEVICE ioctl can fail because the device's
> chardev is not released despite close syscall having been
> called. It happens because the events handler thread is
> still polling the file descriptor.
>
> fdset_pipe_notify() is not enough because it does not
> ensure the notification has been handled by the event
> thread, it just returns once the notification is sent.
>
> To fix this, this patch introduces a synchronization
> mechanism based on pthread's condition, so that
> fdset_pipe_notify_sync() only returns once the pipe's
> read callback has been executed.
>
> Fixes: 51d018fdac4e ("vhost: add VDUSE events handler")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Maxime Coquelin 
> Signed-off-by: David Marchand 
> ---
> Changes since v1:
> - sync'd only when in VDUSE destruction path,
> - added explicit init of sync_mutex,

Applied, thanks.


-- 
David Marchand

[PATCH] vhost: fix vring addr update with vDPA

[David Marchand]

For vDPA devices, vq are not locked once the device has been configured
at runtime.

On the other hand, we need to hold the vq lock to evaluate vq->access_ok,
invalidate vring addresses and translate them.

Move vring address update earlier and, when vDPA is configured, skip parts
which expect lock to be taken.

Bugzilla ID: 1394
Fixes: 741dc052eaf9 ("vhost: annotate virtqueue access checks")

Signed-off-by: David Marchand 
---
 lib/vhost/vhost_user.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 3aba32c95a..7fe1687f08 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -986,17 +986,20 @@ vhost_user_set_vring_addr(struct virtio_net **pdev,
/* addr->index refers to the queue index. The txq 1, rxq is 0. */
vq = dev->virtqueue[ctx->msg.payload.addr.index];
 
-   /* vhost_user_lock_all_queue_pairs locked all qps */
-   VHOST_USER_ASSERT_LOCK(dev, vq, VHOST_USER_SET_VRING_ADDR);
-
-   access_ok = vq->access_ok;
-
/*
 * Rings addresses should not be interpreted as long as the ring is not
 * started and enabled
 */
memcpy(&vq->ring_addrs, addr, sizeof(*addr));
 
+   if (dev->flags & VIRTIO_DEV_VDPA_CONFIGURED)
+   goto out;
+
+   /* vhost_user_lock_all_queue_pairs locked all qps */
+   VHOST_USER_ASSERT_LOCK(dev, vq, VHOST_USER_SET_VRING_ADDR);
+
+   access_ok = vq->access_ok;
+
vring_invalidate(dev, vq);
 
if ((vq->enabled && (dev->features &
@@ -1006,6 +1009,7 @@ vhost_user_set_vring_addr(struct virtio_net **pdev,
*pdev = dev;
}
 
+out:
return RTE_VHOST_MSG_RESULT_OK;
 }
 
-- 
2.43.0

RE: [PATCH v2 22/71] raw/ifpga: replace use of fixed size rte_memcpy

[Xu, Rosen]

Hi,

> -Original Message-
> From: Stephen Hemminger 
> Sent: Saturday, March 2, 2024 1:15 AM
> To: dev@dpdk.org
> Cc: Stephen Hemminger ; Xu, Rosen
> 
> Subject: [PATCH v2 22/71] raw/ifpga: replace use of fixed size rte_memcpy
> 
> Automatically generated by devtools/cocci/rte_memcpy.cocci
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/raw/ifpga/afu_pmd_he_hssi.c |  3 +--
> drivers/raw/ifpga/afu_pmd_he_lpbk.c |  3 +--
> drivers/raw/ifpga/afu_pmd_he_mem.c  |  3 +--
>  drivers/raw/ifpga/afu_pmd_n3000.c   |  8 
>  drivers/raw/ifpga/ifpga_rawdev.c| 11 +--
>  5 files changed, 12 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/raw/ifpga/afu_pmd_he_hssi.c
> b/drivers/raw/ifpga/afu_pmd_he_hssi.c
> index 859f28dcc1f0..c2aaed9203ae 100644
> --- a/drivers/raw/ifpga/afu_pmd_he_hssi.c
> +++ b/drivers/raw/ifpga/afu_pmd_he_hssi.c
> @@ -15,7 +15,6 @@
> 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -314,7 +313,7 @@ static int he_hssi_config(struct afu_rawdev *dev,
> void *config,
>   if (cfg->port >= NUM_HE_HSSI_PORTS)
>   return -EINVAL;
> 
> - rte_memcpy(&priv->he_hssi_cfg, cfg, sizeof(priv->he_hssi_cfg));
> + memcpy(&priv->he_hssi_cfg, cfg, sizeof(priv->he_hssi_cfg));
> 
>   return 0;
>  }
> diff --git a/drivers/raw/ifpga/afu_pmd_he_lpbk.c
> b/drivers/raw/ifpga/afu_pmd_he_lpbk.c
> index c7c5cda48c35..ffb7075c84d2 100644
> --- a/drivers/raw/ifpga/afu_pmd_he_lpbk.c
> +++ b/drivers/raw/ifpga/afu_pmd_he_lpbk.c
> @@ -15,7 +15,6 @@
> 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -363,7 +362,7 @@ static int he_lpbk_config(struct afu_rawdev *dev,
> void *config,
>   if ((cfg->end < cfg->begin) || (cfg->end > MAX_CACHE_LINES))
>   return -EINVAL;
> 
> - rte_memcpy(&priv->he_lpbk_cfg, cfg, sizeof(priv->he_lpbk_cfg));
> + memcpy(&priv->he_lpbk_cfg, cfg, sizeof(priv->he_lpbk_cfg));
> 
>   return 0;
>  }
> diff --git a/drivers/raw/ifpga/afu_pmd_he_mem.c
> b/drivers/raw/ifpga/afu_pmd_he_mem.c
> index a1db533eeb93..b799e40d2db9 100644
> --- a/drivers/raw/ifpga/afu_pmd_he_mem.c
> +++ b/drivers/raw/ifpga/afu_pmd_he_mem.c
> @@ -14,7 +14,6 @@
> 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -126,7 +125,7 @@ static int he_mem_tg_config(struct afu_rawdev *dev,
> void *config,
>   if (config_size != sizeof(struct rte_pmd_afu_he_mem_tg_cfg))
>   return -EINVAL;
> 
> - rte_memcpy(&priv->he_mem_tg_cfg, config, sizeof(priv-
> >he_mem_tg_cfg));
> + memcpy(&priv->he_mem_tg_cfg, config, sizeof(priv-
> >he_mem_tg_cfg));
> 
>   return 0;
>  }
> diff --git a/drivers/raw/ifpga/afu_pmd_n3000.c
> b/drivers/raw/ifpga/afu_pmd_n3000.c
> index 67b394126595..9236c0b15371 100644
> --- a/drivers/raw/ifpga/afu_pmd_n3000.c
> +++ b/drivers/raw/ifpga/afu_pmd_n3000.c
> @@ -1867,8 +1867,8 @@ static int n3000_afu_config(struct afu_rawdev *dev,
> void *config,
>   if ((cfg->nlb_cfg.end < cfg->nlb_cfg.begin) ||
>   (cfg->nlb_cfg.end > MAX_CACHE_LINES))
>   return -EINVAL;
> - rte_memcpy(&priv->nlb_cfg, &cfg->nlb_cfg,
> - sizeof(struct rte_pmd_afu_nlb_cfg));
> + memcpy(&priv->nlb_cfg, &cfg->nlb_cfg,
> +sizeof(struct rte_pmd_afu_nlb_cfg));
>   } else if (cfg->type == RTE_PMD_AFU_N3000_DMA) {
>   if (cfg->dma_cfg.index >= NUM_N3000_DMA)
>   return -EINVAL;
> @@ -1887,8 +1887,8 @@ static int n3000_afu_config(struct afu_rawdev *dev,
> void *config,
>   cfg->dma_cfg.length);
>   }
>   }
> - rte_memcpy(&priv->dma_cfg, &cfg->dma_cfg,
> - sizeof(struct rte_pmd_afu_dma_cfg));
> + memcpy(&priv->dma_cfg, &cfg->dma_cfg,
> +sizeof(struct rte_pmd_afu_dma_cfg));
>   } else {
>   IFPGA_RAWDEV_PMD_ERR("Invalid type of N3000 AFU");
>   return -EINVAL;
> diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> b/drivers/raw/ifpga/ifpga_rawdev.c
> index f89bd3f9e2c3..d5d47e14dd0e 100644
> --- a/drivers/raw/ifpga/ifpga_rawdev.c
> +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> @@ -14,7 +14,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -258,7 +257,7 @@ static int ifpga_rawdev_fill_info(struct ifpga_rawdev
> *ifpga_dev)
>   if (point < 12)
>   return -1;
>   point -= 12;
> - rte_memcpy(ifpga_dev->parent_bdf, &link[point], 12);
> + memcpy(ifpga_dev->parent_bdf, &link[point], 12);
> 
>   point = strlen(link1);
>   if (point < 26)
> @@ -948,10 +947,10 @@ ifpga_rawdev_pr(struct rte_rawdev *dev,
>   if (ret)
>   return ret;
> 
> - rte_memcpy(&afu_pr_conf->afu_id.uuid.uuid_low, uuid.b,
> - sizeof(u64));
> -

Re: [PATCH] hash: make gfni stubs inline

[David Marchand]

On Mon, Mar 4, 2024 at 7:45 PM Stephen Hemminger
 wrote:
>
> This reverts commit 07d836e5929d18ad6640ebae90dd2f81a2cafb71.
>
> Tyler found build issues with MSVC and the thash gfni stubs.
> The problem would be link errors from missing symbols.

Trying to understand this link error.
Does it come from the fact that rte_thash_gfni/rte_thash_gfni_bulk
declarations are hidden under RTE_THASH_GFNI_DEFINED in
rte_thash_gfni.h?

If so, why not always expose those two symbols unconditionnally and
link with the stub only when ! RTE_THASH_GFNI_DEFINED.


-- 
David Marchand

[PATCH] config/arm: add Marvell Odyssey

[Anoob Joseph]

Add meson build configuration for Marvell Odyssey platform with 64-bit
ARM Neoverse V2 cores.

Signed-off-by: Anoob Joseph 
---

Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")

 config/arm/arm64_odyssey_linux_gcc-marvell | 17 +
 config/arm/meson.build | 15 +++
 2 files changed, 32 insertions(+)
 create mode 100644 config/arm/arm64_odyssey_linux_gcc-marvell

diff --git a/config/arm/arm64_odyssey_linux_gcc-marvell 
b/config/arm/arm64_odyssey_linux_gcc-marvell
new file mode 100644
index 00..69b5cd42d8
--- /dev/null
+++ b/config/arm/arm64_odyssey_linux_gcc-marvell
@@ -0,0 +1,17 @@
+[binaries]
+c = ['ccache', 'aarch64-marvell-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-marvell-linux-gnu-g++']
+ar = 'aarch64-marvell-linux-gnu-gcc-ar'
+strip = 'aarch64-marvell-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv9-a'
+endian = 'little'
+
+[properties]
+platform = 'odyssey'
+
+[built-in options]
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3886d0e2dc..94159efaa4 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -500,6 +500,20 @@ soc_n2 = {
 'numa': false
 }
 
+soc_odyssey = {
+'description' : 'Marvell Odyssey',
+'implementer' : '0x41',
+'flags': [
+['RTE_MAX_LCORE', 80],
+['RTE_MAX_NUMA_NODES', 1],
+['RTE_MEMPOOL_ALIGN', 128],
+],
+'part_number': '0xd4f',
+'extra_march_features': ['crypto'],
+'numa': false,
+'sve_acle': false
+}
+
 soc_cn9k = {
 'description': 'Marvell OCTEON 9',
 'implementer': '0x43',
@@ -617,6 +631,7 @@ socs = {
 'kunpeng930': soc_kunpeng930,
 'n1sdp': soc_n1sdp,
 'n2': soc_n2,
+'odyssey' : soc_odyssey,
 'stingray': soc_stingray,
 'thunderx2': soc_thunderx2,
 'thunderxt88': soc_thunderxt88,
-- 
2.25.1

[PATCH v7] net/i40e: add diagnostic support in Tx path

[Mingjin Ye]

Implemented a Tx wrapper to perform a thorough check on mbufs,
categorizing and counting invalid cases by type for diagnostic
purposes. The count of invalid cases is accessible through xstats_get.

Also, the devarg option "mbuf_check" was introduced to configure the
diagnostic parameters to enable the appropriate diagnostic features.

supported cases: mbuf, size, segment, offload.
 1. mbuf: Check for corrupted mbuf.
 2. size: Check min/max packet length according to HW spec.
 3. segment: Check number of mbuf segments not exceed HW limits.
 4. offload: Check for use of an unsupported offload flag.

parameter format: "mbuf_check=" or "mbuf_check=[,]"
eg: dpdk-testpmd -a :87:00.0,mbuf_check=[mbuf,size] -- -i

Signed-off-by: Mingjin Ye 
---
v2: remove strict.
---
v3: optimised.
---
v4: rebase.
---
v5: fix ci error.
---
v6: Changes the commit log.
---
v7: Remove unnecessary changes.
---
 doc/guides/nics/i40e.rst   |  13 +++
 drivers/net/i40e/i40e_ethdev.c | 142 -
 drivers/net/i40e/i40e_ethdev.h |  14 
 drivers/net/i40e/i40e_rxtx.c   | 112 ++
 drivers/net/i40e/i40e_rxtx.h   |   2 +
 5 files changed, 282 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 15689ac958..bf1d1e5d60 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -275,6 +275,19 @@ Runtime Configuration
 
   -a 84:00.0,vf_msg_cfg=80@120:180
 
+- ``Support TX diagnostics`` (default ``not enabled``)
+
+  Set the ``devargs`` parameter ``mbuf_check`` to enable TX diagnostics. For 
example,
+  ``-a 18:01.0,mbuf_check=`` or ``-a 
18:01.0,mbuf_check=[,...]``. Also,
+  ``xstats_get`` can be used to get the error counts, which are collected in
+  ``tx_mbuf_error_packets`` xstats. For example, ``testpmd> show port xstats 
all``.
+  Supported cases:
+
+  *   mbuf: Check for corrupted mbuf.
+  *   size: Check min/max packet length according to hw spec.
+  *   segment: Check number of mbuf segments not exceed hw limitation.
+  *   offload: Check any unsupported offload flag.
+
 Vector RX Pre-conditions
 
 For Vector RX it is assumed that the number of descriptor rings will be a power
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 4d21341382..84fefcb1f9 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -48,6 +48,7 @@
 #define ETH_I40E_SUPPORT_MULTI_DRIVER  "support-multi-driver"
 #define ETH_I40E_QUEUE_NUM_PER_VF_ARG  "queue-num-per-vf"
 #define ETH_I40E_VF_MSG_CFG"vf_msg_cfg"
+#define ETH_I40E_MBUF_CHECK_ARG   "mbuf_check"
 
 #define I40E_CLEAR_PXE_WAIT_MS 200
 #define I40E_VSI_TSR_QINQ_STRIP0x4010
@@ -412,6 +413,7 @@ static const char *const valid_keys[] = {
ETH_I40E_SUPPORT_MULTI_DRIVER,
ETH_I40E_QUEUE_NUM_PER_VF_ARG,
ETH_I40E_VF_MSG_CFG,
+   ETH_I40E_MBUF_CHECK_ARG,
NULL};
 
 static const struct rte_pci_id pci_id_i40e_map[] = {
@@ -545,6 +547,14 @@ static const struct rte_i40e_xstats_name_off 
rte_i40e_stats_strings[] = {
 #define I40E_NB_ETH_XSTATS (sizeof(rte_i40e_stats_strings) / \
sizeof(rte_i40e_stats_strings[0]))
 
+static const struct rte_i40e_xstats_name_off i40e_mbuf_strings[] = {
+   {"tx_mbuf_error_packets", offsetof(struct i40e_mbuf_stats,
+   tx_pkt_errors)},
+};
+
+#define I40E_NB_MBUF_XSTATS (sizeof(i40e_mbuf_strings) / \
+   sizeof(i40e_mbuf_strings[0]))
+
 static const struct rte_i40e_xstats_name_off rte_i40e_hw_port_strings[] = {
{"tx_link_down_dropped", offsetof(struct i40e_hw_port_stats,
tx_dropped_link_down)},
@@ -1373,6 +1383,94 @@ read_vf_msg_config(__rte_unused const char *key,
return 0;
 }
 
+static int
+read_mbuf_check_config(__rte_unused const char *key, const char *value, void 
*args)
+{
+   char *cur;
+   char *tmp;
+   int str_len;
+   int valid_len;
+
+   int ret = 0;
+   uint64_t *mc_flags = args;
+   char *str2 = strdup(value);
+   if (str2 == NULL)
+   return -1;
+
+   str_len = strlen(str2);
+   if (str_len == 0) {
+   ret = -1;
+   goto err_end;
+   }
+
+   /* Try stripping the outer square brackets of the parameter string. */
+   str_len = strlen(str2);
+   if (str2[0] == '[' && str2[str_len - 1] == ']') {
+   if (str_len < 3) {
+   ret = -1;
+   goto err_end;
+   }
+   valid_len = str_len - 2;
+   memmove(str2, str2 + 1, valid_len);
+   memset(str2 + valid_len, '\0', 2);
+   }
+
+   cur = strtok_r(str2, ",", &tmp);
+   while (cur != NULL) {
+   if (!strcmp(cur, "mbuf"))
+   *mc_flags |= I40E_MBUF_CHECK_F_TX_MBUF;
+   else if (!strcmp(cur, "size"))
+   *mc_flags |= I40E_MBUF_CHECK_F_TX_S

[PATCH v4] net/ice: add diagnostic support in Tx path

[Mingjin Ye]

Implemented a Tx wrapper to perform a thorough check on mbufs,
categorizing and counting invalid cases by type for diagnostic
purposes. The count of invalid cases is accessible through xstats_get.

Also, the devarg option "mbuf_check" was introduced to configure the
diagnostic parameters to enable the appropriate diagnostic features.

supported cases: mbuf, size, segment, offload.
 1. mbuf: Check for corrupted mbuf.
 2. size: Check min/max packet length according to HW spec.
 3. segment: Check number of mbuf segments not exceed HW limits.
 4. offload: Check for use of an unsupported offload flag.

parameter format: "mbuf_check=" or "mbuf_check=[,]"
eg: dpdk-testpmd -a :81:00.0,mbuf_check=[mbuf,size] -- -i

Signed-off-by: Mingjin Ye 
---
v2: rebase.
---
v3: Modify comment log.
---
v4: Remove unnecessary changes.
---
 doc/guides/nics/ice.rst  |  14 +
 drivers/net/ice/ice_ethdev.c | 107 +-
 drivers/net/ice/ice_ethdev.h |  13 +
 drivers/net/ice/ice_rxtx.c   | 110 +++
 drivers/net/ice/ice_rxtx.h   |  20 +++
 5 files changed, 263 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 8f33751577..53b4a79095 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -257,6 +257,20 @@ Runtime Configuration
   As a trade-off, this configuration may cause the packet processing 
performance
   degradation due to the PCI bandwidth limitation.
 
+- ``Tx diagnostics`` (default ``not enabled``)
+
+  Set the ``devargs`` parameter ``mbuf_check`` to enable TX diagnostics.
+  For example, ``-a 81:00.0,mbuf_check=`` or ``-a 
81:00.0,mbuf_check=[,...]``.
+  Thereafter, ``rte_eth_xstats_get()`` can be used to get the error counts,
+  which are collected in ``tx_mbuf_error_packets`` xstats.
+  In testpmd these can be shown via: ``testpmd> show port xstats all``.
+  Supported values for the ``case`` parameter are:
+
+  *   mbuf: Check for corrupted mbuf.
+  *   size: Check min/max packet length according to HW spec.
+  *   segment: Check number of mbuf segments does not exceed HW limits.
+  *   offload: Check for use of an unsupported offload flag.
+
 Driver compilation and testing
 --
 
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index f07b236ad4..daf1d629e8 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -12,6 +12,7 @@
 #include 
 
 #include 
+#include 
 
 #include "eal_firmware.h"
 
@@ -34,6 +35,7 @@
 #define ICE_HW_DEBUG_MASK_ARG "hw_debug_mask"
 #define ICE_ONE_PPS_OUT_ARG   "pps_out"
 #define ICE_RX_LOW_LATENCY_ARG"rx_low_latency"
+#define ICE_MBUF_CHECK_ARG   "mbuf_check"
 
 #define ICE_CYCLECOUNTER_MASK  0xULL
 
@@ -49,6 +51,7 @@ static const char * const ice_valid_args[] = {
ICE_ONE_PPS_OUT_ARG,
ICE_RX_LOW_LATENCY_ARG,
ICE_DEFAULT_MAC_DISABLE,
+   ICE_MBUF_CHECK_ARG,
NULL
 };
 
@@ -320,6 +323,14 @@ static const struct ice_xstats_name_off 
ice_stats_strings[] = {
 #define ICE_NB_ETH_XSTATS (sizeof(ice_stats_strings) / \
sizeof(ice_stats_strings[0]))
 
+static const struct ice_xstats_name_off ice_mbuf_strings[] = {
+   {"tx_mbuf_error_packets", offsetof(struct ice_mbuf_stats,
+   tx_pkt_errors)},
+};
+
+#define ICE_NB_MBUF_XSTATS (sizeof(ice_mbuf_strings) / \
+   sizeof(ice_mbuf_strings[0]))
+
 static const struct ice_xstats_name_off ice_hw_port_strings[] = {
{"tx_link_down_dropped", offsetof(struct ice_hw_port_stats,
tx_dropped_link_down)},
@@ -2062,6 +2073,58 @@ handle_pps_out_arg(__rte_unused const char *key, const 
char *value,
return 0;
 }
 
+static int
+ice_parse_mbuf_check(__rte_unused const char *key, const char *value, void 
*args)
+{
+   char *cur;
+   char *tmp;
+   int str_len;
+   int valid_len;
+
+   int ret = 0;
+   uint64_t *mc_flags = args;
+   char *str2 = strdup(value);
+   if (str2 == NULL)
+   return -1;
+
+   str_len = strlen(str2);
+   if (str_len == 0) {
+   ret = -1;
+   goto err_end;
+   }
+
+   /* Try stripping the outer square brackets of the parameter string. */
+   str_len = strlen(str2);
+   if (str2[0] == '[' && str2[str_len - 1] == ']') {
+   if (str_len < 3) {
+   ret = -1;
+   goto err_end;
+   }
+   valid_len = str_len - 2;
+   memmove(str2, str2 + 1, valid_len);
+   memset(str2 + valid_len, '\0', 2);
+   }
+
+   cur = strtok_r(str2, ",", &tmp);
+   while (cur != NULL) {
+   if (!strcmp(cur, "mbuf"))
+   *mc_flags |= ICE_MBUF_CHECK_F_TX_MBUF;
+   else if (!strcmp(cur, "size"))
+   *mc_flags |= ICE_MBUF_CHECK_F_TX_SIZE;
+   else if (!strcmp(cur, "seg

[PATCH] argparse: add version in symbols map

[David Marchand]

Fixes: e3e579f5bab5 ("argparse: introduce argparse library")

Signed-off-by: David Marchand 
---
 lib/argparse/version.map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/argparse/version.map b/lib/argparse/version.map
index 9b68464600..46da99a3e2 100644
--- a/lib/argparse/version.map
+++ b/lib/argparse/version.map
@@ -1,6 +1,7 @@
 EXPERIMENTAL {
global:
 
+   # added in 24.03
rte_argparse_parse;
rte_argparse_parse_type;
 
-- 
2.43.0

[PATCH] net/ice: add version in symbols map

[David Marchand]

Fixes: 0d8d7bd720ba ("net/ice: support DDP dump switch rule binary")
Fixes: ab4eaf9a8a31 ("net/ice: dump Tx scheduling tree")

Signed-off-by: David Marchand 
---
 drivers/net/ice/version.map | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ice/version.map b/drivers/net/ice/version.map
index 24b425d6f7..8449e98aba 100644
--- a/drivers/net/ice/version.map
+++ b/drivers/net/ice/version.map
@@ -7,6 +7,10 @@ EXPERIMENTAL {
 
# added in 19.11
rte_pmd_ice_dump_package;
+
+   # added in 22.11
rte_pmd_ice_dump_switch;
+
+   # added in 24.03
rte_pmd_ice_dump_txsched;
 };
-- 
2.43.0

Re: [PATCH] argparse: add version in symbols map

[Bruce Richardson]

On Tue, Mar 05, 2024 at 11:36:40AM +0100, David Marchand wrote:
> Fixes: e3e579f5bab5 ("argparse: introduce argparse library")
> 
> Signed-off-by: David Marchand 
> ---

Acked-by: Bruce Richardson 

Re: [PATCH] net/ice: add version in symbols map

[Bruce Richardson]

On Tue, Mar 05, 2024 at 11:36:51AM +0100, David Marchand wrote:
> Fixes: 0d8d7bd720ba ("net/ice: support DDP dump switch rule binary")
> Fixes: ab4eaf9a8a31 ("net/ice: dump Tx scheduling tree")
> 
> Signed-off-by: David Marchand 
> ---

Acked-by: Bruce Richardson 

[PATCH v2] config/arm: add Marvell Odyssey

[Anoob Joseph]

Add meson build configuration for Marvell Odyssey platform with 64-bit
ARM Neoverse V2 cores.

Signed-off-by: Anoob Joseph 
---

Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")

Changes in v2:
- Renamed config file

 config/arm/arm64_odyssey_linux_gcc | 17 +
 config/arm/meson.build | 15 +++
 2 files changed, 32 insertions(+)
 create mode 100644 config/arm/arm64_odyssey_linux_gcc

diff --git a/config/arm/arm64_odyssey_linux_gcc 
b/config/arm/arm64_odyssey_linux_gcc
new file mode 100644
index 00..69b5cd42d8
--- /dev/null
+++ b/config/arm/arm64_odyssey_linux_gcc
@@ -0,0 +1,17 @@
+[binaries]
+c = ['ccache', 'aarch64-marvell-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-marvell-linux-gnu-g++']
+ar = 'aarch64-marvell-linux-gnu-gcc-ar'
+strip = 'aarch64-marvell-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv9-a'
+endian = 'little'
+
+[properties]
+platform = 'odyssey'
+
+[built-in options]
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3886d0e2dc..94159efaa4 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -500,6 +500,20 @@ soc_n2 = {
 'numa': false
 }
 
+soc_odyssey = {
+'description' : 'Marvell Odyssey',
+'implementer' : '0x41',
+'flags': [
+['RTE_MAX_LCORE', 80],
+['RTE_MAX_NUMA_NODES', 1],
+['RTE_MEMPOOL_ALIGN', 128],
+],
+'part_number': '0xd4f',
+'extra_march_features': ['crypto'],
+'numa': false,
+'sve_acle': false
+}
+
 soc_cn9k = {
 'description': 'Marvell OCTEON 9',
 'implementer': '0x43',
@@ -617,6 +631,7 @@ socs = {
 'kunpeng930': soc_kunpeng930,
 'n1sdp': soc_n1sdp,
 'n2': soc_n2,
+'odyssey' : soc_odyssey,
 'stingray': soc_stingray,
 'thunderx2': soc_thunderx2,
 'thunderxt88': soc_thunderxt88,
-- 
2.25.1

[PATCH] test/crypto: fix non ASCII character

[Anoob Joseph]

Fix non ASCII character in the comment. Revert to original text.

Bugzilla ID: 1396
Fixes: f97c63f4f445 ("test/crypto: add AES-GCM external mbuf case")

Signed-off-by: Anoob Joseph 
---
 app/test/test_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index c3c3f587b4..754fab39c5 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -1615,7 +1615,7 @@ ext_mbuf_create(struct rte_mempool *mbuf_pool, int 
pkt_len,
goto fail;
}
 
-   /* Save shared data (like callback function) in external 
buffer’s end */
+   /* Save shared data (like callback function) in external 
buffer's end */
ret_shinfo = rte_pktmbuf_ext_shinfo_init_helper(ext_buf_addr, 
&buf_len,
ext_mbuf_callback_fn_free, &freed);
if (ret_shinfo == NULL) {
-- 
2.25.1

Re: [PATCH] argparse: add version in symbols map

[fengchengwen]

Acked-by: Chengwen Feng 

BTW: which tool detects this problem?

On 2024/3/5 18:36, David Marchand wrote:
> Fixes: e3e579f5bab5 ("argparse: introduce argparse library")
> 
> Signed-off-by: David Marchand 
> ---
>  lib/argparse/version.map | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/argparse/version.map b/lib/argparse/version.map
> index 9b68464600..46da99a3e2 100644
> --- a/lib/argparse/version.map
> +++ b/lib/argparse/version.map
> @@ -1,6 +1,7 @@
>  EXPERIMENTAL {
>   global:
>  
> + # added in 24.03
>   rte_argparse_parse;
>   rte_argparse_parse_type;
>  
> 

Re: [PATCH] examples/dma: fix max-frame-size cannot be zero

[fengchengwen]

Hi Thomas,

This commit fix bug "Bug 1387 - [dpdk24.03] cbdma: Failed to launch dpdk-dma 
app" [1]

Should I send v2 to add the following line in commit log?
Bugzilla ID: 1387

[1] https://bugs.dpdk.org/show_bug.cgi?id=1387

Thanks

On 2024/2/21 14:51, Jiang, YuX wrote:
>> -Original Message-
>> From: Chengwen Feng 
>> Sent: Tuesday, February 20, 2024 10:32 AM
>> To: tho...@monjalon.net; dev@dpdk.org; Jiang, YuX ;
>> Richardson, Bruce ; Laatz, Kevin
>> 
>> Subject: [PATCH] examples/dma: fix max-frame-size cannot be zero
>>
>> In the original implementation, the max_frame_size could be zero, but commit
>> ("examples/dma: replace getopt with argparse") treat zero as an error. This
>> commit fixes it.
>>
>> Also, since unsigned doesn't < 0, adjust "<= 0" judgement to "== 0".
>>
>> Fixes: 8d85afb19af7 ("examples/dma: replace getopt with argparse")
>>
>> Reported-by: Jiang, YuX 
>> Signed-off-by: Chengwen Feng 
>> ---
>>  examples/dma/dmafwd.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/examples/dma/dmafwd.c b/examples/dma/dmafwd.c index
>> f4a0bff06e..acceae6b7b 100644
>> --- a/examples/dma/dmafwd.c
>> +++ b/examples/dma/dmafwd.c
>> @@ -695,23 +695,23 @@ dma_parse_args(int argc, char **argv, unsigned int
>> nb_ports)
>>  return ret;
>>
>>  /* check argument's value which parsing by autosave. */
>> -if (dma_batch_sz <= 0 || dma_batch_sz > MAX_PKT_BURST) {
>> +if (dma_batch_sz == 0 || dma_batch_sz > MAX_PKT_BURST) {
>>  printf("Invalid dma batch size, %d.\n", dma_batch_sz);
>>  return -1;
>>  }
>>
>> -if (max_frame_size <= 0 || max_frame_size >
>> RTE_ETHER_MAX_JUMBO_FRAME_LEN) {
>> +if (max_frame_size > RTE_ETHER_MAX_JUMBO_FRAME_LEN) {
>>  printf("Invalid max frame size, %d.\n", max_frame_size);
>>  return -1;
>>  }
>>
>> -if (nb_queues <= 0 || nb_queues > MAX_RX_QUEUES_COUNT) {
>> +if (nb_queues == 0 || nb_queues > MAX_RX_QUEUES_COUNT) {
>>  printf("Invalid RX queues number %d. Max %u\n",
>>  nb_queues, MAX_RX_QUEUES_COUNT);
>>  return -1;
>>  }
>>
>> -if (ring_size <= 0) {
>> +if (ring_size == 0) {
>>  printf("Invalid ring size, %d.\n", ring_size);
>>  return -1;
>>  }
>> @@ -721,7 +721,7 @@ dma_parse_args(int argc, char **argv, unsigned int
>> nb_ports)
>>  ring_size = MBUF_RING_SIZE;
>>  }
>>
>> -if (stats_interval <= 0) {
>> +if (stats_interval == 0) {
>>  printf("Invalid stats interval, setting to 1\n");
>>  stats_interval = 1; /* set to default */
>>  }
>> --
>> 2.17.1
> 
> Tested-by:  Yu Jiang 
> 
> Best regards,
> Yu Jiang
> .
> 

[PATCH] common/qat: fix undefined macro

[Ciara Power]

When using RTE_ENABLE_ASSERT and debug mode, an undefined
macro error appeared for ICP_QAT_FW_SYM_COMM_ADDR_SGL.
This was not being defined, but is now added to the header file.

Bugzilla ID: 1395
Fixes: e9271821e489 ("common/qat: support GEN LCE device")

Signed-off-by: Ciara Power 

---
Cc: nishikanta.na...@intel.com
---
 drivers/common/qat/qat_adf/icp_qat_fw_la.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_la.h 
b/drivers/common/qat/qat_adf/icp_qat_fw_la.h
index 67fc25c919..fe32b66c50 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw_la.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw_la.h
@@ -111,6 +111,7 @@ struct icp_qat_fw_la_bulk_req {
 #define ICP_QAT_FW_SYM_IV_IN_DESC_VALID 1
 #define ICP_QAT_FW_SYM_DIRECTION_BITPOS 15
 #define ICP_QAT_FW_SYM_DIRECTION_MASK 0x1
+#define ICP_QAT_FW_SYM_COMM_ADDR_SGL 1
 
 /* In GEN_LCE AEAD AES GCM Algorithm has ID 0 */
 #define QAT_LA_CRYPTO_AEAD_AES_GCM_GEN_LCE 0
-- 
2.25.1

RE: [PATCH] common/qat: fix undefined macro

[Nayak, Nishikanta]

> -Original Message-
> From: Power, Ciara 
> Sent: Tuesday, March 5, 2024 5:26 PM
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Power, Ciara ; Nayak,
> Nishikanta ; Ji, Kai 
> Subject: [PATCH] common/qat: fix undefined macro
> 
> When using RTE_ENABLE_ASSERT and debug mode, an undefined macro
> error appeared for ICP_QAT_FW_SYM_COMM_ADDR_SGL.
> This was not being defined, but is now added to the header file.
> 
> Bugzilla ID: 1395
> Fixes: e9271821e489 ("common/qat: support GEN LCE device")
> 
> Signed-off-by: Ciara Power 
> 
> ---
> Cc: nishikanta.na...@intel.com
> ---
>  drivers/common/qat/qat_adf/icp_qat_fw_la.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/common/qat/qat_adf/icp_qat_fw_la.h
> b/drivers/common/qat/qat_adf/icp_qat_fw_la.h
> index 67fc25c919..fe32b66c50 100644
> --- a/drivers/common/qat/qat_adf/icp_qat_fw_la.h
> +++ b/drivers/common/qat/qat_adf/icp_qat_fw_la.h
> @@ -111,6 +111,7 @@ struct icp_qat_fw_la_bulk_req {  #define
> ICP_QAT_FW_SYM_IV_IN_DESC_VALID 1  #define
> ICP_QAT_FW_SYM_DIRECTION_BITPOS 15  #define
> ICP_QAT_FW_SYM_DIRECTION_MASK 0x1
> +#define ICP_QAT_FW_SYM_COMM_ADDR_SGL 1
> 
>  /* In GEN_LCE AEAD AES GCM Algorithm has ID 0 */  #define
> QAT_LA_CRYPTO_AEAD_AES_GCM_GEN_LCE 0
> --
> 2.25.1

Acked-by: Nishikant Nayak 

RE: [PATCH] test/crypto: fix non ASCII character

[Ali Alnubani]

> -Original Message-
> From: Anoob Joseph 
> Sent: Tuesday, March 5, 2024 1:34 PM
> To: Akhil Goyal ; David Marchand
> 
> Cc: Aakash Sasidharan ; dev@dpdk.org
> Subject: [PATCH] test/crypto: fix non ASCII character
> 
> Fix non ASCII character in the comment. Revert to original text.
> 
> Bugzilla ID: 1396
> Fixes: f97c63f4f445 ("test/crypto: add AES-GCM external mbuf case")
> 
> Signed-off-by: Anoob Joseph 
> ---

Build passes with this patch, thanks!

Tested-by: Ali Alnubani 

Re: [PATCH] argparse: add version in symbols map

[David Marchand]

On Tue, Mar 5, 2024 at 12:35 PM fengchengwen  wrote:
>
> Acked-by: Chengwen Feng 
>
> BTW: which tool detects this problem?

I found out about those issues while manually inspecting the changes
on **/version.map since v23.11.

At the moment, there is no tool enforcing that experimental symbols
must be in a block with a version comment.

Adding a check could be done:

$ git diff
diff --git a/buildtools/map-list-symbol.sh b/buildtools/map-list-symbol.sh
index a834399816..b76e2417c5 100755
--- a/buildtools/map-list-symbol.sh
+++ b/buildtools/map-list-symbol.sh
@@ -61,8 +61,12 @@ for file in $@; do
if (current_section == "") {
next;
}
-   if ("'$version'" != "" && "'$version'" != current_version) {
-   next;
+   if ("'$version'" != "") {
+   if ("'$version'" == "unset" && current_version != "") {
+   next;
+   } else if ("'$version'" != "unset" &&
"'$version'" != current_version) {
+   next;
+   }
}
gsub(";","");
if ("'$symbol'" == "all" || $1 == "'$symbol'") {


And it catches more issues:
$ find lib -name 'version.map' -exec ./buildtools/map-list-symbol.sh
-S EXPERIMENTAL -V unset {} \;
lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_encode_json_format
lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_reg_all_ethdev
lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_get_global_stats
lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_get_port_stats_ids
lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_get_ports_stats_json
lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_extract_data
lib/regexdev/version.map EXPERIMENTAL rte_regex_devices
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_attr_get
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_attr_set
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_close
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_configure
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_count
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_dequeue_burst
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_dump
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_enqueue_burst
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_get_dev_id
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_info_get
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_is_valid_dev
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_logtype
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_queue_pair_setup
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_compile_activate
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_export
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_import
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_update
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_selftest
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_start
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_stop
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_by_name_get
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_get
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_names_get
lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_reset
lib/reorder/version.map EXPERIMENTAL rte_reorder_seqn_dynfield_offset
lib/mldev/version.map EXPERIMENTAL rte_ml_dequeue_burst
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_close
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_configure
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_count
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_dump
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_info_get
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_init
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_is_valid_dev
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_logtype
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_queue_pair_setup
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_selftest
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_socket_id
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_start
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_stats_get
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_stats_reset
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_stop
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_by_name_get
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_get
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_names_get
lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_reset
lib/mldev/version.map EXPERIMENTAL rte_ml_enqueue_burst
lib/mldev/version.map EXPERIMENTAL rte_ml_io_dequantize
lib/mldev/version.map EXPERIMENTAL rte_ml_io_quantize
lib/mldev/version.map EXPERIMENTAL rte_ml_model_info_get
lib/mldev/version.map EXPERIMENTAL rte_ml_model_load
lib/mldev/version.map EXPERIMENTAL rte_ml_model_params_update
lib/mldev/version.map EXPERIMENTAL rte_ml_model_start
lib/mldev/version.map EXPERIMENTAL rte_ml_model_stop
lib/mldev/vers

RE: [PATCH] common/qat: fix undefined macro

[Ali Alnubani]

> -Original Message-
> From: Ciara Power 
> Sent: Tuesday, March 5, 2024 1:56 PM
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Ciara Power ;
> nishikanta.na...@intel.com; Kai Ji 
> Subject: [PATCH] common/qat: fix undefined macro
> 
> When using RTE_ENABLE_ASSERT and debug mode, an undefined
> macro error appeared for ICP_QAT_FW_SYM_COMM_ADDR_SGL.
> This was not being defined, but is now added to the header file.
> 
> Bugzilla ID: 1395
> Fixes: e9271821e489 ("common/qat: support GEN LCE device")
> 
> Signed-off-by: Ciara Power 
> 
> ---

Can confirm it resolves the build failure, thanks!

Tested-by: Ali Alnubani 

Re: [PATCH] examples/dma: fix max-frame-size cannot be zero

[Thomas Monjalon]

05/03/2024 12:42, fengchengwen:
> Hi Thomas,
> 
> This commit fix bug "Bug 1387 - [dpdk24.03] cbdma: Failed to launch dpdk-dma 
> app" [1]
> 
> Should I send v2 to add the following line in commit log?
> Bugzilla ID: 1387

I can add it while merging.

Re: [PATCH v7] net/i40e: add diagnostic support in Tx path

[Bruce Richardson]

On Tue, Mar 05, 2024 at 10:17:47AM +, Mingjin Ye wrote:
> Implemented a Tx wrapper to perform a thorough check on mbufs,
> categorizing and counting invalid cases by type for diagnostic
> purposes. The count of invalid cases is accessible through xstats_get.
> 
> Also, the devarg option "mbuf_check" was introduced to configure the
> diagnostic parameters to enable the appropriate diagnostic features.
> 
> supported cases: mbuf, size, segment, offload.
>  1. mbuf: Check for corrupted mbuf.
>  2. size: Check min/max packet length according to HW spec.
>  3. segment: Check number of mbuf segments not exceed HW limits.
>  4. offload: Check for use of an unsupported offload flag.
> 
> parameter format: "mbuf_check=" or "mbuf_check=[,]"
> eg: dpdk-testpmd -a :87:00.0,mbuf_check=[mbuf,size] -- -i
> 
> Signed-off-by: Mingjin Ye 
> ---
Acked-by: Bruce Richardson 

Applied to dpdk-next-net-intel with some indentation and whitespace
cleanup.

Thanks,
/Bruce

[PATCH 1/2] net/mlx5: update speed capabilities parsing on Linux

[Thomas Monjalon]

Ease maintenance of speed capabilities parsing from ethtool
by using rte_eth_link_speed_g*().
Functions in ethdev library are simpler, more complete,
and easier to maintain.

Signed-off-by: Thomas Monjalon 
---
 drivers/common/mlx5/linux/meson.build   |  22 
 drivers/net/mlx5/linux/mlx5_ethdev_os.c | 150 ++--
 2 files changed, 7 insertions(+), 165 deletions(-)

diff --git a/drivers/common/mlx5/linux/meson.build 
b/drivers/common/mlx5/linux/meson.build
index b3a64547c5..cdee40c553 100644
--- a/drivers/common/mlx5/linux/meson.build
+++ b/drivers/common/mlx5/linux/meson.build
@@ -146,28 +146,6 @@ has_sym_args = [
 'MLX5_OPCODE_WAIT' ],
 [ 'HAVE_MLX5_OPCODE_ACCESS_ASO', 'infiniband/mlx5dv.h',
 'MLX5_OPCODE_ACCESS_ASO' ],
-[ 'HAVE_SUPPORTED_4baseKR4_Full', 'linux/ethtool.h',
-'SUPPORTED_4baseKR4_Full' ],
-[ 'HAVE_SUPPORTED_4baseCR4_Full', 'linux/ethtool.h',
-'SUPPORTED_4baseCR4_Full' ],
-[ 'HAVE_SUPPORTED_4baseSR4_Full', 'linux/ethtool.h',
-'SUPPORTED_4baseSR4_Full' ],
-[ 'HAVE_SUPPORTED_4baseLR4_Full', 'linux/ethtool.h',
-'SUPPORTED_4baseLR4_Full' ],
-[ 'HAVE_SUPPORTED_56000baseKR4_Full', 'linux/ethtool.h',
-'SUPPORTED_56000baseKR4_Full' ],
-[ 'HAVE_SUPPORTED_56000baseCR4_Full', 'linux/ethtool.h',
-'SUPPORTED_56000baseCR4_Full' ],
-[ 'HAVE_SUPPORTED_56000baseSR4_Full', 'linux/ethtool.h',
-'SUPPORTED_56000baseSR4_Full' ],
-[ 'HAVE_SUPPORTED_56000baseLR4_Full', 'linux/ethtool.h',
-'SUPPORTED_56000baseLR4_Full' ],
-[ 'HAVE_ETHTOOL_LINK_MODE_25G', 'linux/ethtool.h',
-'ETHTOOL_LINK_MODE_25000baseCR_Full_BIT' ],
-[ 'HAVE_ETHTOOL_LINK_MODE_50G', 'linux/ethtool.h',
-'ETHTOOL_LINK_MODE_5baseCR2_Full_BIT' ],
-[ 'HAVE_ETHTOOL_LINK_MODE_100G', 'linux/ethtool.h',
-'ETHTOOL_LINK_MODE_10baseKR4_Full_BIT' ],
 [ 'HAVE_IFLA_NUM_VF', 'linux/if_link.h',
 'IFLA_NUM_VF' ],
 [ 'HAVE_IFLA_EXT_MASK', 'linux/if_link.h',
diff --git a/drivers/net/mlx5/linux/mlx5_ethdev_os.c 
b/drivers/net/mlx5/linux/mlx5_ethdev_os.c
index dd5a0c546d..25e6bbd694 100644
--- a/drivers/net/mlx5/linux/mlx5_ethdev_os.c
+++ b/drivers/net/mlx5/linux/mlx5_ethdev_os.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -45,91 +46,6 @@
 #include "mlx5_rxtx.h"
 #include "mlx5_utils.h"
 
-/* Supported speed values found in /usr/include/linux/ethtool.h */
-#ifndef HAVE_SUPPORTED_4baseKR4_Full
-#define SUPPORTED_4baseKR4_Full (1 << 23)
-#endif
-#ifndef HAVE_SUPPORTED_4baseCR4_Full
-#define SUPPORTED_4baseCR4_Full (1 << 24)
-#endif
-#ifndef HAVE_SUPPORTED_4baseSR4_Full
-#define SUPPORTED_4baseSR4_Full (1 << 25)
-#endif
-#ifndef HAVE_SUPPORTED_4baseLR4_Full
-#define SUPPORTED_4baseLR4_Full (1 << 26)
-#endif
-#ifndef HAVE_SUPPORTED_56000baseKR4_Full
-#define SUPPORTED_56000baseKR4_Full (1 << 27)
-#endif
-#ifndef HAVE_SUPPORTED_56000baseCR4_Full
-#define SUPPORTED_56000baseCR4_Full (1 << 28)
-#endif
-#ifndef HAVE_SUPPORTED_56000baseSR4_Full
-#define SUPPORTED_56000baseSR4_Full (1 << 29)
-#endif
-#ifndef HAVE_SUPPORTED_56000baseLR4_Full
-#define SUPPORTED_56000baseLR4_Full (1 << 30)
-#endif
-
-/* Add defines in case the running kernel is not the same as user headers. */
-#ifndef ETHTOOL_GLINKSETTINGS
-struct ethtool_link_settings {
-   uint32_t cmd;
-   uint32_t speed;
-   uint8_t duplex;
-   uint8_t port;
-   uint8_t phy_address;
-   uint8_t autoneg;
-   uint8_t mdio_support;
-   uint8_t eth_to_mdix;
-   uint8_t eth_tp_mdix_ctrl;
-   int8_t link_mode_masks_nwords;
-   uint32_t reserved[8];
-   uint32_t link_mode_masks[];
-};
-
-/* The kernel values can be found in /include/uapi/linux/ethtool.h */
-#define ETHTOOL_GLINKSETTINGS 0x004c
-#define ETHTOOL_LINK_MODE_1000baseT_Full_BIT 5
-#define ETHTOOL_LINK_MODE_Autoneg_BIT 6
-#define ETHTOOL_LINK_MODE_1000baseKX_Full_BIT 17
-#define ETHTOOL_LINK_MODE_1baseKX4_Full_BIT 18
-#define ETHTOOL_LINK_MODE_1baseKR_Full_BIT 19
-#define ETHTOOL_LINK_MODE_1baseR_FEC_BIT 20
-#define ETHTOOL_LINK_MODE_2baseMLD2_Full_BIT 21
-#define ETHTOOL_LINK_MODE_2baseKR2_Full_BIT 22
-#define ETHTOOL_LINK_MODE_4baseKR4_Full_BIT 23
-#define ETHTOOL_LINK_MODE_4baseCR4_Full_BIT 24
-#define ETHTOOL_LINK_MODE_4baseSR4_Full_BIT 25
-#define ETHTOOL_LINK_MODE_4baseLR4_Full_BIT 26
-#define ETHTOOL_LINK_MODE_56000baseKR4_Full_BIT 27
-#define ETHTOOL_LINK_MODE_56000baseCR4_Full_BIT 28
-#define ETHTOOL_LINK_MODE_56000baseSR4_Full_BIT 29
-#define ETHTOOL_LINK_MODE_56000baseLR4_Full_BIT 30
-#endif
-#ifndef HAVE_ETHTOOL_LINK_MODE_25G
-#define ETHTOOL_LINK_MODE_25000baseCR_Full_BIT 31
-#define ETHTOOL_LINK_MODE_25000baseKR_Full_BIT 32
-#define ETHTOOL_LINK_MODE_25000baseSR_Full_

[PATCH 2/2] net/mlx5: apply default tuning to future speeds

[Thomas Monjalon]

Some default parameters for number of queues and ring size
are different starting with 100G speed capability.

Instead of checking all speed above 100G, make sure it is applied
for any speed capability newer than 100G (including 400G for instance).

Signed-off-by: Thomas Monjalon 
---
 drivers/net/mlx5/mlx5_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index fb6d9d28ba..aea799341c 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -242,8 +242,8 @@ mlx5_set_default_params(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->default_txportconf.ring_size = 256;
info->default_rxportconf.burst_size = MLX5_RX_DEFAULT_BURST;
info->default_txportconf.burst_size = MLX5_TX_DEFAULT_BURST;
-   if ((priv->link_speed_capa & RTE_ETH_LINK_SPEED_200G) |
-   (priv->link_speed_capa & RTE_ETH_LINK_SPEED_100G)) {
+   if (priv->link_speed_capa >> rte_bsf32(RTE_ETH_LINK_SPEED_100G)) {
+   /* if supports at least 100G */
info->default_rxportconf.nb_queues = 16;
info->default_txportconf.nb_queues = 16;
if (dev->data->nb_rx_queues > 2 ||
-- 
2.43.0

DPDK Release Status Meeting 2024-02-29

[Mcnamara, John]

Release status meeting minutes 2024-02-29
=

Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens

Participants:
* AMD
* ARM
* Intel
* Marvell
* Nvidia
* Red Hat

Release Dates
-

The following are the current/updated working dates for 24.03:

* V1:  29 December 2023
* RC1: 21 February 2024
* RC2:  4 March2024
* RC3: 11 March2024
* Release: 20 March2024

https://core.dpdk.org/roadmap/#dates


Subtrees


* next-net
  * Testpmd patch from Napatech.
  * AF_XDP update and docs.

* next-net-intel
  * Some additions/fixes for RC2.

* next-net-mlx
  * Mainly merged for RC2.

* next-net-mvl
  * 40 patches to merge for RC2.

* next-eventdev
  * Bruce patches reviewed. Good to merge.
  * Prepping for RC2.

* next-baseband
  * PR for RC1 was reworked for RC2.

* next-virtio
  * Prepping for RC2.

* next-crypto
  * Merged for RC1.
  * ~ 35 patches for RC2.
  * There is a new Ionic driver. Probably will be postponed to next release.
* main
  * Windows series being reviewed.

  * Proposed 24.03 dates:
* RC2:  4 March 2024
* RC3: 11 March 2024
* Release: 20 March 2024

LTS
---

* 22.11.4 - Released.
* 21.11.6 - Released.
* 20.11.10 - Released.
* 19.11.15 - Will only be updated with CVE and critical fixes.


* Distros
  * Debian 12 contains DPDK v22.11
  * Ubuntu 22.04-LTS contains DPDK v21.11
  * Ubuntu 23.04 contains DPDK v22.11

Defects
---

* Bugzilla links, 'Bugs',  added for hosted projects
  * https://www.dpdk.org/hosted-projects/



DPDK Release Status Meetings


The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.

The meeting occurs on every Thursday at 9:30 UTC over Jitsi on 
https://meet.jit.si/DPDK

You don't need an invite to join the meeting but if you want a calendar 
reminder just
send an email to "John McNamara john.mcnam...@intel.com" for the invite.

Re: [PATCH] common/qat: fix undefined macro

[Thomas Monjalon]

05/03/2024 13:15, Ali Alnubani:
> > -Original Message-
> > From: Ciara Power 
> > Sent: Tuesday, March 5, 2024 1:56 PM
> > To: dev@dpdk.org
> > Cc: gak...@marvell.com; Ciara Power ;
> > nishikanta.na...@intel.com; Kai Ji 
> > Subject: [PATCH] common/qat: fix undefined macro
> > 
> > When using RTE_ENABLE_ASSERT and debug mode, an undefined
> > macro error appeared for ICP_QAT_FW_SYM_COMM_ADDR_SGL.
> > This was not being defined, but is now added to the header file.
> > 
> > Bugzilla ID: 1395
> > Fixes: e9271821e489 ("common/qat: support GEN LCE device")
> > 
> > Signed-off-by: Ciara Power 
> > 
> > ---
> 
> Can confirm it resolves the build failure, thanks!
> 
> Tested-by: Ali Alnubani 

Reported-by: Ali Alnubani 

Applied, thanks.

RE: [PATCH 00/21] Improvements and new test cases

[Anoob Joseph]

> Subject: [PATCH 00/21] Improvements and new test cases
> 
> Adding new test cases and improvements to test application.
> 
> Aakash Sasidharan (7):
>   test/security: enable AES-GCM in combined mode TLS
>   test/security: add TLS 1.2 data walkthrough test
>   test/security: add DTLS 1.2 data walkthrough test
>   test/security: add TLS SG data walkthrough test
>   test/security: add DTLS 1.2 anti-replay tests
>   test/security: add more DTLS anti-replay window sz
>   test/security: add out of place sgl test case for TLS 1.2
> 
> Akhil Goyal (2):
>   test/security: add TLS/DTLS 1.2 AES-256-SHA384 vectors
>   test/crypto: add TLS 1.3 vectors
> 
> Anoob Joseph (1):
>   test/cryptodev: allow zero packet length buffers
> 
> Vidya Sagar Velumuri (11):
>   test/security: unit test for TLS packet corruption
>   test/security: unit test for custom content verification
>   test/security: unit test to verify zero TLS records
>   test/security: add unit tests for DTLS-1.2
>   test/crypto: update verification of header
>   test/crypto: update framework to verify tls-1.3
>   test/crypto: test to verify hdr corruption in TLS
>   test/crypto: test to verify custom content type in TLS
>   test/crypto: test to verify zero len record in TLS
>   test/crypto: unit tests to verify padding in TLS
>   test/crypto: unit tests for padding in DTLS-1.2
> 
>  app/test/test_cryptodev.c | 975 --
>  app/test/test_cryptodev.h |  32 +-
>  app/test/test_cryptodev_security_tls_record.c | 203 ++--
> app/test/test_cryptodev_security_tls_record.h |  77 +-
> ...yptodev_security_tls_record_test_vectors.h | 405 
>  app/test/test_security_proto.c|  17 +
>  app/test/test_security_proto.h|   9 +
>  7 files changed, 1539 insertions(+), 179 deletions(-)
> 
> --
> 2.25.1


Series Acked-by: Anoob Joseph 


<>

Re: [PATCH] test/crypto: fix non ASCII character

[Thomas Monjalon]

05/03/2024 13:14, Ali Alnubani:
> > Subject: [PATCH] test/crypto: fix non ASCII character
> > 
> > Fix non ASCII character in the comment. Revert to original text.
> > 
> > Bugzilla ID: 1396
> > Fixes: f97c63f4f445 ("test/crypto: add AES-GCM external mbuf case")
> > 
> > Signed-off-by: Anoob Joseph 
> > ---
> 
> Build passes with this patch, thanks!
> 
> Tested-by: Ali Alnubani 

Reported-by: Ali Alnubani 

Applied, thanks.


The script buildtools/get-test-suites.py is not tolerant with Unicode.
We may be more flexible probably.
Bruce, Robin, what do you think about allowing Unicode characters in this 
script?

Re: [PATCH] test/crypto: fix non ASCII character

[David Marchand]

On Tue, Mar 5, 2024 at 2:25 PM Thomas Monjalon  wrote:
>
> 05/03/2024 13:14, Ali Alnubani:
> > > Subject: [PATCH] test/crypto: fix non ASCII character
> > >
> > > Fix non ASCII character in the comment. Revert to original text.
> > >
> > > Bugzilla ID: 1396
> > > Fixes: f97c63f4f445 ("test/crypto: add AES-GCM external mbuf case")
> > >
> > > Signed-off-by: Anoob Joseph 
> > > ---
> >
> > Build passes with this patch, thanks!
> >
> > Tested-by: Ali Alnubani 
>
> Reported-by: Ali Alnubani 
>
> Applied, thanks.
>
>
> The script buildtools/get-test-suites.py is not tolerant with Unicode.
> We may be more flexible probably.
> Bruce, Robin, what do you think about allowing Unicode characters in this 
> script?

Note: I could reproduce this issue with a Ubuntu 18.04 container, but
not with my fedora 38.
Maybe something to do with a python version.. ?


-- 
David Marchand

Re: [PATCH] vhost: fix vring addr update with vDPA

[David Marchand]

On Tue, Mar 5, 2024 at 10:13 AM David Marchand
 wrote:
>
> For vDPA devices, vq are not locked once the device has been configured
> at runtime.
>
> On the other hand, we need to hold the vq lock to evaluate vq->access_ok,
> invalidate vring addresses and translate them.
>
> Move vring address update earlier and, when vDPA is configured, skip parts
> which expect lock to be taken.
>
> Bugzilla ID: 1394
> Fixes: 741dc052eaf9 ("vhost: annotate virtqueue access checks")
>
> Signed-off-by: David Marchand 

Recheck-request: iol-testing


-- 
David Marchand

Re: [PATCH] test/crypto: fix non ASCII character

[Robin Jarry]

David Marchand, Mar 05, 2024 at 14:27:

> The script buildtools/get-test-suites.py is not tolerant with Unicode.
> We may be more flexible probably.
> Bruce, Robin, what do you think about allowing Unicode characters in this 
script?

Note: I could reproduce this issue with a Ubuntu 18.04 container, but
not with my fedora 38.
Maybe something to do with a python version.. ?


The files are opened without specifying an encoding. So it depends on 
the LC_ALL environment variable.


https://git.dpdk.org/dpdk/tree/buildtools/get-test-suites.py#n22

I will send a patch to fix this.

[PATCH] tests: assume c source files are utf-8 encoded

[Robin Jarry]

Instead of relying on the default locale from the environment (LC_ALL),
explicitly read the files as utf-8 encoded.

Fixes: 0aeaf75df879 ("test: define unit tests suites based on test types")

Signed-off-by: Robin Jarry 
---
 buildtools/get-test-suites.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildtools/get-test-suites.py b/buildtools/get-test-suites.py
index 574c233aa873..c61f6a273fad 100644
--- a/buildtools/get-test-suites.py
+++ b/buildtools/get-test-suites.py
@@ -19,7 +19,7 @@ def get_fast_test_params(test_name, ln):
 return f":{nohuge.strip().lower()}:{asan.strip().lower()}"
 
 for fname in input_list:
-with open(fname) as f:
+with open(fname, "r", encoding="utf-8") as f:
 contents = [ln.strip() for ln in f.readlines()]
 test_lines = [ln for ln in contents if test_def_regex.match(ln)]
 non_suite_tests.extend([non_suite_regex.match(ln).group(1)
-- 
2.44.0

Re: [PATCH v4] net/ice: add diagnostic support in Tx path

[Bruce Richardson]

On Tue, Mar 05, 2024 at 10:18:42AM +, Mingjin Ye wrote:
> Implemented a Tx wrapper to perform a thorough check on mbufs,
> categorizing and counting invalid cases by type for diagnostic
> purposes. The count of invalid cases is accessible through xstats_get.
> 
> Also, the devarg option "mbuf_check" was introduced to configure the
> diagnostic parameters to enable the appropriate diagnostic features.
> 
> supported cases: mbuf, size, segment, offload.
>  1. mbuf: Check for corrupted mbuf.
>  2. size: Check min/max packet length according to HW spec.
>  3. segment: Check number of mbuf segments not exceed HW limits.
>  4. offload: Check for use of an unsupported offload flag.
> 
> parameter format: "mbuf_check=" or "mbuf_check=[,]"
> eg: dpdk-testpmd -a :81:00.0,mbuf_check=[mbuf,size] -- -i
> 
> Signed-off-by: Mingjin Ye 
> ---
Acked-by: Bruce Richardson 

Applied to dpdk-next-net-intel with some whitespace/indent fixups.

Thanks,
/Bruce

Re: [PATCH] tests: assume c source files are utf-8 encoded

[Bruce Richardson]

On Tue, Mar 05, 2024 at 02:46:15PM +0100, Robin Jarry wrote:
> Instead of relying on the default locale from the environment (LC_ALL),
> explicitly read the files as utf-8 encoded.
> 
> Fixes: 0aeaf75df879 ("test: define unit tests suites based on test types")
> 
> Signed-off-by: Robin Jarry 
> ---
Acked-by: Bruce Richardson 

Thanks for the update/fix.

[PATCH] devtools: require version for experimental symbols

[David Marchand]

Add version to all symbols maps and a check so any experimental symbol
is versioned.

Signed-off-by: David Marchand 
---
 buildtools/map-list-symbol.sh  |  8 ++--
 devtools/check-symbol-maps.sh  | 15 +++
 doc/guides/contributing/abi_policy.rst | 17 -
 drivers/baseband/acc/version.map   |  1 +
 drivers/baseband/fpga_5gnr_fec/version.map |  1 +
 drivers/baseband/fpga_lte_fec/version.map  |  2 +-
 drivers/bus/pci/version.map|  1 +
 drivers/dma/dpaa2/version.map  |  3 +++
 drivers/event/dlb2/version.map |  1 +
 drivers/mempool/cnxk/version.map   |  2 ++
 drivers/net/atlantic/version.map   |  1 +
 drivers/net/i40e/version.map   |  7 ++-
 drivers/net/ixgbe/version.map  |  1 +
 lib/argparse/version.map   |  1 +
 lib/metrics/version.map|  2 +-
 lib/mldev/version.map  |  1 +
 lib/regexdev/version.map   |  9 ++---
 lib/reorder/version.map|  2 ++
 18 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/buildtools/map-list-symbol.sh b/buildtools/map-list-symbol.sh
index a834399816..b76e2417c5 100755
--- a/buildtools/map-list-symbol.sh
+++ b/buildtools/map-list-symbol.sh
@@ -61,8 +61,12 @@ for file in $@; do
if (current_section == "") {
next;
}
-   if ("'$version'" != "" && "'$version'" != current_version) {
-   next;
+   if ("'$version'" != "") {
+   if ("'$version'" == "unset" && current_version != "") {
+   next;
+   } else if ("'$version'" != "unset" && "'$version'" != 
current_version) {
+   next;
+   }
}
gsub(";","");
if ("'$symbol'" == "all" || $1 == "'$symbol'") {
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index ba2f892f56..6121f78ec6 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -97,4 +97,19 @@ if [ -n "$bad_format_maps" ] ; then
 ret=1
 fi
 
+find_non_versioned_maps ()
+{
+for map in $@ ; do
+[ $(buildtools/map-list-symbol.sh -S EXPERIMENTAL -V unset $map | wc 
-l) = '0' ] ||
+echo $map
+done
+}
+
+non_versioned_maps=$(find_non_versioned_maps $@)
+if [ -n "$non_versioned_maps" ] ; then
+echo "Found non versioned maps:"
+echo "$non_versioned_maps"
+ret=1
+fi
+
 exit $ret
diff --git a/doc/guides/contributing/abi_policy.rst 
b/doc/guides/contributing/abi_policy.rst
index 5fd4052585..3c4478692a 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -331,7 +331,22 @@ become part of a tracked ABI version.
 Note that marking an API as experimental is a multi step process.
 To mark an API as experimental, the symbols which are desired to be exported
 must be placed in an EXPERIMENTAL version block in the corresponding libraries'
-version map script.
+version map script. Experimental symbols must be commented so
+that it is clear in which DPDK version they were introduced.
+
+.. code-block:: none
+
+ EXPERIMENTAL {
+global:
+
+# added in 20.11
+rte_foo_init;
+rte_foo_configure;
+
+# added in 21.02
+rte_foo_cleanup;
+ ...
+
 Secondly, the corresponding prototypes of those exported functions (in the
 development header files), must be marked with the ``__rte_experimental`` tag
 (see ``rte_compat.h``).
diff --git a/drivers/baseband/acc/version.map b/drivers/baseband/acc/version.map
index 1b6b1cd10d..fa39a63f0f 100644
--- a/drivers/baseband/acc/version.map
+++ b/drivers/baseband/acc/version.map
@@ -5,5 +5,6 @@ DPDK_24 {
 EXPERIMENTAL {
global:
 
+   # added in 22.11
rte_acc_configure;
 };
diff --git a/drivers/baseband/fpga_5gnr_fec/version.map 
b/drivers/baseband/fpga_5gnr_fec/version.map
index 2da20cabc1..855ce55703 100644
--- a/drivers/baseband/fpga_5gnr_fec/version.map
+++ b/drivers/baseband/fpga_5gnr_fec/version.map
@@ -5,6 +5,7 @@ DPDK_24 {
 EXPERIMENTAL {
global:
 
+   # added in 20.11
rte_fpga_5gnr_fec_configure;
 
 };
diff --git a/drivers/baseband/fpga_lte_fec/version.map 
b/drivers/baseband/fpga_lte_fec/version.map
index 83f3a8a267..2c8e60375d 100644
--- a/drivers/baseband/fpga_lte_fec/version.map
+++ b/drivers/baseband/fpga_lte_fec/version.map
@@ -5,6 +5,6 @@ DPDK_24 {
 EXPERIMENTAL {
global:
 
+   # added in 20.11
rte_fpga_lte_fec_configure;
-
 };
diff --git a/drivers/bus/pci/version.map b/drivers/bus/pci/version.map
index 9e4d8f5e54..5d9dced5b2 100644
--- a/drivers/bus/pci/version.map
+++ b/drivers/bus/pci/version.map
@@ -17,6 +17,7 @@ DPDK_24 {
 EXPERIMENTAL {
global:
 
+   # added in 20.11
rte_pci_find_ext_capability;

RE: [PATCH] tests: assume c source files are utf-8 encoded

[Morten Brørup]

> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Tuesday, 5 March 2024 14.46
> 
> Instead of relying on the default locale from the environment (LC_ALL),
> explicitly read the files as utf-8 encoded.
> 
> Fixes: 0aeaf75df879 ("test: define unit tests suites based on test types")
> 
> Signed-off-by: Robin Jarry 
> ---

I strongly agree on UTF-8 encoding everywhere in the DPDK project, so...

Acked-by: Morten Brørup 

Re: [PATCH v7 08/39] mbuf: use C11 alignas

[David Marchand]

On Mon, Mar 4, 2024 at 6:54 PM Tyler Retzlaff
 wrote:
>
> The current location used for __rte_aligned(a) for alignment of types
> and variables is not compatible with MSVC. There is only a single
> location accepted by both toolchains.
>
> For variables standard C11 offers alignas(a) supported by conformant
> compilers i.e. both MSVC and GCC.
>
> For types the standard offers no alignment facility that compatibly
> interoperates with C and C++ but may be achieved by relocating the
> placement of __rte_aligned(a) to the aforementioned location accepted
> by all currently supported toolchains.
>
> To allow alignment for both compilers do the following:
>
> * Move __rte_aligned from the end of {struct,union} definitions to
>   be between {struct,union} and tag.
>
>   The placement between {struct,union} and the tag allows the desired
>   alignment to be imparted on the type regardless of the toolchain being
>   used for all of GCC, LLVM, MSVC compilers building both C and C++.
>
> * Replace use of __rte_aligned(a) on variables/fields with alignas(a).
>
> Signed-off-by: Tyler Retzlaff 
> Acked-by: Morten Brørup 
> Acked-by: Konstantin Ananyev 
> ---
>  lib/mbuf/rte_mbuf_core.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> index 5688683..917a811 100644
> --- a/lib/mbuf/rte_mbuf_core.h
> +++ b/lib/mbuf/rte_mbuf_core.h
> @@ -463,7 +463,7 @@ enum {
>  /**
>   * The generic rte_mbuf, containing a packet mbuf.
>   */
> -struct rte_mbuf {
> +struct __rte_cache_aligned rte_mbuf {
> RTE_MARKER cacheline0;
>
> void *buf_addr;   /**< Virtual address of segment buffer. */
> @@ -476,7 +476,7 @@ struct rte_mbuf {
>  * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
>  * working on vector drivers easier.
>  */
> -   rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> +   alignas(sizeof(rte_iova_t)) rte_iova_t buf_iova;
>  #else
> /**
>  * Next segment of scattered packet.
> @@ -662,7 +662,7 @@ struct rte_mbuf {
> uint16_t timesync;
>
> uint32_t dynfield1[9]; /**< Reserved for dynamic fields. */
> -} __rte_cache_aligned;
> +};

I probably missed the discussion, but why is cacheline1 not handled in
this patch?
I was expecting a:
-   RTE_MARKER cacheline1 __rte_cache_min_aligned;
+   alignas(RTE_CACHE_LINE_MIN_SIZE) RTE_MARKER cacheline1;


-- 
David Marchand

RE: [EXT] [PATCH] app/test: don't count skipped tests as executed

[Akhil Goyal]

> Subject: [EXT] [PATCH] app/test: don't count skipped tests as executed
> The logic around skipped tests is a little confusing in the unit test
> runner.
> * Any explicitly disabled tests are counted as skipped but not
>   executed.
> * Any tests that return TEST_SKIPPED are counted as both skipped and
>   executed, using the same statistics counters.
> 
> This makes the stats very strange and hard to correlate, since the
> totals don't add up.  One would expect that SKIPPED + EXECUTED +
> UNSUPPORTED == TOTAL, and that PASSED + FAILED == EXECUTED.
> 
> To achieve this, mark any tests returning TEST_SKIPPED, or ENOTSUP as
> not having executed.
> 
> Signed-off-by: Bruce Richardson 

Acked-by: Akhil Goyal 

Yes this makes sense.
One would say executed should count the unsupported cases as well.
But I think this makes sense to not include them in executed cases.
This would give better correlation.
Can we backport this as well?

Re: [PATCH] argparse: add version in symbols map

[David Marchand]

On Tue, Mar 5, 2024 at 1:14 PM David Marchand  wrote:
>
> On Tue, Mar 5, 2024 at 12:35 PM fengchengwen  wrote:
> >
> > Acked-by: Chengwen Feng 
> >
> > BTW: which tool detects this problem?
>
> I found out about those issues while manually inspecting the changes
> on **/version.map since v23.11.
>
> At the moment, there is no tool enforcing that experimental symbols
> must be in a block with a version comment.
>
> Adding a check could be done:
>
> $ git diff
> diff --git a/buildtools/map-list-symbol.sh b/buildtools/map-list-symbol.sh
> index a834399816..b76e2417c5 100755
> --- a/buildtools/map-list-symbol.sh
> +++ b/buildtools/map-list-symbol.sh
> @@ -61,8 +61,12 @@ for file in $@; do
> if (current_section == "") {
> next;
> }
> -   if ("'$version'" != "" && "'$version'" != current_version) {
> -   next;
> +   if ("'$version'" != "") {
> +   if ("'$version'" == "unset" && current_version != "") 
> {
> +   next;
> +   } else if ("'$version'" != "unset" &&
> "'$version'" != current_version) {
> +   next;
> +   }
> }
> gsub(";","");
> if ("'$symbol'" == "all" || $1 == "'$symbol'") {
>
>
> And it catches more issues:
> $ find lib -name 'version.map' -exec ./buildtools/map-list-symbol.sh
> -S EXPERIMENTAL -V unset {} \;
> lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_encode_json_format
> lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_reg_all_ethdev
> lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_get_global_stats
> lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_get_port_stats_ids
> lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_get_ports_stats_json
> lib/metrics/version.map EXPERIMENTAL rte_metrics_tel_extract_data
> lib/regexdev/version.map EXPERIMENTAL rte_regex_devices
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_attr_get
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_attr_set
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_close
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_configure
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_count
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_dequeue_burst
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_dump
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_enqueue_burst
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_get_dev_id
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_info_get
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_is_valid_dev
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_logtype
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_queue_pair_setup
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_compile_activate
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_export
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_import
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_rule_db_update
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_selftest
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_start
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_stop
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_by_name_get
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_get
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_names_get
> lib/regexdev/version.map EXPERIMENTAL rte_regexdev_xstats_reset
> lib/reorder/version.map EXPERIMENTAL rte_reorder_seqn_dynfield_offset
> lib/mldev/version.map EXPERIMENTAL rte_ml_dequeue_burst
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_close
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_configure
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_count
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_dump
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_info_get
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_init
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_is_valid_dev
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_logtype
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_queue_pair_setup
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_selftest
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_socket_id
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_start
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_stats_get
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_stats_reset
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_stop
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_by_name_get
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_get
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_names_get
> lib/mldev/version.map EXPERIMENTAL rte_ml_dev_xstats_reset
> lib/mldev/version.map EXPERIMENTAL rte_ml_enqueue_burst
> lib/mldev/version.map EXPERIMENTAL rte_ml_io_dequantize
> lib/mldev/version.map EXPERIMENTAL rte_ml_io_quantize
> lib/mldev/version.map EXPERIMENTAL rte_ml_model_

RE: [PATCH v4 2/2] doc: remove outdated version details

[Wathsala Wathawana Vithanage]

> Subject: [PATCH v4 2/2] doc: remove outdated version details
> 
> SW PMDs documentation is updated to remove details of unsupported IPsec
> Multi-buffer versions.DPDK older than 20.11 is end of life. So, older DPDK
> versions are removed from the Crypto library version table.
> 
> Signed-off-by: Sivaramakrishnan Venkat
> 
> Acked-by: Pablo de Lara 

Acked-by: Wathsala Vithanage 

> ---
>   v3:
> - added second patch for outdated documentation updates.
> ---
>  doc/guides/cryptodevs/aesni_gcm.rst | 19 +++---
>  doc/guides/cryptodevs/aesni_mb.rst  | 22 +++--
>  doc/guides/cryptodevs/chacha20_poly1305.rst | 12 ++-
>  doc/guides/cryptodevs/kasumi.rst| 14 +++--
>  doc/guides/cryptodevs/snow3g.rst| 15 +++---
>  doc/guides/cryptodevs/zuc.rst   | 15 +++---
>  6 files changed, 17 insertions(+), 80 deletions(-)
> 
> diff --git a/doc/guides/cryptodevs/aesni_gcm.rst
> b/doc/guides/cryptodevs/aesni_gcm.rst
> index dc665e536c..e38a03b78f 100644
> --- a/doc/guides/cryptodevs/aesni_gcm.rst
> +++ b/doc/guides/cryptodevs/aesni_gcm.rst
> @@ -62,12 +62,6 @@ Once it is downloaded, extract it and follow these
> steps:
>  make
>  make install
> 
> -.. note::
> -
> -   Compilation of the Multi-Buffer library is broken when GCC < 5.0, if 
> library
> <= v0.53.
> -   If a lower GCC version than 5.0, the workaround proposed by the following
> link
> -   should be used: ``_.
> -
> 
>  As a reference, the following table shows a mapping between the past DPDK
> versions  and the external crypto libraries supported by them:
> @@ -79,18 +73,11 @@ and the external crypto libraries supported by them:
> =  
> DPDK version   Crypto library version
> =  
> -   16.04 - 16.11  Multi-buffer library 0.43 - 0.44
> -   17.02 - 17.05  ISA-L Crypto v2.18
> -   17.08 - 18.02  Multi-buffer library 0.46 - 0.48
> -   18.05 - 19.02  Multi-buffer library 0.49 - 0.52
> -   19.05 - 20.08  Multi-buffer library 0.52 - 0.55
> -   20.11 - 21.08  Multi-buffer library 0.53 - 1.3*
> -   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
> -   24.03+ Multi-buffer library 1.4  - 1.5*
> +   20.11 - 21.08  Multi-buffer library 0.53 - 1.3
> +   21.11 - 23.11  Multi-buffer library 1.0  - 1.5
> +   24.03+ Multi-buffer library 1.4  - 1.5
> =  
> 
> -\* Multi-buffer library 1.0 or newer only works for Meson but not Make build
> system.
> -
>  Initialization
>  --
> 
> diff --git a/doc/guides/cryptodevs/aesni_mb.rst
> b/doc/guides/cryptodevs/aesni_mb.rst
> index 5d670ee237..bd7c8de07f 100644
> --- a/doc/guides/cryptodevs/aesni_mb.rst
> +++ b/doc/guides/cryptodevs/aesni_mb.rst
> @@ -121,12 +121,6 @@ Once it is downloaded, extract it and follow these
> steps:
>  make
>  make install
> 
> -.. note::
> -
> -   Compilation of the Multi-Buffer library is broken when GCC < 5.0, if 
> library
> <= v0.53.
> -   If a lower GCC version than 5.0, the workaround proposed by the following
> link
> -   should be used: ``_.
> -
>  As a reference, the following table shows a mapping between the past DPDK
> versions  and the Multi-Buffer library version supported by them:
> 
> @@ -137,21 +131,11 @@ and the Multi-Buffer library version supported by
> them:
> ==  
> DPDK versionMulti-buffer library version
> ==  
> -   2.2 - 16.11 0.43 - 0.44
> -   17.02   0.44
> -   17.05 - 17.08   0.45 - 0.48
> -   17.11   0.47 - 0.48
> -   18.02   0.48
> -   18.05 - 19.02   0.49 - 0.52
> -   19.05 - 19.08   0.52
> -   19.11 - 20.08   0.52 - 0.55
> -   20.11 - 21.08   0.53 - 1.3*
> -   21.11 - 23.11   1.0  - 1.5*
> -   24.03+  1.4  - 1.5*
> +   20.11 - 21.08   0.53 - 1.3
> +   21.11 - 23.11   1.0  - 1.5
> +   24.03+  1.4  - 1.5
> ==  
> 
> -\* Multi-buffer library 1.0 or newer only works for Meson but not Make build
> system.
> -
>  Initialization
>  --
> 
> diff --git a/doc/guides/cryptodevs/chacha20_poly1305.rst
> b/doc/guides/cryptodevs/chacha20_poly1305.rst
> index c32866b301..8e0ee4f835 100644
> --- a/doc/guides/cryptodevs/chacha20_poly1305.rst
> +++ b/doc/guides/cryptodevs/chacha20_poly1305.rst
> @@ -56,12 +56,6 @@ Once it is downloaded, extract it and follow these
> steps:
>  make
>  make install
> 
> -.. note::
> -
> -   Compilation of the Multi-Buffer library is broken when GCC < 5.0, if 
> library
> <= v0.53.
> -   If a lower GCC version than 5.0, the workaround proposed by the following
> link
> -   should be used: ``_.
> -
>  As a reference, the 

Re: [EXT] [PATCH] app/test: don't count skipped tests as executed

[Bruce Richardson]

On Tue, Mar 05, 2024 at 02:36:27PM +, Akhil Goyal wrote:
> > Subject: [EXT] [PATCH] app/test: don't count skipped tests as executed
> > The logic around skipped tests is a little confusing in the unit test
> > runner.
> > * Any explicitly disabled tests are counted as skipped but not
> >   executed.
> > * Any tests that return TEST_SKIPPED are counted as both skipped and
> >   executed, using the same statistics counters.
> > 
> > This makes the stats very strange and hard to correlate, since the
> > totals don't add up.  One would expect that SKIPPED + EXECUTED +
> > UNSUPPORTED == TOTAL, and that PASSED + FAILED == EXECUTED.
> > 
> > To achieve this, mark any tests returning TEST_SKIPPED, or ENOTSUP as
> > not having executed.
> > 
> > Signed-off-by: Bruce Richardson 
> 
> Acked-by: Akhil Goyal 
Cc: sta...@dpdk.org

> 
> Yes this makes sense.
> One would say executed should count the unsupported cases as well.
> But I think this makes sense to not include them in executed cases.

It's a good question and there are arguments either way. I'd say that no
test should return ENOTSUP now, and that such tests should return
TEST_SKIPPED. For now, I think it's best to treat them the same.

> This would give better correlation.
> Can we backport this as well?
> 

If LTS maintainers want it, sure. Adding stable on CC.

RE: [PATCH v4 1/2] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

[Wathsala Wathawana Vithanage]

> Subject: [PATCH v4 1/2] crypto/ipsec_mb: bump minimum IPsec Multi-buffer
> version
> 
> SW PMDs increment IPsec Multi-buffer version to 1.4.
> A minimum IPsec Multi-buffer version of 1.4 or greater is now required.
> 
> Signed-off-by: Sivaramakrishnan Venkat
> 
> Acked-by: Ciara Power 
> Acked-by: Pablo de Lara 

Acked-by: Wathsala Vithanage 

> ---
>   v4:
>  - 24.03 release notes updated to bump minimum IPSec Multi-buffer
>version to 1.4 for SW PMDs.
>   v2:
>  - Removed unused macro in ipsec_mb_ops.c
>  - set_gcm_job() modified correctly to keep multi_sgl_job line
>  - Updated SW PMDs documentation for minimum IPSec Multi-buffer
> version
>  - Updated commit message, and patch title.
> ---
>  doc/guides/cryptodevs/aesni_gcm.rst |   3 +-
>  doc/guides/cryptodevs/aesni_mb.rst  |   3 +-
>  doc/guides/cryptodevs/chacha20_poly1305.rst |   3 +-
>  doc/guides/cryptodevs/kasumi.rst|   3 +-
>  doc/guides/cryptodevs/snow3g.rst|   3 +-
>  doc/guides/cryptodevs/zuc.rst   |   3 +-
>  doc/guides/rel_notes/release_24_03.rst  |   4 +
>  drivers/crypto/ipsec_mb/ipsec_mb_ops.c  |  23 ---
>  drivers/crypto/ipsec_mb/meson.build |   2 +-
>  drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 165 
>  drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |   9 --
>  11 files changed, 17 insertions(+), 204 deletions(-)
> 
> diff --git a/doc/guides/cryptodevs/aesni_gcm.rst
> b/doc/guides/cryptodevs/aesni_gcm.rst
> index f5773426ee..dc665e536c 100644
> --- a/doc/guides/cryptodevs/aesni_gcm.rst
> +++ b/doc/guides/cryptodevs/aesni_gcm.rst
> @@ -85,7 +85,8 @@ and the external crypto libraries supported by them:
> 18.05 - 19.02  Multi-buffer library 0.49 - 0.52
> 19.05 - 20.08  Multi-buffer library 0.52 - 0.55
> 20.11 - 21.08  Multi-buffer library 0.53 - 1.3*
> -   21.11+ Multi-buffer library 1.0  - 1.5*
> +   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
> +   24.03+ Multi-buffer library 1.4  - 1.5*
> =  
> 
>  \* Multi-buffer library 1.0 or newer only works for Meson but not Make build
> system.
> diff --git a/doc/guides/cryptodevs/aesni_mb.rst
> b/doc/guides/cryptodevs/aesni_mb.rst
> index b2e74ba417..5d670ee237 100644
> --- a/doc/guides/cryptodevs/aesni_mb.rst
> +++ b/doc/guides/cryptodevs/aesni_mb.rst
> @@ -146,7 +146,8 @@ and the Multi-Buffer library version supported by
> them:
> 19.05 - 19.08   0.52
> 19.11 - 20.08   0.52 - 0.55
> 20.11 - 21.08   0.53 - 1.3*
> -   21.11+  1.0  - 1.5*
> +   21.11 - 23.11   1.0  - 1.5*
> +   24.03+  1.4  - 1.5*
> ==  
> 
>  \* Multi-buffer library 1.0 or newer only works for Meson but not Make build
> system.
> diff --git a/doc/guides/cryptodevs/chacha20_poly1305.rst
> b/doc/guides/cryptodevs/chacha20_poly1305.rst
> index 9d4bf86cf1..c32866b301 100644
> --- a/doc/guides/cryptodevs/chacha20_poly1305.rst
> +++ b/doc/guides/cryptodevs/chacha20_poly1305.rst
> @@ -72,7 +72,8 @@ and the external crypto libraries supported by them:
> =  
> DPDK version   Crypto library version
> =  
> -   21.11+ Multi-buffer library 1.0-1.5*
> +   21.11 - 23.11  Multi-buffer library 1.0-1.5*
> +   24.03+ Multi-buffer library 1.4-1.5*
> =  
> 
>  \* Multi-buffer library 1.0 or newer only works for Meson but not Make build
> system.
> diff --git a/doc/guides/cryptodevs/kasumi.rst
> b/doc/guides/cryptodevs/kasumi.rst
> index 0989054875..a8f4e6b204 100644
> --- a/doc/guides/cryptodevs/kasumi.rst
> +++ b/doc/guides/cryptodevs/kasumi.rst
> @@ -87,7 +87,8 @@ and the external crypto libraries supported by them:
> =  
> 16.11 - 19.11  LibSSO KASUMI
> 20.02 - 21.08  Multi-buffer library 0.53 - 1.3*
> -   21.11+ Multi-buffer library 1.0  - 1.5*
> +   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
> +   24.03+ Multi-buffer library 1.4  - 1.5*
> =  
> 
>  \* Multi-buffer library 1.0 or newer only works for Meson but not Make build
> system.
> diff --git a/doc/guides/cryptodevs/snow3g.rst
> b/doc/guides/cryptodevs/snow3g.rst
> index 3392932653..46863462e5 100644
> --- a/doc/guides/cryptodevs/snow3g.rst
> +++ b/doc/guides/cryptodevs/snow3g.rst
> @@ -96,7 +96,8 @@ and the external crypto libraries supported by them:
> =  
> 16.04 - 19.11  LibSSO SNOW3G
> 20.02 - 21.08  Multi-buffer library 0.53 - 1.3*
> -   21.11+ Multi-buffer library 1.0  - 1.5*
> +   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
> +   24.03+ Multi-buffer library 1.4  - 1.5*
> =  
> 
>  \* Multi-buffer library 1.0 or n

RE: [PATCH v2] crypto/ipsec_mb: use new ipad/opad calculation API

[Wathsala Wathawana Vithanage]

> Signed-off-by: Pablo de Lara 
> Signed-off-by: Brian Dooley 
> Acked-by: Ciara Power 

Acked-by: Wathsala Vithanage 

> 
> Depends-on: series-30989 ("crypto/ipsec_mb: bump minimum IPsec Multi-
> buffer version")
> 
> v2:
> - Remove ipsec mb version checks
> ---
>  drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 75 ++
>  1 file changed, 5 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> index 4de4866cf3..251e18ec7a 100644
> --- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> +++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> @@ -13,49 +13,6 @@ struct aesni_mb_op_buf_data {
>   uint32_t offset;
>  };
> 
> -/**
> - * Calculate the authentication pre-computes
> - *
> - * @param one_block_hash Function pointer
> - *   to calculate digest on ipad/opad
> - * @param ipad   Inner pad output byte array
> - * @param opad   Outer pad output byte array
> - * @param hkey   Authentication key
> - * @param hkey_len   Authentication key length
> - * @param blocksize  Block size of selected hash algo
> - */
> -static void
> -calculate_auth_precomputes(hash_one_block_t one_block_hash,
> - uint8_t *ipad, uint8_t *opad,
> - const uint8_t *hkey, uint16_t hkey_len,
> - uint16_t blocksize)
> -{
> - uint32_t i, length;
> -
> - uint8_t ipad_buf[blocksize] __rte_aligned(16);
> - uint8_t opad_buf[blocksize] __rte_aligned(16);
> -
> - /* Setup inner and outer pads */
> - memset(ipad_buf, HMAC_IPAD_VALUE, blocksize);
> - memset(opad_buf, HMAC_OPAD_VALUE, blocksize);
> -
> - /* XOR hash key with inner and outer pads */
> - length = hkey_len > blocksize ? blocksize : hkey_len;
> -
> - for (i = 0; i < length; i++) {
> - ipad_buf[i] ^= hkey[i];
> - opad_buf[i] ^= hkey[i];
> - }
> -
> - /* Compute partial hashes */
> - (*one_block_hash)(ipad_buf, ipad);
> - (*one_block_hash)(opad_buf, opad);
> -
> - /* Clean up stack */
> - memset(ipad_buf, 0, blocksize);
> - memset(opad_buf, 0, blocksize);
> -}
> -
>  static inline int
>  is_aead_algo(IMB_HASH_ALG hash_alg, IMB_CIPHER_MODE cipher_mode)  {
> @@ -66,12 +23,10 @@ is_aead_algo(IMB_HASH_ALG hash_alg,
> IMB_CIPHER_MODE cipher_mode)
> 
>  /** Set session authentication parameters */  static int -
> aesni_mb_set_session_auth_parameters(const IMB_MGR *mb_mgr,
> +aesni_mb_set_session_auth_parameters(IMB_MGR *mb_mgr,
>   struct aesni_mb_session *sess,
>   const struct rte_crypto_sym_xform *xform)  {
> - hash_one_block_t hash_oneblock_fn = NULL;
> - unsigned int key_larger_block_size = 0;
>   uint8_t hashed_key[HMAC_MAX_BLOCK_SIZE] = { 0 };
>   uint32_t auth_precompute = 1;
> 
> @@ -267,18 +222,15 @@ aesni_mb_set_session_auth_parameters(const
> IMB_MGR *mb_mgr,
>   switch (xform->auth.algo) {
>   case RTE_CRYPTO_AUTH_MD5_HMAC:
>   sess->template_job.hash_alg = IMB_AUTH_MD5;
> - hash_oneblock_fn = mb_mgr->md5_one_block;
>   break;
>   case RTE_CRYPTO_AUTH_SHA1_HMAC:
>   sess->template_job.hash_alg = IMB_AUTH_HMAC_SHA_1;
> - hash_oneblock_fn = mb_mgr->sha1_one_block;
>   if (xform->auth.key.length > get_auth_algo_blocksize(
>   IMB_AUTH_HMAC_SHA_1)) {
>   IMB_SHA1(mb_mgr,
>   xform->auth.key.data,
>   xform->auth.key.length,
>   hashed_key);
> - key_larger_block_size = 1;
>   }
>   break;
>   case RTE_CRYPTO_AUTH_SHA1:
> @@ -287,14 +239,12 @@ aesni_mb_set_session_auth_parameters(const
> IMB_MGR *mb_mgr,
>   break;
>   case RTE_CRYPTO_AUTH_SHA224_HMAC:
>   sess->template_job.hash_alg = IMB_AUTH_HMAC_SHA_224;
> - hash_oneblock_fn = mb_mgr->sha224_one_block;
>   if (xform->auth.key.length > get_auth_algo_blocksize(
>   IMB_AUTH_HMAC_SHA_224)) {
>   IMB_SHA224(mb_mgr,
>   xform->auth.key.data,
>   xform->auth.key.length,
>   hashed_key);
> - key_larger_block_size = 1;
>   }
>   break;
>   case RTE_CRYPTO_AUTH_SHA224:
> @@ -303,14 +253,12 @@ aesni_mb_set_session_auth_parameters(const
> IMB_MGR *mb_mgr,
>   break;
>   case RTE_CRYPTO_AUTH_SHA256_HMAC:
>   sess->template_job.hash_alg = IMB_AUTH_HMAC_SHA_256;
> - hash_oneblock_fn = mb_mgr->sha256_one_block;
>   if (xform->auth.key.length > get_auth_algo_blocksize(
>   IMB_AUTH_HMAC_SHA_256)) {
>   IMB_SHA256(mb_mgr,
>

RE: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface

[Wathsala Wathawana Vithanage]

> Subject: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface
> 
> Currently IPsec MB provides both the JOB API and direct API.
> AESNI_MB PMD is using the JOB API codepath while ZUC, KASUMI, SNOW3G
> and CHACHA20_POLY1305 are using the direct API.
> Instead of using the direct API for these PMDs, they should now make
> use of the JOB API codepath. This would remove all use of the IPsec MB
> direct API for these PMDs.
> 
> Signed-off-by: Brian Dooley 

Acked-by: Wathsala Vithanage 

> ---
> v2:
> - Fix compilation failure
> v3:
> - Remove session configure pointer for each PMD
> v4:
> - Keep AES GCM PMD and fix extern issue
> ---
>  doc/guides/rel_notes/release_24_03.rst|   6 +
>  drivers/crypto/ipsec_mb/pmd_aesni_mb.c|  10 +-
>  drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h   |  15 +-
>  drivers/crypto/ipsec_mb/pmd_chacha_poly.c | 338 +--
>  .../crypto/ipsec_mb/pmd_chacha_poly_priv.h|  28 -
>  drivers/crypto/ipsec_mb/pmd_kasumi.c  | 410 +
>  drivers/crypto/ipsec_mb/pmd_kasumi_priv.h |  20 -
>  drivers/crypto/ipsec_mb/pmd_snow3g.c  | 543 +-
>  drivers/crypto/ipsec_mb/pmd_snow3g_priv.h |  21 -
>  drivers/crypto/ipsec_mb/pmd_zuc.c | 347 +--
>  drivers/crypto/ipsec_mb/pmd_zuc_priv.h|  20 -
>  11 files changed, 48 insertions(+), 1710 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> index 879bb4944c..6c5b76cef5 100644
> --- a/doc/guides/rel_notes/release_24_03.rst
> +++ b/doc/guides/rel_notes/release_24_03.rst
> @@ -138,6 +138,12 @@ New Features
>  to support TLS v1.2, TLS v1.3 and DTLS v1.2.
>* Added PMD API to allow raw submission of instructions to CPT.
> 
> +* **Updated ipsec_mb crypto driver.**
> +
> +  * Kasumi, Snow3G, ChaChaPoly and ZUC PMDs now share the job API
> codepath
> +with AESNI_MB PMD. Depending on the architecture, the performance of
> ZUC
> +crypto PMD is approximately 10% less for small fixed packet sizes.
> +
> 
>  Removed Items
>  -
> diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> index 4de4866cf3..7d4dbc91ef 100644
> --- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> +++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
> @@ -8,6 +8,8 @@
> 
>  RTE_DEFINE_PER_LCORE(pid_t, pid);
> 
> +uint8_t pmd_driver_id_aesni_mb;
> +
>  struct aesni_mb_op_buf_data {
>   struct rte_mbuf *m;
>   uint32_t offset;
> @@ -761,7 +763,7 @@ aesni_mb_set_session_aead_parameters(const
> IMB_MGR *mb_mgr,
>  }
> 
>  /** Configure a aesni multi-buffer session from a crypto xform chain */
> -static int
> +int
>  aesni_mb_session_configure(IMB_MGR *mb_mgr,
>   void *priv_sess,
>   const struct rte_crypto_sym_xform *xform)
> @@ -2131,7 +2133,7 @@ set_job_null_op(IMB_JOB *job, struct
> rte_crypto_op *op)
>  }
> 
>  #if IMB_VERSION(1, 2, 0) < IMB_VERSION_NUM
> -static uint16_t
> +uint16_t
>  aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
>   uint16_t nb_ops)
>  {
> @@ -2321,7 +2323,7 @@ flush_mb_mgr(struct ipsec_mb_qp *qp, IMB_MGR
> *mb_mgr,
>   return processed_ops;
>  }
> 
> -static uint16_t
> +uint16_t
>  aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
>   uint16_t nb_ops)
>  {
> @@ -2456,7 +2458,7 @@ verify_sync_dgst(struct rte_crypto_sym_vec *vec,
>   return k;
>  }
> 
> -static uint32_t
> +uint32_t
>  aesni_mb_process_bulk(struct rte_cryptodev *dev __rte_unused,
>   struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs
> sofs,
>   struct rte_crypto_sym_vec *vec)
> diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
> b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
> index 85994fe5a1..2d462a7f68 100644
> --- a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
> +++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
> @@ -21,6 +21,19 @@
>  #define MAX_NUM_SEGS 16
>  #endif
> 
> +int
> +aesni_mb_session_configure(IMB_MGR * m __rte_unused, void *priv_sess,
> + const struct rte_crypto_sym_xform *xform);
> +
> +uint16_t
> +aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
> + uint16_t nb_ops);
> +
> +uint32_t
> +aesni_mb_process_bulk(struct rte_cryptodev *dev __rte_unused,
> + struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs
> sofs,
> + struct rte_crypto_sym_vec *vec);
> +
>  static const struct rte_cryptodev_capabilities aesni_mb_capabilities[] = {
>   {   /* MD5 HMAC */
>   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> @@ -722,8 +735,6 @@ static const struct rte_cryptodev_capabilities
> aesni_mb_capabilities[] = {
>   RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
>  };
> 
> -uint8_t pmd_driver_id_aesni_mb;
> -
>  struct aesni_mb_qp_data {
>   uint8_t temp_digests[IMB_MAX_JOBS][DIGEST_LENGTH_MAX];
>   /* *< Buffers used to store the digest generated
> diff --git a/drivers/crypto/i

RE: [PATCH] app/test: don't count skipped tests as executed

[Power, Ciara]

Hi Bruce,

> -Original Message-
> From: Bruce Richardson 
> Sent: Monday, November 13, 2023 3:06 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce 
> Subject: [PATCH] app/test: don't count skipped tests as executed
> 
> The logic around skipped tests is a little confusing in the unit test runner.
> * Any explicitly disabled tests are counted as skipped but not
>   executed.
> * Any tests that return TEST_SKIPPED are counted as both skipped and
>   executed, using the same statistics counters.
> 
> This makes the stats very strange and hard to correlate, since the totals 
> don't add
> up.  One would expect that SKIPPED + EXECUTED + UNSUPPORTED == TOTAL,
> and that PASSED + FAILED == EXECUTED.
> 
> To achieve this, mark any tests returning TEST_SKIPPED, or ENOTSUP as not
> having executed.
> 
> Signed-off-by: Bruce Richardson 
> ---
>  app/test/test.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/app/test/test.c b/app/test/test.c index bfa9ea52e3..7b882a59de
> 100644
> --- a/app/test/test.c
> +++ b/app/test/test.c
> @@ -375,11 +375,13 @@ unit_test_suite_runner(struct unit_test_suite *suite)
> 
>   if (test_success == TEST_SUCCESS)
>   suite->succeeded++;
> - else if (test_success == TEST_SKIPPED)
> + else if (test_success == TEST_SKIPPED) {
>   suite->skipped++;
> - else if (test_success == -ENOTSUP)
> + suite->executed--;
> + } else if (test_success == -ENOTSUP) {
>   suite->unsupported++;
> - else
> + suite->executed--;
> + } else
>   suite->failed++;
>   } else if (test_success == -ENOTSUP) {
>   suite->unsupported++;
> --
> 2.39.2

Makes sense - probably something I should have spotted way back when reworking 
some of the test framework for sub-testsuites.
Thanks

Acked-by: Ciara Power 

Re: [PATCH v5 4/4] hash: add SVE support for bulk key lookup

[Yoan Picchi]

On 3/4/24 13:35, Konstantin Ananyev wrote:




- Implemented SVE code for comparing signatures in bulk lookup.
- Added Defines in code for SVE code support.
- Optimise NEON code
- New SVE code is ~5% slower than optimized NEON for N2 processor.

Signed-off-by: Yoan Picchi 
Signed-off-by: Harjot Singh 
Reviewed-by: Nathan Brown 
Reviewed-by: Ruifeng Wang 
---
   lib/hash/rte_cuckoo_hash.c | 196 -
   lib/hash/rte_cuckoo_hash.h |   1 +
   2 files changed, 151 insertions(+), 46 deletions(-)

diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index a07dd3a28d..231d6d6ded 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -442,8 +442,11 @@ rte_hash_create(const struct rte_hash_parameters *params)
h->sig_cmp_fn = RTE_HASH_COMPARE_SSE;
else
   #elif defined(RTE_ARCH_ARM64)
-   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))
+   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) {
h->sig_cmp_fn = RTE_HASH_COMPARE_NEON;
+   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
+   h->sig_cmp_fn = RTE_HASH_COMPARE_SVE;
+   }
else
   #endif
h->sig_cmp_fn = RTE_HASH_COMPARE_SCALAR;
@@ -1860,37 +1863,103 @@ rte_hash_free_key_with_position(const struct rte_hash 
*h,
   #if defined(__ARM_NEON)

   static inline void
-compare_signatures_dense(uint32_t *prim_hash_matches, uint32_t 
*sec_hash_matches,
-   const struct rte_hash_bucket *prim_bkt,
-   const struct rte_hash_bucket *sec_bkt,
+compare_signatures_dense(uint16_t *hitmask_buffer,
+   const uint16_t *prim_bucket_sigs,
+   const uint16_t *sec_bucket_sigs,
uint16_t sig,
enum rte_hash_sig_compare_function sig_cmp_fn)
   {
unsigned int i;

+   static_assert(sizeof(*hitmask_buffer) >= 2*(RTE_HASH_BUCKET_ENTRIES/8),
+   "The hitmask must be exactly wide enough to accept the whole hitmask if it 
is dense");
+
/* For match mask every bits indicates the match */
switch (sig_cmp_fn) {


Can I ask to move arch specific comparison code into some arch-specific headers 
or so?
It is getting really hard to read and understand the generic code with all 
these ifdefs and arch specific instructions...



Hi, apologies for long delay in response.

  

I can easily enough move the compare_signatures into an arm/x86
directory, and have a default version in the code.


Yes, that's what I thought about.
  

The problem would be for bulk lookup. The function is already duplicated
   2 times (the l and lf version). If I remove the #ifdefs, I'll need to
duplicate them again into 4 nearly identical versions (dense and
sparse). The only third options I see would be some preprocessor macro
to patch the function, but that looks even dirtier to me.


Not sure I understood you here: from looking at the code I don't see any
arch specific ifdefs in bulk_lookup() routines.
What I am missing here?
  


Most if not all of those #if are architecture specific. For instance:
#if defined(__ARM_NEON)
#if defined(RTE_HAS_SVE_ACLE)

The main reason there's some #if in bulk lookup is to handle whether the 
function run with dense hitmask or a sparse hitmask.
x86 only support the sparse hitmask version (1 bit data, 1 bit padding) 
but arm support the dense hitmask (every bit count). The later ends up 
being faster.
Splitting bulk_lookup into its sparse and dense variant would be a lot 
of code duplication that I'd prefer to avoid.


What I might be able to do would be move compare_signatures into some 
arch specific version. The function are different enough that it 
wouldn't be too much of a code duplication. I'd argue though that the 
#ifded for NEON and SSE were already there and I only added the SVE variant.





I think duplicating the code would be bad, but I can do it if you want.
Unless you have a better solution?


+#if RTE_HASH_BUCKET_ENTRIES <= 8
case RTE_HASH_COMPARE_NEON: {
-   uint16x8_t vmat, x;
+   uint16x8_t vmat, hit1, hit2;
const uint16x8_t mask = {0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 
0x80};
const uint16x8_t vsig = vld1q_dup_u16((uint16_t const *)&sig);

/* Compare all signatures in the primary bucket */
-   vmat = vceqq_u16(vsig, vld1q_u16((uint16_t const 
*)prim_bkt->sig_current));
-   x = vandq_u16(vmat, mask);
-   *prim_hash_matches = (uint32_t)(vaddvq_u16(x));
+   vmat = vceqq_u16(vsig, vld1q_u16(prim_bucket_sigs));
+   hit1 = vandq_u16(vmat, mask);
+
/* Compare all signatures in the secondary bucket */
-   vmat = vceqq_u16(vsig, vld1q_u16((uint16_t const 
*)sec_bkt->sig_current));
-   x = vandq_u16(vmat, mask);
-   *sec_hash_matches = (uint32_t)(vaddvq_u16(x));
+

Re: [PATCH v7 10/39] eventdev: use C11 alignas

[David Marchand]

On Mon, Mar 4, 2024 at 6:54 PM Tyler Retzlaff
 wrote:
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 3af4686..08e5f93 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -1338,7 +1338,7 @@ int rte_event_dev_stop_flush_callback_register(uint8_t 
> dev_id,
>  /**
>   * Event vector structure.
>   */
> -struct rte_event_vector {
> +struct __rte_aligned(16) rte_event_vector {
> uint16_t nb_elem;
> /**< Number of elements valid in this event vector. */
> uint16_t elem_offset : 12;
> @@ -1376,23 +1376,19 @@ struct rte_event_vector {
>  * value to share between dequeue and enqueue operation.
>  * The application should not modify this field.
>  */
> -   union {
> +   union __rte_aligned(16) {
>  #endif
> struct rte_mbuf *mbufs[0];
> void *ptrs[0];
> uint64_t u64s[0];
>  #ifndef __cplusplus
> -   } __rte_aligned(16);
> +   };
>  #endif
> /**< Start of the vector array union. Depending upon the event type 
> the
>  * vector array can be an array of mbufs or pointers or opaque u64
>  * values.
>  */
> -#ifndef __DOXYGEN__
> -} __rte_aligned(16);
> -#else
>  };
> -#endif

This part was a strange construct.
I see nothing wrong with the change (doxygen passes fine), but just a
heads up to Jerin.


-- 
David Marchand

RE: [EXTERNAL] [PATCH] crypto/ipsec_mb: update Arm IPsec-MB library tag

[Akhil Goyal]

> Subject: RE: [EXTERNAL] [PATCH] crypto/ipsec_mb: update Arm IPsec-MB library
> tag
> 
> > Updates the tag of Arm IPsec-MB library to SECLIB-IPSEC-2023.10.13
> > in snow3g and zuc documentation. Tag SECLIB-IPSEC-2023.10.13 updates
> > IPSec-MB library version to 1.4.
> >
> > Signed-off-by: Wathsala Vithanage 
> > Reviewed-by: Ruifeng Wang 
> > Reviewed-by: Honnappa Nagarahalli 
> > Reviewed-by: Jack Bond-Preston 
> > ---
> I believe this patch would need a rework due to the issue found in
> https://patches.dpdk.org/project/dpdk/patch/20240228113301.934291-1-
> brian.doo...@intel.com/
Hi Wathsala,
Any update on the updated tag and this patch?

RE: RFC: Using and renaming 8-bit reserved field of rte_crypto_op for implementation specific

[Akhil Goyal]

Hi Ganapati,

Can you please explain the flow with a sequence of APIs to be used.

Regards,
Akhil

From: Kundapura, Ganapati 
Sent: Tuesday, March 5, 2024 12:44 PM
To: dpdk-dev ; Akhil Goyal ; 
fanzhang@gmail.com; Ji, Kai ; Power, Ciara 
; Kusztal, ArkadiuszX ; 
Gujjar, Abhinandan S ; Jayatheerthan, Jay 
; Jerin Jacob 
Subject: [EXTERNAL] RFC: Using and renaming 8-bit reserved field of 
rte_crypto_op for implementation specific

Prioritize security for external emails: Confirm sender and content safety 
before clicking links or opening attachments

Hi dpdk-dev,
   Can 'uint8_t reserved[1]' of 'struct rte_crypto_op' be renamed
to 'uint8_t impl_opaque' for implementation specific?

An implementation may use this field to hold implementation specific
value to share value between dequeue and enqueue operation and crypto 
library/driver
can also use this field to share implementation specfic value to event crypto 
adapter/application.

'struct rte_event' has 'uint8_t impl_opaque' member
struct rte_event {
...
uint8_t impl_opaque;
/**< Implementation specific opaque value.
* An implementation may use this field to hold
* implementation specific value to share between
* dequeue and enqueue operation.
* The application should not modify this field.
*/
...
};

Event crypto adapter, on dequeuing the event, enqueues rte_event::event_ptr
to cryptodev as rte_crypto_op and converts the dequeued crypto op to rte_event
without restoring the implementation specific opaque value.

By having the 'uint8_t impl_opaque' member in 'struct rte_crypto_op' as
diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h
index dbc2700..af46ec9 100644
--- a/lib/cryptodev/rte_crypto.h
+++ b/lib/cryptodev/rte_crypto.h
@@ -146,10 +146,13 @@ struct rte_crypto_op {
/**< TLS record */
} param1;
/**< Additional per operation parameter 1. */
-   uint8_t reserved[1];
-   /**< Reserved bytes to fill 64 bits for
-* future additions
+   uint8_t impl_opaque;
+   /**< Implementation specific opaque value.
+* An implementation may use this field to hold
+* implementation specific value to share between
+* dequeue and enqueue operation.
 */
+

which is untouched in library/driver and rte_event::impl_opaque field can be 
restored
while enqueuing the event back to eventdev.

Also crypto library/driver can use rte_crypto_op::impl_opaque field to
share implementation specific opaque value to the event crypto 
adapter/application.

I look forward to feedback on this proposal. Patch will be submitted
for review once the initial feedback is received.

Thank you,
Ganapati

RE: [PATCH 1/2] net/mlx5: update speed capabilities parsing on Linux

[Dariusz Sosnowski]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Tuesday, March 5, 2024 14:13
> To: dev@dpdk.org
> Cc: Dariusz Sosnowski ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Matan Azrad 
> Subject: [PATCH 1/2] net/mlx5: update speed capabilities parsing on Linux
> 
> External email: Use caution opening links or attachments
> 
> 
> Ease maintenance of speed capabilities parsing from ethtool by using
> rte_eth_link_speed_g*().
> Functions in ethdev library are simpler, more complete, and easier to 
> maintain.
> 
> Signed-off-by: Thomas Monjalon 
Acked-by: Dariusz Sosnowski 

Best regards,
Dariusz Sosnowski

RE: [PATCH 2/2] net/mlx5: apply default tuning to future speeds

[Dariusz Sosnowski]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Tuesday, March 5, 2024 14:13
> To: dev@dpdk.org
> Cc: Dariusz Sosnowski ; Slava Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Matan Azrad 
> Subject: [PATCH 2/2] net/mlx5: apply default tuning to future speeds
> 
> External email: Use caution opening links or attachments
> 
> 
> Some default parameters for number of queues and ring size are different
> starting with 100G speed capability.
> 
> Instead of checking all speed above 100G, make sure it is applied for any 
> speed
> capability newer than 100G (including 400G for instance).
> 
> Signed-off-by: Thomas Monjalon 
Acked-by: Dariusz Sosnowski 

Best regards,
Dariusz Sosnowski

RE: [PATCH v2 45/71] event/dlb2: replace use of fixed size rte_memcpy

[Sevincer, Abdullah]

Hi Stephen,

Are all rte_memcpy functions now be replaced by memcpy and no more use of 
rte_memcpy?

RE: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface

[Wathsala Wathawana Vithanage]

> This is being worked on. We are in the process of creating a new tag. We will
> update soon.
> 
A new tag SECLIB-IPSEC-2024.03.05 has been created. We will be sending out a 
patch for the documentation soon. 

RE: [EXT] Re: [PATCH v2 8/8] crypto/ipsec_mb: set and use session ID

[Wathsala Wathawana Vithanage]

> A new tag SECLIB-IPSEC-2023.10.13 has been created from the tip of arm
> ipsec-mb git repo.
> Please use this tag going forward, it has been tested and works as expected.

Please use SECLIB-IPSEC-2024.03.05 that fixes issues caused by above tag.
We will be updating the documentation soon.

Re: [PATCH v7 08/39] mbuf: use C11 alignas

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 03:30:49PM +0100, David Marchand wrote:
> On Mon, Mar 4, 2024 at 6:54 PM Tyler Retzlaff
>  wrote:
> >
> > The current location used for __rte_aligned(a) for alignment of types
> > and variables is not compatible with MSVC. There is only a single
> > location accepted by both toolchains.
> >
> > For variables standard C11 offers alignas(a) supported by conformant
> > compilers i.e. both MSVC and GCC.
> >
> > For types the standard offers no alignment facility that compatibly
> > interoperates with C and C++ but may be achieved by relocating the
> > placement of __rte_aligned(a) to the aforementioned location accepted
> > by all currently supported toolchains.
> >
> > To allow alignment for both compilers do the following:
> >
> > * Move __rte_aligned from the end of {struct,union} definitions to
> >   be between {struct,union} and tag.
> >
> >   The placement between {struct,union} and the tag allows the desired
> >   alignment to be imparted on the type regardless of the toolchain being
> >   used for all of GCC, LLVM, MSVC compilers building both C and C++.
> >
> > * Replace use of __rte_aligned(a) on variables/fields with alignas(a).
> >
> > Signed-off-by: Tyler Retzlaff 
> > Acked-by: Morten Brørup 
> > Acked-by: Konstantin Ananyev 
> > ---
> >  lib/mbuf/rte_mbuf_core.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > index 5688683..917a811 100644
> > --- a/lib/mbuf/rte_mbuf_core.h
> > +++ b/lib/mbuf/rte_mbuf_core.h
> > @@ -463,7 +463,7 @@ enum {
> >  /**
> >   * The generic rte_mbuf, containing a packet mbuf.
> >   */
> > -struct rte_mbuf {
> > +struct __rte_cache_aligned rte_mbuf {
> > RTE_MARKER cacheline0;
> >
> > void *buf_addr;   /**< Virtual address of segment buffer. */
> > @@ -476,7 +476,7 @@ struct rte_mbuf {
> >  * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
> >  * working on vector drivers easier.
> >  */
> > -   rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> > +   alignas(sizeof(rte_iova_t)) rte_iova_t buf_iova;
> >  #else
> > /**
> >  * Next segment of scattered packet.
> > @@ -662,7 +662,7 @@ struct rte_mbuf {
> > uint16_t timesync;
> >
> > uint32_t dynfield1[9]; /**< Reserved for dynamic fields. */
> > -} __rte_cache_aligned;
> > +};
> 
> I probably missed the discussion, but why is cacheline1 not handled in
> this patch?
> I was expecting a:
> -   RTE_MARKER cacheline1 __rte_cache_min_aligned;
> +   alignas(RTE_CACHE_LINE_MIN_SIZE) RTE_MARKER cacheline1;

I should have replaced it I just missed it. Could I get you to fix it up?
We have 2 options.

1. You can leave it as is, eventually the other series I have dealing
   with the markers I will probably remove the cacheline1 marker anyway.

2. You could adjust it as you've identified above, just move alignas
   before the field type and name.

If you want me to submit a v8 for this let me know I'll do it right
away.

Thanks!

> 
> 
> -- 
> David Marchand

Re: [PATCH v7 10/39] eventdev: use C11 alignas

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 04:47:05PM +0100, David Marchand wrote:
> On Mon, Mar 4, 2024 at 6:54 PM Tyler Retzlaff
>  wrote:
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index 3af4686..08e5f93 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -1338,7 +1338,7 @@ int 
> > rte_event_dev_stop_flush_callback_register(uint8_t dev_id,
> >  /**
> >   * Event vector structure.
> >   */
> > -struct rte_event_vector {
> > +struct __rte_aligned(16) rte_event_vector {
> > uint16_t nb_elem;
> > /**< Number of elements valid in this event vector. */
> > uint16_t elem_offset : 12;
> > @@ -1376,23 +1376,19 @@ struct rte_event_vector {
> >  * value to share between dequeue and enqueue operation.
> >  * The application should not modify this field.
> >  */
> > -   union {
> > +   union __rte_aligned(16) {
> >  #endif
> > struct rte_mbuf *mbufs[0];
> > void *ptrs[0];
> > uint64_t u64s[0];
> >  #ifndef __cplusplus
> > -   } __rte_aligned(16);
> > +   };
> >  #endif
> > /**< Start of the vector array union. Depending upon the event type 
> > the
> >  * vector array can be an array of mbufs or pointers or opaque u64
> >  * values.
> >  */
> > -#ifndef __DOXYGEN__
> > -} __rte_aligned(16);
> > -#else
> >  };
> > -#endif
> 
> This part was a strange construct.
> I see nothing wrong with the change (doxygen passes fine), but just a
> heads up to Jerin.

So there was another series merged recently that added this __DOXYGEN__
conditional I'm just removing it again.

Bruce pointed out that one of the benefits of moving __rte_aligned(16)
between struct  doxygen no longer gets confused.

https://mails.dpdk.org/archives/dev/2024-March/289231.html

> 
> 
> -- 
> David Marchand

[PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

[Brian Dooley]

From: Sivaramakrishnan Venkat 

SW PMDs increment IPsec Multi-buffer version to 1.4.
A minimum IPsec Multi-buffer version of 1.4 or greater is now required.

Signed-off-by: Sivaramakrishnan Venkat 
Acked-by: Ciara Power 
Acked-by: Pablo de Lara 
Acked-by: Wathsala Vithanage 
---
  v5:
 - Rebased and added to patchset
  v4:
 - 24.03 release notes updated to bump minimum IPSec Multi-buffer
   version to 1.4 for SW PMDs.
  v2:
 - Removed unused macro in ipsec_mb_ops.c
 - set_gcm_job() modified correctly to keep multi_sgl_job line
 - Updated SW PMDs documentation for minimum IPSec Multi-buffer version
 - Updated commit message, and patch title.
---
 doc/guides/cryptodevs/aesni_gcm.rst |   3 +-
 doc/guides/cryptodevs/aesni_mb.rst  |   3 +-
 doc/guides/cryptodevs/chacha20_poly1305.rst |   3 +-
 doc/guides/cryptodevs/kasumi.rst|   3 +-
 doc/guides/cryptodevs/snow3g.rst|   3 +-
 doc/guides/cryptodevs/zuc.rst   |   3 +-
 doc/guides/rel_notes/release_24_03.rst  |   4 +
 drivers/crypto/ipsec_mb/ipsec_mb_ops.c  |  23 ---
 drivers/crypto/ipsec_mb/meson.build |   2 +-
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 164 
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h |   9 --
 11 files changed, 17 insertions(+), 203 deletions(-)

diff --git a/doc/guides/cryptodevs/aesni_gcm.rst 
b/doc/guides/cryptodevs/aesni_gcm.rst
index f5773426ee..dc665e536c 100644
--- a/doc/guides/cryptodevs/aesni_gcm.rst
+++ b/doc/guides/cryptodevs/aesni_gcm.rst
@@ -85,7 +85,8 @@ and the external crypto libraries supported by them:
18.05 - 19.02  Multi-buffer library 0.49 - 0.52
19.05 - 20.08  Multi-buffer library 0.52 - 0.55
20.11 - 21.08  Multi-buffer library 0.53 - 1.3*
-   21.11+ Multi-buffer library 1.0  - 1.5*
+   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
+   24.03+ Multi-buffer library 1.4  - 1.5*
=  
 
 \* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst 
b/doc/guides/cryptodevs/aesni_mb.rst
index b2e74ba417..5d670ee237 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -146,7 +146,8 @@ and the Multi-Buffer library version supported by them:
19.05 - 19.08   0.52
19.11 - 20.08   0.52 - 0.55
20.11 - 21.08   0.53 - 1.3*
-   21.11+  1.0  - 1.5*
+   21.11 - 23.11   1.0  - 1.5*
+   24.03+  1.4  - 1.5*
==  
 
 \* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
diff --git a/doc/guides/cryptodevs/chacha20_poly1305.rst 
b/doc/guides/cryptodevs/chacha20_poly1305.rst
index 9d4bf86cf1..c32866b301 100644
--- a/doc/guides/cryptodevs/chacha20_poly1305.rst
+++ b/doc/guides/cryptodevs/chacha20_poly1305.rst
@@ -72,7 +72,8 @@ and the external crypto libraries supported by them:
=  
DPDK version   Crypto library version
=  
-   21.11+ Multi-buffer library 1.0-1.5*
+   21.11 - 23.11  Multi-buffer library 1.0-1.5*
+   24.03+ Multi-buffer library 1.4-1.5*
=  
 
 \* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
diff --git a/doc/guides/cryptodevs/kasumi.rst b/doc/guides/cryptodevs/kasumi.rst
index 0989054875..a8f4e6b204 100644
--- a/doc/guides/cryptodevs/kasumi.rst
+++ b/doc/guides/cryptodevs/kasumi.rst
@@ -87,7 +87,8 @@ and the external crypto libraries supported by them:
=  
16.11 - 19.11  LibSSO KASUMI
20.02 - 21.08  Multi-buffer library 0.53 - 1.3*
-   21.11+ Multi-buffer library 1.0  - 1.5*
+   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
+   24.03+ Multi-buffer library 1.4  - 1.5*
=  
 
 \* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
diff --git a/doc/guides/cryptodevs/snow3g.rst b/doc/guides/cryptodevs/snow3g.rst
index 3392932653..46863462e5 100644
--- a/doc/guides/cryptodevs/snow3g.rst
+++ b/doc/guides/cryptodevs/snow3g.rst
@@ -96,7 +96,8 @@ and the external crypto libraries supported by them:
=  
16.04 - 19.11  LibSSO SNOW3G
20.02 - 21.08  Multi-buffer library 0.53 - 1.3*
-   21.11+ Multi-buffer library 1.0  - 1.5*
+   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
+   24.03+ Multi-buffer library 1.4  - 1.5*
=  
 
 \* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
diff --git a/doc/guides/cryptodevs/zuc.rst b/doc/guides/cryptodevs/zuc.rst
index a414b5ad2c..51867e1a16 100644
--- a/doc/guides/cryptodevs/zuc.rst
+++ b/doc/guides/cryptod

[PATCH v5 2/4] doc: remove outdated version details

[Brian Dooley]

From: Sivaramakrishnan Venkat 

SW PMDs documentation is updated to remove details of unsupported IPsec
Multi-buffer versions.DPDK older than 20.11 is end of life. So, older
DPDK versions are removed from the Crypto library version table.

Signed-off-by: Sivaramakrishnan Venkat 
Acked-by: Pablo de Lara 
Acked-by: Wathsala Vithanage 
---
  v5:
- Rebased and added to patchset
  v3:
- added second patch for outdated documentation updates.
---
 doc/guides/cryptodevs/aesni_gcm.rst | 19 +++---
 doc/guides/cryptodevs/aesni_mb.rst  | 22 +++--
 doc/guides/cryptodevs/chacha20_poly1305.rst | 12 ++-
 doc/guides/cryptodevs/kasumi.rst| 14 +++--
 doc/guides/cryptodevs/snow3g.rst| 15 +++---
 doc/guides/cryptodevs/zuc.rst   | 15 +++---
 6 files changed, 17 insertions(+), 80 deletions(-)

diff --git a/doc/guides/cryptodevs/aesni_gcm.rst 
b/doc/guides/cryptodevs/aesni_gcm.rst
index dc665e536c..e38a03b78f 100644
--- a/doc/guides/cryptodevs/aesni_gcm.rst
+++ b/doc/guides/cryptodevs/aesni_gcm.rst
@@ -62,12 +62,6 @@ Once it is downloaded, extract it and follow these steps:
 make
 make install
 
-.. note::
-
-   Compilation of the Multi-Buffer library is broken when GCC < 5.0, if 
library <= v0.53.
-   If a lower GCC version than 5.0, the workaround proposed by the following 
link
-   should be used: ``_.
-
 
 As a reference, the following table shows a mapping between the past DPDK 
versions
 and the external crypto libraries supported by them:
@@ -79,18 +73,11 @@ and the external crypto libraries supported by them:
=  
DPDK version   Crypto library version
=  
-   16.04 - 16.11  Multi-buffer library 0.43 - 0.44
-   17.02 - 17.05  ISA-L Crypto v2.18
-   17.08 - 18.02  Multi-buffer library 0.46 - 0.48
-   18.05 - 19.02  Multi-buffer library 0.49 - 0.52
-   19.05 - 20.08  Multi-buffer library 0.52 - 0.55
-   20.11 - 21.08  Multi-buffer library 0.53 - 1.3*
-   21.11 - 23.11  Multi-buffer library 1.0  - 1.5*
-   24.03+ Multi-buffer library 1.4  - 1.5*
+   20.11 - 21.08  Multi-buffer library 0.53 - 1.3
+   21.11 - 23.11  Multi-buffer library 1.0  - 1.5
+   24.03+ Multi-buffer library 1.4  - 1.5
=  
 
-\* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
-
 Initialization
 --
 
diff --git a/doc/guides/cryptodevs/aesni_mb.rst 
b/doc/guides/cryptodevs/aesni_mb.rst
index 5d670ee237..bd7c8de07f 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -121,12 +121,6 @@ Once it is downloaded, extract it and follow these steps:
 make
 make install
 
-.. note::
-
-   Compilation of the Multi-Buffer library is broken when GCC < 5.0, if 
library <= v0.53.
-   If a lower GCC version than 5.0, the workaround proposed by the following 
link
-   should be used: ``_.
-
 As a reference, the following table shows a mapping between the past DPDK 
versions
 and the Multi-Buffer library version supported by them:
 
@@ -137,21 +131,11 @@ and the Multi-Buffer library version supported by them:
==  
DPDK versionMulti-buffer library version
==  
-   2.2 - 16.11 0.43 - 0.44
-   17.02   0.44
-   17.05 - 17.08   0.45 - 0.48
-   17.11   0.47 - 0.48
-   18.02   0.48
-   18.05 - 19.02   0.49 - 0.52
-   19.05 - 19.08   0.52
-   19.11 - 20.08   0.52 - 0.55
-   20.11 - 21.08   0.53 - 1.3*
-   21.11 - 23.11   1.0  - 1.5*
-   24.03+  1.4  - 1.5*
+   20.11 - 21.08   0.53 - 1.3
+   21.11 - 23.11   1.0  - 1.5
+   24.03+  1.4  - 1.5
==  
 
-\* Multi-buffer library 1.0 or newer only works for Meson but not Make build 
system.
-
 Initialization
 --
 
diff --git a/doc/guides/cryptodevs/chacha20_poly1305.rst 
b/doc/guides/cryptodevs/chacha20_poly1305.rst
index c32866b301..8e0ee4f835 100644
--- a/doc/guides/cryptodevs/chacha20_poly1305.rst
+++ b/doc/guides/cryptodevs/chacha20_poly1305.rst
@@ -56,12 +56,6 @@ Once it is downloaded, extract it and follow these steps:
 make
 make install
 
-.. note::
-
-   Compilation of the Multi-Buffer library is broken when GCC < 5.0, if 
library <= v0.53.
-   If a lower GCC version than 5.0, the workaround proposed by the following 
link
-   should be used: ``_.
-
 As a reference, the following table shows a mapping between the past DPDK 
versions
 and the external crypto libraries supported by them:
 
@@ -72,12 +66,10 @@ and the external crypto libraries supported by them:
=  =

[PATCH v5 3/4] crypto/ipsec_mb: use new ipad/opad calculation API

[Brian Dooley]

IPSec Multi-buffer library v1.4 added a new API to
calculate inner/outer padding for HMAC-SHAx/MD5.

Signed-off-by: Pablo de Lara 
Signed-off-by: Brian Dooley 
Acked-by: Ciara Power 
Acked-by: Wathsala Vithanage 

---
v5:
- Rebased and added to patchset
v2:
- Remove ipsec mb version checks
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 75 ++
 1 file changed, 5 insertions(+), 70 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 2acd229268..92703a76f0 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -13,49 +13,6 @@ struct aesni_mb_op_buf_data {
uint32_t offset;
 };
 
-/**
- * Calculate the authentication pre-computes
- *
- * @param one_block_hash   Function pointer
- * to calculate digest on ipad/opad
- * @param ipad Inner pad output byte array
- * @param opad Outer pad output byte array
- * @param hkey Authentication key
- * @param hkey_len Authentication key length
- * @param blocksizeBlock size of selected hash algo
- */
-static void
-calculate_auth_precomputes(hash_one_block_t one_block_hash,
-   uint8_t *ipad, uint8_t *opad,
-   const uint8_t *hkey, uint16_t hkey_len,
-   uint16_t blocksize)
-{
-   uint32_t i, length;
-
-   uint8_t ipad_buf[blocksize] __rte_aligned(16);
-   uint8_t opad_buf[blocksize] __rte_aligned(16);
-
-   /* Setup inner and outer pads */
-   memset(ipad_buf, HMAC_IPAD_VALUE, blocksize);
-   memset(opad_buf, HMAC_OPAD_VALUE, blocksize);
-
-   /* XOR hash key with inner and outer pads */
-   length = hkey_len > blocksize ? blocksize : hkey_len;
-
-   for (i = 0; i < length; i++) {
-   ipad_buf[i] ^= hkey[i];
-   opad_buf[i] ^= hkey[i];
-   }
-
-   /* Compute partial hashes */
-   (*one_block_hash)(ipad_buf, ipad);
-   (*one_block_hash)(opad_buf, opad);
-
-   /* Clean up stack */
-   memset(ipad_buf, 0, blocksize);
-   memset(opad_buf, 0, blocksize);
-}
-
 static inline int
 is_aead_algo(IMB_HASH_ALG hash_alg, IMB_CIPHER_MODE cipher_mode)
 {
@@ -66,12 +23,10 @@ is_aead_algo(IMB_HASH_ALG hash_alg, IMB_CIPHER_MODE 
cipher_mode)
 
 /** Set session authentication parameters */
 static int
-aesni_mb_set_session_auth_parameters(const IMB_MGR *mb_mgr,
+aesni_mb_set_session_auth_parameters(IMB_MGR *mb_mgr,
struct aesni_mb_session *sess,
const struct rte_crypto_sym_xform *xform)
 {
-   hash_one_block_t hash_oneblock_fn = NULL;
-   unsigned int key_larger_block_size = 0;
uint8_t hashed_key[HMAC_MAX_BLOCK_SIZE] = { 0 };
uint32_t auth_precompute = 1;
 
@@ -263,18 +218,15 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR 
*mb_mgr,
switch (xform->auth.algo) {
case RTE_CRYPTO_AUTH_MD5_HMAC:
sess->template_job.hash_alg = IMB_AUTH_MD5;
-   hash_oneblock_fn = mb_mgr->md5_one_block;
break;
case RTE_CRYPTO_AUTH_SHA1_HMAC:
sess->template_job.hash_alg = IMB_AUTH_HMAC_SHA_1;
-   hash_oneblock_fn = mb_mgr->sha1_one_block;
if (xform->auth.key.length > get_auth_algo_blocksize(
IMB_AUTH_HMAC_SHA_1)) {
IMB_SHA1(mb_mgr,
xform->auth.key.data,
xform->auth.key.length,
hashed_key);
-   key_larger_block_size = 1;
}
break;
case RTE_CRYPTO_AUTH_SHA1:
@@ -283,14 +235,12 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR 
*mb_mgr,
break;
case RTE_CRYPTO_AUTH_SHA224_HMAC:
sess->template_job.hash_alg = IMB_AUTH_HMAC_SHA_224;
-   hash_oneblock_fn = mb_mgr->sha224_one_block;
if (xform->auth.key.length > get_auth_algo_blocksize(
IMB_AUTH_HMAC_SHA_224)) {
IMB_SHA224(mb_mgr,
xform->auth.key.data,
xform->auth.key.length,
hashed_key);
-   key_larger_block_size = 1;
}
break;
case RTE_CRYPTO_AUTH_SHA224:
@@ -299,14 +249,12 @@ aesni_mb_set_session_auth_parameters(const IMB_MGR 
*mb_mgr,
break;
case RTE_CRYPTO_AUTH_SHA256_HMAC:
sess->template_job.hash_alg = IMB_AUTH_HMAC_SHA_256;
-   hash_oneblock_fn = mb_mgr->sha256_one_block;
if (xform->auth.key.length > get_auth_algo_blocksize(
IMB_AUTH_HMAC_SHA_256)) {
IMB_SHA256(mb_mgr,
xform->auth.key.data,
   

[PATCH v5 4/4] crypto/ipsec_mb: unified IPsec MB interface

[Brian Dooley]

Currently IPsec MB provides both the JOB API and direct API.
AESNI_MB PMD is using the JOB API codepath while ZUC, KASUMI, SNOW3G
and CHACHA20_POLY1305 are using the direct API.
Instead of using the direct API for these PMDs, they should now make
use of the JOB API codepath. This would remove all use of the IPsec MB
direct API for these PMDs.

Signed-off-by: Brian Dooley 
Acked-by: Ciara Power 
Acked-by: Wathsala Vithanage 
---
v5:
- Rebased and added patchset
v4:
- Keep AES GCM PMD and fix extern issue
v3:
- Remove session configure pointer for each PMD
v2:
- Fix compilation failure
---
 doc/guides/rel_notes/release_24_03.rst|   3 +
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c|   8 +-
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h   |  15 +-
 drivers/crypto/ipsec_mb/pmd_chacha_poly.c | 338 +--
 .../crypto/ipsec_mb/pmd_chacha_poly_priv.h|  28 -
 drivers/crypto/ipsec_mb/pmd_kasumi.c  | 410 +
 drivers/crypto/ipsec_mb/pmd_kasumi_priv.h |  20 -
 drivers/crypto/ipsec_mb/pmd_snow3g.c  | 543 +-
 drivers/crypto/ipsec_mb/pmd_snow3g_priv.h |  21 -
 drivers/crypto/ipsec_mb/pmd_zuc.c | 347 +--
 drivers/crypto/ipsec_mb/pmd_zuc_priv.h|  20 -
 11 files changed, 44 insertions(+), 1709 deletions(-)

diff --git a/doc/guides/rel_notes/release_24_03.rst 
b/doc/guides/rel_notes/release_24_03.rst
index 8fa8cf1dd6..a4309311d4 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -147,6 +147,9 @@ New Features
 * **Updated ipsec_mb crypto driver.**
 
   * Bump minimum IPSec Multi-buffer version to 1.4 for SW PMDs.
+  * Kasumi, Snow3G, ChaChaPoly and ZUC PMDs now share the job API codepath
+with AESNI_MB PMD. Depending on the architecture, the performance of ZUC
+crypto PMD is approximately 10% less for small fixed packet sizes.
 
 * **Updated Marvell cnxk crypto driver.**
 
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 92703a76f0..35bd7eaa51 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -8,6 +8,8 @@
 
 RTE_DEFINE_PER_LCORE(pid_t, pid);
 
+uint8_t pmd_driver_id_aesni_mb;
+
 struct aesni_mb_op_buf_data {
struct rte_mbuf *m;
uint32_t offset;
@@ -692,7 +694,7 @@ aesni_mb_set_session_aead_parameters(const IMB_MGR *mb_mgr,
 }
 
 /** Configure a aesni multi-buffer session from a crypto xform chain */
-static int
+int
 aesni_mb_session_configure(IMB_MGR *mb_mgr,
void *priv_sess,
const struct rte_crypto_sym_xform *xform)
@@ -2039,7 +2041,7 @@ set_job_null_op(IMB_JOB *job, struct rte_crypto_op *op)
return job;
 }
 
-static uint16_t
+uint16_t
 aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
uint16_t nb_ops)
 {
@@ -2227,7 +2229,7 @@ verify_sync_dgst(struct rte_crypto_sym_vec *vec,
return k;
 }
 
-static uint32_t
+uint32_t
 aesni_mb_process_bulk(struct rte_cryptodev *dev __rte_unused,
struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs sofs,
struct rte_crypto_sym_vec *vec)
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
index 51cfd7e2aa..4805627679 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
@@ -19,6 +19,19 @@
 
 #define MAX_NUM_SEGS 16
 
+int
+aesni_mb_session_configure(IMB_MGR * m __rte_unused, void *priv_sess,
+   const struct rte_crypto_sym_xform *xform);
+
+uint16_t
+aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
+   uint16_t nb_ops);
+
+uint32_t
+aesni_mb_process_bulk(struct rte_cryptodev *dev __rte_unused,
+   struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs sofs,
+   struct rte_crypto_sym_vec *vec);
+
 static const struct rte_cryptodev_capabilities aesni_mb_capabilities[] = {
{   /* MD5 HMAC */
.op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
@@ -715,8 +728,6 @@ static const struct rte_cryptodev_capabilities 
aesni_mb_capabilities[] = {
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
 };
 
-uint8_t pmd_driver_id_aesni_mb;
-
 struct aesni_mb_qp_data {
uint8_t temp_digests[IMB_MAX_JOBS][DIGEST_LENGTH_MAX];
/* *< Buffers used to store the digest generated
diff --git a/drivers/crypto/ipsec_mb/pmd_chacha_poly.c 
b/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
index 97e7cef233..7436353fc2 100644
--- a/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
+++ b/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
@@ -3,334 +3,7 @@
  */
 
 #include "pmd_chacha_poly_priv.h"
-
-/** Parse crypto xform chain and set private session parameters. */
-static int
-chacha20_poly1305_session_configure(IMB_MGR * mb_mgr __rte_unused,
-   void *priv_sess, const struct rte_crypto_sym_xform *xform)
-{
-   struct chacha20_poly1305_session *sess = priv_sess;
-  

RE: [EXTERNAL] [PATCH] crypto/ipsec_mb: update Arm IPsec-MB library tag

[Wathsala Wathawana Vithanage]

> Hi Wathsala,
> Any update on the updated tag and this patch?

Hi Akhil,
Tag SECLIB-IPSEC-2024.03.05 has been created.

Re: [PATCH] hash: make gfni stubs inline

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 11:14:45AM +0100, David Marchand wrote:
> On Mon, Mar 4, 2024 at 7:45 PM Stephen Hemminger
>  wrote:
> >
> > This reverts commit 07d836e5929d18ad6640ebae90dd2f81a2cafb71.
> >
> > Tyler found build issues with MSVC and the thash gfni stubs.
> > The problem would be link errors from missing symbols.
> 
> Trying to understand this link error.
> Does it come from the fact that rte_thash_gfni/rte_thash_gfni_bulk
> declarations are hidden under RTE_THASH_GFNI_DEFINED in
> rte_thash_gfni.h?
> 
> If so, why not always expose those two symbols unconditionnally and
> link with the stub only when ! RTE_THASH_GFNI_DEFINED.

So I don't have a lot of background of this lib.

I think we understand that we can't conditionally expose symbols. That's
what windows was picking up because it seems none of our CI's ever end
up with RTE_THASH_GFNI_DEFINED but my local test system did and failed.
(my experiments showed that Linux would complain too if it was defined)

If we always expose the symbols then as you point out we have to
conditionally link with the stub otherwise the inline (non-stub) will be
duplicate and build / link will fail.

I guess the part I don't understand with your suggestion is how we would
conditionally link with just the stub? We have to link with rte_hash to
get the rest of hash and the stub. I've probably missed something here.

Since we never had a release exposing the new symbols introduced by
Stephen in question my suggestion was that we just revert for 24.03 so
we don't end up with an ABI break later if we choose to solve the
problem without exports.

I don't know what else to do, but I think we need to decide for 24.03.

ty

> 
> -- 
> David Marchand

Re: [RFC 1/7] eal: extend bit manipulation functions

[Mattias Rönnblom]

On 2024-03-04 17:34, Tyler Retzlaff wrote:

On Sun, Mar 03, 2024 at 07:26:36AM +0100, Mattias Rönnblom wrote:

On 2024-03-02 18:05, Stephen Hemminger wrote:

On Sat, 2 Mar 2024 14:53:22 +0100
Mattias Rönnblom  wrote:


diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
index 449565eeae..9a368724d5 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -2,6 +2,7 @@
   * Copyright(c) 2020 Arm Limited
   * Copyright(c) 2010-2019 Intel Corporation
   * Copyright(c) 2023 Microsoft Corporation
+ * Copyright(c) 2024 Ericsson AB
   */


Unless this is coming from another project code base, the common
practice is not to add copyright for each contributor in later versions.



Unless it's a large contribution (compared to the rest of the file)?

I guess that's why the 916c50d commit adds the Microsoft copyright notice.


+/**
+ * Test if a particular bit in a 32-bit word is set.
+ *
+ * This function does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the 32-bit word to query.
+ * @param nr
+ *   The index of the bit (0-31).
+ * @return
+ *   Returns true if the bit is set, and false otherwise.
+ */
+static inline bool
+rte_bit_test32(const uint32_t *addr, unsigned int nr);


Is it possible to reorder these inlines to avoid having
forward declarations?



Yes, but I'm not sure it's a net gain.

A statement expression macro seems like a perfect tool for the job,
but then MSVC doesn't support statement expressions. You could also
have a macro that just generate the function body, as oppose to the
whole function.


statement expressions can be used even with MSVC when using C. but GCC
documentation discourages their use for C++. since the header is


GCC documentation discourages statement expressions *of a particular 
form* from being included in headers to be consumed by C++.


They would be fine to use here, especially considering they wouldn't be 
a part of the public API (i.e., only invoked from the static inline 
functions in the API).



consumed by C++ in addition to C it's preferrable to avoid them.



I'll consider if I should just bite the bullet and expand all the
macros. 4x duplication.


Also, new functions should be marked __rte_experimental
for a release or two.


Yes, thanks.

Re: [**EXTERNAL**] [PATCH 03/30] net/ice/base: remove unnecessary control queue array

[Gudimetla, Leela Sankar]

Hi @Qiming Yang, @Jacob 
Keller

Good day!
I am seeing  a crash in ice/base running DPDK-2111-stable. We use VPP.
While looking at DPDK-emails, I see some relevant changes here.
Can you please take a look at the back-trace and suggest/point if this has been 
found and fixed ?

(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x7fb6f9983773 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#2  0x7fb6f9938876 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7fb6f99237e3 in __GI_abort () at abort.c:79
#4  0x004083fa in os_exit (code=code@entry=1) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/vpp/vnet/main.c:434
#5  0x7fb6f9c6b8d1 in unix_signal_handler (signum=11, si=, 
uc=) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/vlib/unix/main.c:190
#6  
#7  0x7fb6b37e5850 in ice_sq_send_cmd_nolock (hw=0xac0318700, 
cq=0xac031a1c0, desc=0x7fb6b643c5e0, buf=0xac2a78200, buf_size=6, cd=0x0) at 
../git/drivers/net/ice/base/ice_controlq.c:1058
#8  0x7fb6b37f428a in ice_sq_send_cmd (hw=0xac0318700, cq=0xac031a1c0, 
desc=0x7fb6b643c5e0, buf=0xac2a78200, buf_size=6, cd=0x0) at 
../git/drivers/net/ice/base/ice_controlq.c:1126
#9  0x7fb6b3824ddb in ice_sq_send_cmd_retry (hw=0xac0318700, 
cq=0xac031a1c0, desc=0x7fb6b643c5e0, buf=0xac2a78200, buf_size=6, cd=0x0) at 
../git/drivers/net/ice/base/ice_common.c:1729
#10 0x7fb6b38335ee in ice_aq_send_cmd (hw=0xac0318700, desc=0x7fb6b643c5e0, 
buf=0xac2a78200, buf_size=6, cd=0x0) at 
../git/drivers/net/ice/base/ice_common.c:1788
#11 0x7fb6b3833fca in ice_aq_alloc_free_res (hw=0xac0318700, num_entries=1, 
buf=0xac2a78200, buf_size=6, opc=ice_aqc_opc_alloc_res, cd=0x0) at 
../git/drivers/net/ice/base/ice_common.c:2124
#12 0x7fb6b38340a1 in ice_alloc_hw_res (hw=0xac0318700, type=96, num=1, 
btm=false, res=0x7fb6b643f348) at ../git/drivers/net/ice/base/ice_common.c:2154
#13 0x7fb6b39e25e8 in ice_alloc_prof_id (hw=0xac0318700, blk=ICE_BLK_RSS, 
prof_id=0x7fb6b643f39f "") at ../git/drivers/net/ice/base/ice_flex_pipe.c:3309
#14 0x7fb6b3a03659 in ice_add_prof (hw=0xac0318700, blk=ICE_BLK_RSS, 
id=17179875328, ptypes=0xac2a790fc "", attr=0x0, attr_cnt=0, es=0xac2a78fd0, 
masks=0xac2a7909a, fd_swap=true)
at ../git/drivers/net/ice/base/ice_flex_pipe.c:5028
#15 0x7fb6b3a20210 in ice_flow_add_prof_sync (hw=0xac0318700, 
blk=ICE_BLK_RSS, dir=ICE_FLOW_RX, prof_id=17179875328, segs=0xac2a79200, 
segs_cnt=1 '\001', acts=0x0, acts_cnt=0 '\000',
prof=0x7fb6b6444f10) at ../git/drivers/net/ice/base/ice_flow.c:2245
#16 0x7fb6b3a20f9a in ice_flow_add_prof (hw=0xac0318700, blk=ICE_BLK_RSS, 
dir=ICE_FLOW_RX, prof_id=17179875328, segs=0xac2a79200, segs_cnt=1 '\001', 
acts=0x0, acts_cnt=0 '\000',
prof=0x7fb6b6444f10) at ../git/drivers/net/ice/base/ice_flow.c:2646
#17 0x7fb6b3a483af in ice_add_rss_cfg_sync (hw=0xac0318700, vsi_handle=0, 
cfg=0x7fb6b6444f60) at ../git/drivers/net/ice/base/ice_flow.c:4276
#18 0x7fb6b3a48503 in ice_add_rss_cfg (hw=0xac0318700, vsi_handle=0, 
cfg=0x7fb6b6444fe0) at ../git/drivers/net/ice/base/ice_flow.c:4329
#19 0x7fb6b3c18577 in ice_add_rss_cfg_wrap (pf=0xac031b718, vsi_id=0, 
cfg=0x7fb6b6444fe0) at ../git/drivers/net/ice/ice_ethdev.c:2998
#20 0x7fb6b3c186cc in ice_rss_hash_set (pf=0xac031b718, rss_hf=12220) at 
../git/drivers/net/ice/ice_ethdev.c:3038
#21 0x7fb6b3c2eba9 in ice_init_rss (pf=0xac031b718) at 
../git/drivers/net/ice/ice_ethdev.c:3289
#22 0x7fb6b3c2eccd in ice_dev_configure (dev=0x7fb6b8dc04c0 
) at ../git/drivers/net/ice/ice_ethdev.c:3323
#23 0x7fb6b8ca82a3 in rte_eth_dev_configure (port_id=0, nb_rx_q=2, 
nb_tx_q=3, dev_conf=0x7fb6bbde3820) at ../git/lib/ethdev/rte_ethdev.c:1633
#24 0x7fb6b8fb7fef in dpdk_device_setup (xd=xd@entry=0x7fb6bbde37c0) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/plugins/dpdk/device/common.c:92
#25 0x7fb6b8fcbe37 in dpdk_lib_init (dm=0x7fb6b901d260 ) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/plugins/dpdk/device/init.c:759
#26 0x7fb6b8fd0936 in dpdk_process (vm=0x4aef40 , 
rt=, f=)
at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/plugins/dpdk/device/init.c:1684
#27 0x7fb6f9c1c7b7 in vlib_process_bootstrap (_a=) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/vlib/main.c:1477
#28 0x7fb6f9b24ea8 in clib_calljmp () at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/vppinfra/longjmp.S:123
#29 0x7fb6b8656d10 in ?? ()
#30 0x7fb6f9c2075c in vlib_process_startup (f=0x0, p=0x7fb6b966e080, 
vm=0x4aef40 ) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/vlib/main.c:1502
#31 dispatch_process (vm=0x4aef40 , p=0x7fb6b966e080, 
last_time_stamp=, f=0x0) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+fdd8bd2f89-r0/git/src/vlib/main.c:1558

Re: [RFC 1/7] eal: extend bit manipulation functions

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 07:01:50PM +0100, Mattias Rönnblom wrote:
> On 2024-03-04 17:34, Tyler Retzlaff wrote:
> >On Sun, Mar 03, 2024 at 07:26:36AM +0100, Mattias Rönnblom wrote:
> >>On 2024-03-02 18:05, Stephen Hemminger wrote:
> >>>On Sat, 2 Mar 2024 14:53:22 +0100
> >>>Mattias Rönnblom  wrote:
> >>>
> diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
> index 449565eeae..9a368724d5 100644
> --- a/lib/eal/include/rte_bitops.h
> +++ b/lib/eal/include/rte_bitops.h
> @@ -2,6 +2,7 @@
>    * Copyright(c) 2020 Arm Limited
>    * Copyright(c) 2010-2019 Intel Corporation
>    * Copyright(c) 2023 Microsoft Corporation
> + * Copyright(c) 2024 Ericsson AB
>    */
> >>>
> >>>Unless this is coming from another project code base, the common
> >>>practice is not to add copyright for each contributor in later versions.
> >>>
> >>
> >>Unless it's a large contribution (compared to the rest of the file)?
> >>
> >>I guess that's why the 916c50d commit adds the Microsoft copyright notice.
> >>
> +/**
> + * Test if a particular bit in a 32-bit word is set.
> + *
> + * This function does not give any guarantees in regards to memory
> + * ordering or atomicity.
> + *
> + * @param addr
> + *   A pointer to the 32-bit word to query.
> + * @param nr
> + *   The index of the bit (0-31).
> + * @return
> + *   Returns true if the bit is set, and false otherwise.
> + */
> +static inline bool
> +rte_bit_test32(const uint32_t *addr, unsigned int nr);
> >>>
> >>>Is it possible to reorder these inlines to avoid having
> >>>forward declarations?
> >>>
> >>
> >>Yes, but I'm not sure it's a net gain.
> >>
> >>A statement expression macro seems like a perfect tool for the job,
> >>but then MSVC doesn't support statement expressions. You could also
> >>have a macro that just generate the function body, as oppose to the
> >>whole function.
> >
> >statement expressions can be used even with MSVC when using C. but GCC
> >documentation discourages their use for C++. since the header is
> 
> GCC documentation discourages statement expressions *of a particular
> form* from being included in headers to be consumed by C++.
> 
> They would be fine to use here, especially considering they wouldn't
> be a part of the public API (i.e., only invoked from the static
> inline functions in the API).

agreed, there should be no problem.

> 
> >consumed by C++ in addition to C it's preferrable to avoid them.
> >
> >>
> >>I'll consider if I should just bite the bullet and expand all the
> >>macros. 4x duplication.
> >>
> >>>Also, new functions should be marked __rte_experimental
> >>>for a release or two.
> >>
> >>Yes, thanks.

[PATCH] net/mlx5: fix async flow create error handling

[Dariusz Sosnowski]

Whenever processing of asynchronous flow rule create operation failed,
but after some dynamic flow actions had already been allocated,
these actions were not freed during error handling flow.
That behavior lead to leaks e.g., RSS/QUEUE action objects were leaked
which triggered assertions during device cleanup.

This patch adds flow rule cleanup handling in case of an error
during async flow rule creation.

Fixes: 3a2f674b6aa8 ("net/mlx5: add queue and RSS HW steering action")
Cc: suanmi...@nvidia.com
Cc: sta...@dpdk.org

Signed-off-by: Dariusz Sosnowski 
Acked-by: Ori Kam 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 78 +++--
 1 file changed, 55 insertions(+), 23 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 4216433c6e..5a407d592c 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -174,7 +174,7 @@ mlx5_flow_hw_aux_set_mtr_id(struct rte_flow_hw *flow,
aux->orig.mtr_id = mtr_id;
 }
 
-static __rte_always_inline uint32_t __rte_unused
+static __rte_always_inline uint32_t
 mlx5_flow_hw_aux_get_mtr_id(struct rte_flow_hw *flow, struct rte_flow_hw_aux 
*aux)
 {
if (unlikely(flow->operation_type == MLX5_FLOW_HW_FLOW_OP_TYPE_UPDATE))
@@ -183,6 +183,10 @@ mlx5_flow_hw_aux_get_mtr_id(struct rte_flow_hw *flow, 
struct rte_flow_hw_aux *au
return aux->orig.mtr_id;
 }
 
+static void
+flow_hw_age_count_release(struct mlx5_priv *priv, uint32_t queue, struct 
rte_flow_hw *flow,
+ struct rte_flow_error *error);
+
 static int
 mlx5_tbl_multi_pattern_process(struct rte_eth_dev *dev,
   struct rte_flow_template_table *tbl,
@@ -3034,6 +3038,31 @@ flow_hw_modify_field_construct(struct 
mlx5_modification_cmd *mhdr_cmd,
return 0;
 }
 
+/**
+ * Release any actions allocated for the flow rule during actions construction.
+ *
+ * @param[in] flow
+ *   Pointer to flow structure.
+ */
+static void
+flow_hw_release_actions(struct rte_eth_dev *dev,
+   uint32_t queue,
+   struct rte_flow_hw *flow)
+{
+   struct mlx5_priv *priv = dev->data->dev_private;
+   struct mlx5_aso_mtr_pool *pool = priv->hws_mpool;
+   struct rte_flow_hw_aux *aux = mlx5_flow_hw_aux(dev->data->port_id, 
flow);
+
+   if (flow->flags & MLX5_FLOW_HW_FLOW_FLAG_FATE_JUMP)
+   flow_hw_jump_release(dev, flow->jump);
+   else if (flow->flags & MLX5_FLOW_HW_FLOW_FLAG_FATE_HRXQ)
+   mlx5_hrxq_obj_release(dev, flow->hrxq);
+   if (flow->flags & MLX5_FLOW_HW_FLOW_FLAG_CNT_ID)
+   flow_hw_age_count_release(priv, queue, flow, NULL);
+   if (flow->flags & MLX5_FLOW_HW_FLOW_FLAG_MTR_ID)
+   mlx5_ipool_free(pool->idx_pool, 
mlx5_flow_hw_aux_get_mtr_id(flow, aux));
+}
+
 /**
  * Construct flow action array.
  *
@@ -3156,7 +3185,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
(dev, queue, action, table, it_idx,
 at->action_flags, flow,
 &rule_acts[act_data->action_dst]))
-   return -1;
+   goto error;
break;
case RTE_FLOW_ACTION_TYPE_VOID:
break;
@@ -3176,7 +3205,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
jump = flow_hw_jump_action_register
(dev, &table->cfg, jump_group, NULL);
if (!jump)
-   return -1;
+   goto error;
rule_acts[act_data->action_dst].action =
(!!attr.group) ? jump->hws_action : jump->root_action;
flow->jump = jump;
@@ -3188,7 +3217,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
ft_flag,
action);
if (!hrxq)
-   return -1;
+   goto error;
rule_acts[act_data->action_dst].action = hrxq->action;
flow->hrxq = hrxq;
flow->flags |= MLX5_FLOW_HW_FLOW_FLAG_FATE_HRXQ;
@@ -3198,19 +3227,19 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
if (flow_hw_shared_action_get
(dev, act_data, item_flags,
 &rule_acts[act_data->action_dst]))
-   return -1;
+   goto error;
break;
case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
enc_item = ((const struct rte_flow_action_vxlan_encap *)
   action->conf)->definition;
if (flow_

Re: [RFC 2/7] eal: add generic bit manipulation macros

[Mattias Rönnblom]

On 2024-03-04 17:42, Tyler Retzlaff wrote:

On Sat, Mar 02, 2024 at 02:53:23PM +0100, Mattias Rönnblom wrote:

Add bit-level test/set/clear/assign macros operating on both 32-bit
and 64-bit words by means of C11 generic selection.

Signed-off-by: Mattias Rönnblom 
---


_Generic is nice here. should we discourage direct use of the inline
functions in preference of using the macro always? either way lgtm.



That was something I considered, but decided against it for RFC v1. I 
wasn't even sure people would like _Generic.


The big upside of having only the _Generic macros would be a much 
smaller API, but maybe a tiny bit less (type-)safe to use.


Also, _Generic is new for DPDK, so who knows what issues it might cause 
with old compilers.


Thanks.


Acked-by: Tyler Retzlaff 


  lib/eal/include/rte_bitops.h | 81 
  1 file changed, 81 insertions(+)

diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
index 9a368724d5..afd0f11033 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -107,6 +107,87 @@ extern "C" {
  #define RTE_FIELD_GET64(mask, reg) \
((typeof(mask))(((reg) & (mask)) >> rte_ctz64(mask)))
  
+/**

+ * Test bit in word.
+ *
+ * Generic selection macro to test the value of a bit in a 32-bit or
+ * 64-bit word. The type of operation depends on the type of the @c
+ * addr parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ */
+#define rte_bit_test(addr, nr) \
+   _Generic((addr),\
+uint32_t *: rte_bit_test32,\
+uint64_t *: rte_bit_test64)(addr, nr)
+
+/**
+ * Set bit in word.
+ *
+ * Generic selection macro to set a bit in a 32-bit or 64-bit
+ * word. The type of operation depends on the type of the @c addr
+ * parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ */
+#define rte_bit_set(addr, nr)  \
+   _Generic((addr),\
+uint32_t *: rte_bit_set32, \
+uint64_t *: rte_bit_set64)(addr, nr)
+
+/**
+ * Clear bit in word.
+ *
+ * Generic selection macro to clear a bit in a 32-bit or 64-bit
+ * word. The type of operation depends on the type of the @c addr
+ * parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ */
+#define rte_bit_clear(addr, nr)\
+   _Generic((addr),\
+uint32_t *: rte_bit_clear32,   \
+uint64_t *: rte_bit_clear64)(addr, nr)
+
+/**
+ * Assign a value to a bit in word.
+ *
+ * Generic selection macro to assign a value to a bit in a 32-bit or 64-bit
+ * word. The type of operation depends on the type of the @c addr parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ * @param value
+ *   The new value of the bit - true for '1', or false for '0'.
+ */
+#define rte_bit_assign(addr, nr, value)\
+   _Generic((addr),\
+uint32_t *: rte_bit_assign32,  \
+uint64_t *: rte_bit_assign64)(addr, nr, value)
+
  /**
   * Test if a particular bit in a 32-bit word is set.
   *
--
2.34.1

Re: [PATCH] app/test: don't count skipped tests as executed

[Tyler Retzlaff]

On Mon, Nov 13, 2023 at 03:05:33PM +, Bruce Richardson wrote:
> The logic around skipped tests is a little confusing in the unit test
> runner.
> * Any explicitly disabled tests are counted as skipped but not
>   executed.
> * Any tests that return TEST_SKIPPED are counted as both skipped and
>   executed, using the same statistics counters.
> 
> This makes the stats very strange and hard to correlate, since the
> totals don't add up.  One would expect that SKIPPED + EXECUTED +
> UNSUPPORTED == TOTAL, and that PASSED + FAILED == EXECUTED.
> 
> To achieve this, mark any tests returning TEST_SKIPPED, or ENOTSUP as
> not having executed.
> 
> Signed-off-by: Bruce Richardson 
> ---

Clearly something that was skipped didn't get executed. Solid change.

Acked-by: Tyler Retzlaff 

Re: [RFC 2/7] eal: add generic bit manipulation macros

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 07:08:36PM +0100, Mattias Rönnblom wrote:
> On 2024-03-04 17:42, Tyler Retzlaff wrote:
> >On Sat, Mar 02, 2024 at 02:53:23PM +0100, Mattias Rönnblom wrote:
> >>Add bit-level test/set/clear/assign macros operating on both 32-bit
> >>and 64-bit words by means of C11 generic selection.
> >>
> >>Signed-off-by: Mattias Rönnblom 
> >>---
> >
> >_Generic is nice here. should we discourage direct use of the inline
> >functions in preference of using the macro always? either way lgtm.
> >
> 
> That was something I considered, but decided against it for RFC v1.
> I wasn't even sure people would like _Generic.
> 
> The big upside of having only the _Generic macros would be a much
> smaller API, but maybe a tiny bit less (type-)safe to use.

i'm curious what misuse pattern you anticipate or have seen that may be
less type-safe? just so i can look out for them.

i (perhaps naively) have liked generic functions for their selection of
the "correct" type and for _Generic if no leg/case exists compiler
error (as opposed to e.g. silent truncation).

> 
> Also, _Generic is new for DPDK, so who knows what issues it might
> cause with old compilers.

i was thinking about this overnight, it's supposed to be standard C11
and my use on various compilers showed no problem but I can't recall if
i did any evaluation when consuming as a part of a C++ translation unit
so there could be problems.

> 
> Thanks.
> 
> >Acked-by: Tyler Retzlaff 
> >
> >>  lib/eal/include/rte_bitops.h | 81 
> >>  1 file changed, 81 insertions(+)
> >>
> >>diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
> >>index 9a368724d5..afd0f11033 100644
> >>--- a/lib/eal/include/rte_bitops.h
> >>+++ b/lib/eal/include/rte_bitops.h
> >>@@ -107,6 +107,87 @@ extern "C" {
> >>  #define RTE_FIELD_GET64(mask, reg) \
> >>((typeof(mask))(((reg) & (mask)) >> rte_ctz64(mask)))
> >>+/**
> >>+ * Test bit in word.
> >>+ *
> >>+ * Generic selection macro to test the value of a bit in a 32-bit or
> >>+ * 64-bit word. The type of operation depends on the type of the @c
> >>+ * addr parameter.
> >>+ *
> >>+ * This macro does not give any guarantees in regards to memory
> >>+ * ordering or atomicity.
> >>+ *
> >>+ * @param addr
> >>+ *   A pointer to the word to modify.
> >>+ * @param nr
> >>+ *   The index of the bit.
> >>+ */
> >>+#define rte_bit_test(addr, nr) \
> >>+   _Generic((addr),\
> >>+uint32_t *: rte_bit_test32,\
> >>+uint64_t *: rte_bit_test64)(addr, nr)
> >>+
> >>+/**
> >>+ * Set bit in word.
> >>+ *
> >>+ * Generic selection macro to set a bit in a 32-bit or 64-bit
> >>+ * word. The type of operation depends on the type of the @c addr
> >>+ * parameter.
> >>+ *
> >>+ * This macro does not give any guarantees in regards to memory
> >>+ * ordering or atomicity.
> >>+ *
> >>+ * @param addr
> >>+ *   A pointer to the word to modify.
> >>+ * @param nr
> >>+ *   The index of the bit.
> >>+ */
> >>+#define rte_bit_set(addr, nr)  \
> >>+   _Generic((addr),\
> >>+uint32_t *: rte_bit_set32, \
> >>+uint64_t *: rte_bit_set64)(addr, nr)
> >>+
> >>+/**
> >>+ * Clear bit in word.
> >>+ *
> >>+ * Generic selection macro to clear a bit in a 32-bit or 64-bit
> >>+ * word. The type of operation depends on the type of the @c addr
> >>+ * parameter.
> >>+ *
> >>+ * This macro does not give any guarantees in regards to memory
> >>+ * ordering or atomicity.
> >>+ *
> >>+ * @param addr
> >>+ *   A pointer to the word to modify.
> >>+ * @param nr
> >>+ *   The index of the bit.
> >>+ */
> >>+#define rte_bit_clear(addr, nr)\
> >>+   _Generic((addr),\
> >>+uint32_t *: rte_bit_clear32,   \
> >>+uint64_t *: rte_bit_clear64)(addr, nr)
> >>+
> >>+/**
> >>+ * Assign a value to a bit in word.
> >>+ *
> >>+ * Generic selection macro to assign a value to a bit in a 32-bit or 64-bit
> >>+ * word. The type of operation depends on the type of the @c addr 
> >>parameter.
> >>+ *
> >>+ * This macro does not give any guarantees in regards to memory
> >>+ * ordering or atomicity.
> >>+ *
> >>+ * @param addr
> >>+ *   A pointer to the word to modify.
> >>+ * @param nr
> >>+ *   The index of the bit.
> >>+ * @param value
> >>+ *   The new value of the bit - true for '1', or false for '0'.
> >>+ */
> >>+#define rte_bit_assign(addr, nr, value)\
> >>+   _Generic((addr),\
> >>+uint32_t *: rte_bit_assign32,  \
> >>+uint64_t *: rte_bit_assign64)(addr, nr, value)
> >>+
> >>  /**
> >>   * Test if a particular bit in a 32-bit word is set.
> >>   *
> >>-- 
> >>2.34.1

Re: [PATCH] tests: assume c source files are utf-8 encoded

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 02:46:15PM +0100, Robin Jarry wrote:
> Instead of relying on the default locale from the environment (LC_ALL),
> explicitly read the files as utf-8 encoded.
> 
> Fixes: 0aeaf75df879 ("test: define unit tests suites based on test types")
> 
> Signed-off-by: Robin Jarry 
> ---

Acked-by: Tyler Retzlaff 

Re: [PATCH v2 45/71] event/dlb2: replace use of fixed size rte_memcpy

[Stephen Hemminger]

On Tue, 5 Mar 2024 17:07:02 +
"Sevincer, Abdullah"  wrote:

> Hi Stephen,
> 
> Are all rte_memcpy functions now be replaced by memcpy and no more use of 
> rte_memcpy?
> 

Long term yes. There is no reason for rte_memcpy to exist, it only exists 
because
the DPDK team at Intel was able to get a faster result for bulk copies than
the current glibc versions.

Medium term, it would be good to kill rte_memcpy for the fixed size case.
Already done for several other architectures.

Short term, none of this is urgent.

Re: reg. https://patches.dpdk.org/project/dpdk/list/?series=31200 - patch result

[Aaron Conole]

"Power, Ciara"  writes:

> + Patrick
>
>  
>
> From: Power, Ciara 
> Sent: Tuesday, March 5, 2024 10:05 AM
> To: Sivaramakrishnan, VenkatX ; Akhil 
> Goyal 
> Cc: Ji, Kai ; Aaron Conole 
> Subject: RE: reg. https://patches.dpdk.org/project/dpdk/list/?series=31200 - 
> patch result
>
>  
>
> Hi folks,
>
>  
>
> Had a quick look, I can also see this:
>
> crypto/ipsec_mb: IPSec_MB version >= 1.4.0 is required, found version 1.2.0

This version of ipsec_mb is less than 1 year old.  Did this pass any
other CI testing?  I would be surprised if it did - I'm not sure any
downstream environments that would be using it already.

> I guess the installed PMD .so file isn’t created because they are not 
> compiled in, due to the minimum version on
> environment not meeting the new requirements.

I don't see any such new requirements anywhere on the crypto tree.  The
only change I know about was for QAT to try and default to IPSec_MB 1.4,
but it is supposed to fall back to OpenSSL if that is unavailable.  Did
this change?

> CC’ing Aaron, who might know about upgrading that environment to ipsec-mb 
> v1.4.
>
>  
>
> Thanks,
>
> Ciara
>
>  
>
> From: Sivaramakrishnan, VenkatX  
> Sent: Monday, March 4, 2024 10:45 AM
> To: Akhil Goyal 
> Cc: Ji, Kai ; Power, Ciara 
> Subject: reg. https://patches.dpdk.org/project/dpdk/list/?series=31200 - 
> patch result
>
>  
>
> Hi Akhil,
>
>  
>
> I would like to provide details of the failures
>
>  
>
>  
>
> *
>
>  
>
>  
>
> Failures details:
>
> 
>
> "Build and test" failed for "librte_crypto_ipsec_mb.so". 
>
> doc: remove outdated version details · ovsrobot/dpdk@f40ab34 (github.com)
>
> Error: cannot find librte_crypto_ipsec_mb.so.24.0 in install
>
>  
>
> Looks like, “ipsec mb” was not installed on the server. 
>
>  
>
> However, the patch changes are related to the Doc update. Hope that this will 
> not impact patch merging 
>
>  
>
>Thank you.
>
>  
>
> Best Regards,
>
> Venkat.

Re: [PATCH] hash: make gfni stubs inline

[Stephen Hemminger]

On Tue, 5 Mar 2024 09:53:00 -0800
Tyler Retzlaff  wrote:

> On Tue, Mar 05, 2024 at 11:14:45AM +0100, David Marchand wrote:
> > On Mon, Mar 4, 2024 at 7:45 PM Stephen Hemminger
> >  wrote:  
> > >
> > > This reverts commit 07d836e5929d18ad6640ebae90dd2f81a2cafb71.
> > >
> > > Tyler found build issues with MSVC and the thash gfni stubs.
> > > The problem would be link errors from missing symbols.  
> > 
> > Trying to understand this link error.
> > Does it come from the fact that rte_thash_gfni/rte_thash_gfni_bulk
> > declarations are hidden under RTE_THASH_GFNI_DEFINED in
> > rte_thash_gfni.h?
> > 
> > If so, why not always expose those two symbols unconditionnally and
> > link with the stub only when ! RTE_THASH_GFNI_DEFINED.  
> 
> So I don't have a lot of background of this lib.
> 
> I think we understand that we can't conditionally expose symbols. That's
> what windows was picking up because it seems none of our CI's ever end
> up with RTE_THASH_GFNI_DEFINED but my local test system did and failed.
> (my experiments showed that Linux would complain too if it was defined)
> 
> If we always expose the symbols then as you point out we have to
> conditionally link with the stub otherwise the inline (non-stub) will be
> duplicate and build / link will fail.
> 
> I guess the part I don't understand with your suggestion is how we would
> conditionally link with just the stub? We have to link with rte_hash to
> get the rest of hash and the stub. I've probably missed something here.
> 
> Since we never had a release exposing the new symbols introduced by
> Stephen in question my suggestion was that we just revert for 24.03 so
> we don't end up with an ABI break later if we choose to solve the
> problem without exports.
> 
> I don't know what else to do, but I think we need to decide for 24.03.
> 
> ty

Another option would be introduce dead code stubs all the time.
Then have inline wrapper that redirect to the dead stub if needed.

Something like:
From 7bb972d342e939200f8f993a9074b20794941f6a Mon Sep 17 00:00:00 2001
From: Stephen Hemminger 
Date: Tue, 5 Mar 2024 10:42:48 -0800
Subject: [PATCH] hash: rename GFNI stubs

Make the GFNI stub functions always built. This solves the conditional
linking problem. If GFNI is available, they will never get used.

Signed-off-by: Stephen Hemminger 
---
 lib/hash/rte_thash_gfni.c | 11 +--
 lib/hash/rte_thash_gfni.h | 23 ++-
 lib/hash/version.map  |  9 +++--
 3 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/lib/hash/rte_thash_gfni.c b/lib/hash/rte_thash_gfni.c
index f1525f9838de..de67abb8b211 100644
--- a/lib/hash/rte_thash_gfni.c
+++ b/lib/hash/rte_thash_gfni.c
@@ -4,18 +4,18 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
-#ifndef RTE_THASH_GFNI_DEFINED
-
 RTE_LOG_REGISTER_SUFFIX(hash_gfni_logtype, gfni, INFO);
 #define RTE_LOGTYPE_HASH hash_gfni_logtype
 #define HASH_LOG(level, ...) \
RTE_LOG_LINE(level, HASH, "" __VA_ARGS__)
 
+__rte_internal
 uint32_t
-rte_thash_gfni(const uint64_t *mtrx __rte_unused,
+___rte_thash_gfni(const uint64_t *mtrx __rte_unused,
const uint8_t *key __rte_unused, int len __rte_unused)
 {
static bool warned;
@@ -29,8 +29,9 @@ rte_thash_gfni(const uint64_t *mtrx __rte_unused,
return 0;
 }
 
+__rte_internal
 void
-rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
+___rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
int len __rte_unused, uint8_t *tuple[] __rte_unused,
uint32_t val[], uint32_t num)
 {
@@ -47,5 +48,3 @@ rte_thash_gfni_bulk(const uint64_t *mtrx __rte_unused,
for (i = 0; i < num; i++)
val[i] = 0;
 }
-
-#endif
diff --git a/lib/hash/rte_thash_gfni.h b/lib/hash/rte_thash_gfni.h
index eed55fc86c86..1cb61cf39675 100644
--- a/lib/hash/rte_thash_gfni.h
+++ b/lib/hash/rte_thash_gfni.h
@@ -9,7 +9,16 @@
 extern "C" {
 #endif
 
-#include 
+#include 
+/*
+ * @internal
+ * Stubs defined for use when GFNI is not available
+ */
+uint32_t
+___rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len);
+void
+___rte_thash_gfni_bulk(const uint64_t *mtrx, int len, uint8_t *tuple[],
+  uint32_t val[], uint32_t num);
 
 #ifdef RTE_ARCH_X86
 
@@ -18,10 +27,8 @@ extern "C" {
 #endif
 
 #ifndef RTE_THASH_GFNI_DEFINED
-
 /**
  * Calculate Toeplitz hash.
- * Dummy implementation.
  *
  * @param m
  *  Pointer to the matrices generated from the corresponding
@@ -34,7 +41,10 @@ extern "C" {
  *  Calculated Toeplitz hash value.
  */
 uint32_t
-rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len);
+rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int len)
+{
+   return ___rte_thash_gfni(mtrx, key, len);
+}
 
 /**
  * Bulk implementation for Toeplitz hash.
@@ -55,7 +65,10 @@ rte_thash_gfni(const uint64_t *mtrx, const uint8_t *key, int 
len);
  */
 void
 rte_thash_gfni_bulk(const uint64_t *mtrx, int len, uint8_t *tuple[],
-   uint32_t val[], uint32_t num);
+   uint32_t val

RE: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

[Akhil Goyal]

> Subject: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec
> Multi-buffer version
> 
> From: Sivaramakrishnan Venkat 
> 
> SW PMDs increment IPsec Multi-buffer version to 1.4.
> A minimum IPsec Multi-buffer version of 1.4 or greater is now required.
> 
> Signed-off-by: Sivaramakrishnan Venkat 
> Acked-by: Ciara Power 
> Acked-by: Pablo de Lara 
> Acked-by: Wathsala Vithanage 
please check these:
https://github.com/ovsrobot/dpdk/actions/runs/8160942783/job/22308639670#step:19:19411
Error: cannot find librte_crypto_ipsec_mb.so.24.0 in install
You need to get this fixed or else CI would fail for every patch once this 
series is applied.
And this is also failing 
http://mails.dpdk.org/archives/test-report/2024-March/601301.html
These need to be fixed in CI infra.

Re: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

[Patrick Robb]

On Tue, Mar 5, 2024 at 2:11 PM Akhil Goyal  wrote:
>
> > Subject: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec
> > Multi-buffer version
> >
> > From: Sivaramakrishnan Venkat 
> >
> > SW PMDs increment IPsec Multi-buffer version to 1.4.
> > A minimum IPsec Multi-buffer version of 1.4 or greater is now required.
> >
> > Signed-off-by: Sivaramakrishnan Venkat 
> > Acked-by: Ciara Power 
> > Acked-by: Pablo de Lara 
> > Acked-by: Wathsala Vithanage 
> please check these:
> https://github.com/ovsrobot/dpdk/actions/runs/8160942783/job/22308639670#step:19:19411
> Error: cannot find librte_crypto_ipsec_mb.so.24.0 in install
Aaron has some questions about whether the upgrade is appropriate or
not in another thread. If/when those are resolved, I think he will be
able to upgrade the robot to 1.4.

> You need to get this fixed or else CI would fail for every patch once this 
> series is applied.
> And this is also failing 
> http://mails.dpdk.org/archives/test-report/2024-March/601301.html
> These need to be fixed in CI infra.

For context, we had upgraded a couple weeks ago to tip of main on the
arm ipsec-mb repo, and the v4 of this series was passing at that
point.

https://patchwork.dpdk.org/project/dpdk/list/?series=31200&state=%2A&archive=both

I see that there have been some subsequent commits since then and I
see in the other thread Wathsala created a SECLIB-IPSEC-2024.03.05 tag
today. We can rebuild from that tag right now and issue reruns. If the
updated arm repo resolves the issues seen here, you should see the IOL
CI results go green tonight.

Re: [PATCH v7 08/39] mbuf: use C11 alignas

[David Marchand]

On Tue, Mar 5, 2024 at 6:37 PM Tyler Retzlaff
 wrote:
> > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > > index 5688683..917a811 100644
> > > --- a/lib/mbuf/rte_mbuf_core.h
> > > +++ b/lib/mbuf/rte_mbuf_core.h
> > > @@ -463,7 +463,7 @@ enum {
> > >  /**
> > >   * The generic rte_mbuf, containing a packet mbuf.
> > >   */
> > > -struct rte_mbuf {
> > > +struct __rte_cache_aligned rte_mbuf {
> > > RTE_MARKER cacheline0;
> > >
> > > void *buf_addr;   /**< Virtual address of segment buffer. 
> > > */
> > > @@ -476,7 +476,7 @@ struct rte_mbuf {
> > >  * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
> > >  * working on vector drivers easier.
> > >  */
> > > -   rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> > > +   alignas(sizeof(rte_iova_t)) rte_iova_t buf_iova;
> > >  #else
> > > /**
> > >  * Next segment of scattered packet.
> > > @@ -662,7 +662,7 @@ struct rte_mbuf {
> > > uint16_t timesync;
> > >
> > > uint32_t dynfield1[9]; /**< Reserved for dynamic fields. */
> > > -} __rte_cache_aligned;
> > > +};
> >
> > I probably missed the discussion, but why is cacheline1 not handled in
> > this patch?
> > I was expecting a:
> > -   RTE_MARKER cacheline1 __rte_cache_min_aligned;
> > +   alignas(RTE_CACHE_LINE_MIN_SIZE) RTE_MARKER cacheline1;
>
> I should have replaced it I just missed it. Could I get you to fix it up?
> We have 2 options.
>
> 1. You can leave it as is, eventually the other series I have dealing
>with the markers I will probably remove the cacheline1 marker anyway.
>
> 2. You could adjust it as you've identified above, just move alignas
>before the field type and name.

I like consistency, let's go with option 2.

I'll adjust as I mentionned, no need for a v8.
I already tested it in my builds.

Thanks.

-- 
David Marchand

Re: [RFC 2/7] eal: add generic bit manipulation macros

[Mattias Rönnblom]

On 2024-03-05 19:22, Tyler Retzlaff wrote:

On Tue, Mar 05, 2024 at 07:08:36PM +0100, Mattias Rönnblom wrote:

On 2024-03-04 17:42, Tyler Retzlaff wrote:

On Sat, Mar 02, 2024 at 02:53:23PM +0100, Mattias Rönnblom wrote:

Add bit-level test/set/clear/assign macros operating on both 32-bit
and 64-bit words by means of C11 generic selection.

Signed-off-by: Mattias Rönnblom 
---


_Generic is nice here. should we discourage direct use of the inline
functions in preference of using the macro always? either way lgtm.



That was something I considered, but decided against it for RFC v1.
I wasn't even sure people would like _Generic.

The big upside of having only the _Generic macros would be a much
smaller API, but maybe a tiny bit less (type-)safe to use.


i'm curious what misuse pattern you anticipate or have seen that may be
less type-safe? just so i can look out for them.



That was just a gut feeling, not to be taken too seriously.

uint32_t *p = some_void_pointer;
/../
rte_bit_set32(p, 17);

A code section like this is redundant in the way the type (or at least 
type size) is coded both into the function name, and the pointer type. 
The use of rte_set_bit() will eliminate this, which is good (DRY), and 
bad, because now the type isn't "double-checked".


As you can see, it's a pretty weak argument.


i (perhaps naively) have liked generic functions for their selection of
the "correct" type and for _Generic if no leg/case exists compiler
error (as opposed to e.g. silent truncation).



Also, _Generic is new for DPDK, so who knows what issues it might
cause with old compilers.


i was thinking about this overnight, it's supposed to be standard C11
and my use on various compilers showed no problem but I can't recall if
i did any evaluation when consuming as a part of a C++ translation unit
so there could be problems.



It would be unfortunate if DPDK was prohibited from using _Generic.



Thanks.


Acked-by: Tyler Retzlaff 


  lib/eal/include/rte_bitops.h | 81 
  1 file changed, 81 insertions(+)

diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
index 9a368724d5..afd0f11033 100644
--- a/lib/eal/include/rte_bitops.h
+++ b/lib/eal/include/rte_bitops.h
@@ -107,6 +107,87 @@ extern "C" {
  #define RTE_FIELD_GET64(mask, reg) \
((typeof(mask))(((reg) & (mask)) >> rte_ctz64(mask)))
+/**
+ * Test bit in word.
+ *
+ * Generic selection macro to test the value of a bit in a 32-bit or
+ * 64-bit word. The type of operation depends on the type of the @c
+ * addr parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ */
+#define rte_bit_test(addr, nr) \
+   _Generic((addr),\
+uint32_t *: rte_bit_test32,\
+uint64_t *: rte_bit_test64)(addr, nr)
+
+/**
+ * Set bit in word.
+ *
+ * Generic selection macro to set a bit in a 32-bit or 64-bit
+ * word. The type of operation depends on the type of the @c addr
+ * parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ */
+#define rte_bit_set(addr, nr)  \
+   _Generic((addr),\
+uint32_t *: rte_bit_set32, \
+uint64_t *: rte_bit_set64)(addr, nr)
+
+/**
+ * Clear bit in word.
+ *
+ * Generic selection macro to clear a bit in a 32-bit or 64-bit
+ * word. The type of operation depends on the type of the @c addr
+ * parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ */
+#define rte_bit_clear(addr, nr)\
+   _Generic((addr),\
+uint32_t *: rte_bit_clear32,   \
+uint64_t *: rte_bit_clear64)(addr, nr)
+
+/**
+ * Assign a value to a bit in word.
+ *
+ * Generic selection macro to assign a value to a bit in a 32-bit or 64-bit
+ * word. The type of operation depends on the type of the @c addr parameter.
+ *
+ * This macro does not give any guarantees in regards to memory
+ * ordering or atomicity.
+ *
+ * @param addr
+ *   A pointer to the word to modify.
+ * @param nr
+ *   The index of the bit.
+ * @param value
+ *   The new value of the bit - true for '1', or false for '0'.
+ */
+#define rte_bit_assign(addr, nr, value)\
+   _Generic((addr),\
+uint32_t *: rte_bit_assign32,  \
+uint64_t *: rte_bit_assign64)(addr, nr, value)
+
  /**
   * Test if a 

Re: [PATCH v7 00/39] use C11 alignas

[David Marchand]

On Mon, Mar 4, 2024 at 6:53 PM Tyler Retzlaff
 wrote:
>
> The current location used for __rte_aligned(a) for alignment of types
> and variables is not compatible with MSVC. There is only a single
> location accepted by both toolchains.
>
> For variables standard C11 offers alignas(a) supported by conformant
> compilers i.e. both MSVC and GCC.
>
> For types the standard offers no alignment facility that compatibly
> interoperates with C and C++ but may be achieved by relocating the
> placement of __rte_aligned(a) to the aforementioned location accepted
> by all currently supported toolchains.
>
> ** NOTE **
>
> Finally, In the interest of not creating more API (internal or not) the
> series does not introduce a wrapper for C11 alignas. If we don't introduce
> a macro an application can't take a dependency.

I have been looking into adding some check so that we catch new
introductions of __rte_*aligned calls...
Wdyt of:

diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index c47ea59501..632397f42d 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -336,6 +336,21 @@ check_internal_tags() { # 
return $res
 }

+check_aligned_attributes() { # 
+   res=0
+
+   for token in __rte_aligned __rte_cache_aligned
__rte_cache_min_aligned; do
+   if [ $(grep -E '^\+.*\<'$token'\>' "$1" | \
+   grep -vE
'\<(struct|union)[[:space:]]*'$token'\>' | \
+   wc -l) != 0 ]; then
+   echo "Please only use $token for struct or
union types alignment."
+   res=1
+   fi
+   done
+
+   return $res
+}
+
 check_release_notes() { # 
rel_notes_prefix=doc/guides/rel_notes/release_
IFS=. read year month release < VERSION
@@ -445,6 +460,14 @@ check () { #  
ret=1
fi

+   ! $verbose || printf '\nChecking alignment attributes:\n'
+   report=$(check_aligned_attributes "$tmpinput")
+   if [ $? -ne 0 ] ; then
+   $headline_printed || print_headline "$subject"
+   printf '%s\n' "$report"
+   ret=1
+   fi
+
! $verbose || printf '\nChecking release notes updates:\n'
report=$(check_release_notes "$tmpinput")
if [ $? -ne 0 ] ; then


-- 
David Marchand

RTE lock

[Mattias Rönnblom]

Shouldn't we have a DPDK-native mutex API, rather than using direct 
POSIX mutex lock calls?


There are two reasons for this, as I see it
1) more cleanly support non-POSIX operating system (i.e., Microsoft 
Windows).
2) to discourage mechanical use of spinlocks in places where a regular 
mutex lock is more appropriate.


I think (and hope) DPDK developers will tend to pick DPDK-native rather 
than other APIs as their first choice.


For locks, they go for spinlocks, even in control (non-fast 
path/non-packet processing) code paths (e.g., calls made by the typical 
non-EAL thread).


Using spinlocks to synchronize threads that may be preempted aren't 
great idea.

Re: [RFC 2/7] eal: add generic bit manipulation macros

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 09:02:34PM +0100, Mattias Rönnblom wrote:
> On 2024-03-05 19:22, Tyler Retzlaff wrote:
> >On Tue, Mar 05, 2024 at 07:08:36PM +0100, Mattias Rönnblom wrote:
> >>On 2024-03-04 17:42, Tyler Retzlaff wrote:
> >>>On Sat, Mar 02, 2024 at 02:53:23PM +0100, Mattias Rönnblom wrote:
> Add bit-level test/set/clear/assign macros operating on both 32-bit
> and 64-bit words by means of C11 generic selection.
> 
> Signed-off-by: Mattias Rönnblom 
> ---
> >>>
> >>>_Generic is nice here. should we discourage direct use of the inline
> >>>functions in preference of using the macro always? either way lgtm.
> >>>
> >>
> >>That was something I considered, but decided against it for RFC v1.
> >>I wasn't even sure people would like _Generic.
> >>
> >>The big upside of having only the _Generic macros would be a much
> >>smaller API, but maybe a tiny bit less (type-)safe to use.
> >
> >i'm curious what misuse pattern you anticipate or have seen that may be
> >less type-safe? just so i can look out for them.
> >
> 
> That was just a gut feeling, not to be taken too seriously.
> 
> uint32_t *p = some_void_pointer;
> /../
> rte_bit_set32(p, 17);
> 
> A code section like this is redundant in the way the type (or at
> least type size) is coded both into the function name, and the
> pointer type. The use of rte_set_bit() will eliminate this, which is
> good (DRY), and bad, because now the type isn't "double-checked".
> 
> As you can see, it's a pretty weak argument.
> 
> >i (perhaps naively) have liked generic functions for their selection of
> >the "correct" type and for _Generic if no leg/case exists compiler
> >error (as opposed to e.g. silent truncation).
> >
> >>
> >>Also, _Generic is new for DPDK, so who knows what issues it might
> >>cause with old compilers.
> >
> >i was thinking about this overnight, it's supposed to be standard C11
> >and my use on various compilers showed no problem but I can't recall if
> >i did any evaluation when consuming as a part of a C++ translation unit
> >so there could be problems.
> >
> 
> It would be unfortunate if DPDK was prohibited from using _Generic.

I agree, I don't think it should be prohibited. If C++ poses a problem
we can work to find solutions.

> 
> >>
> >>Thanks.
> >>
> >>>Acked-by: Tyler Retzlaff 
> >>>
>   lib/eal/include/rte_bitops.h | 81 
>   1 file changed, 81 insertions(+)
> 
> diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
> index 9a368724d5..afd0f11033 100644
> --- a/lib/eal/include/rte_bitops.h
> +++ b/lib/eal/include/rte_bitops.h
> @@ -107,6 +107,87 @@ extern "C" {
>   #define RTE_FIELD_GET64(mask, reg) \
>   ((typeof(mask))(((reg) & (mask)) >> rte_ctz64(mask)))
> +/**
> + * Test bit in word.
> + *
> + * Generic selection macro to test the value of a bit in a 32-bit or
> + * 64-bit word. The type of operation depends on the type of the @c
> + * addr parameter.
> + *
> + * This macro does not give any guarantees in regards to memory
> + * ordering or atomicity.
> + *
> + * @param addr
> + *   A pointer to the word to modify.
> + * @param nr
> + *   The index of the bit.
> + */
> +#define rte_bit_test(addr, nr)   \
> + _Generic((addr),\
> +  uint32_t *: rte_bit_test32,\
> +  uint64_t *: rte_bit_test64)(addr, nr)
> +
> +/**
> + * Set bit in word.
> + *
> + * Generic selection macro to set a bit in a 32-bit or 64-bit
> + * word. The type of operation depends on the type of the @c addr
> + * parameter.
> + *
> + * This macro does not give any guarantees in regards to memory
> + * ordering or atomicity.
> + *
> + * @param addr
> + *   A pointer to the word to modify.
> + * @param nr
> + *   The index of the bit.
> + */
> +#define rte_bit_set(addr, nr)\
> + _Generic((addr),\
> +  uint32_t *: rte_bit_set32, \
> +  uint64_t *: rte_bit_set64)(addr, nr)
> +
> +/**
> + * Clear bit in word.
> + *
> + * Generic selection macro to clear a bit in a 32-bit or 64-bit
> + * word. The type of operation depends on the type of the @c addr
> + * parameter.
> + *
> + * This macro does not give any guarantees in regards to memory
> + * ordering or atomicity.
> + *
> + * @param addr
> + *   A pointer to the word to modify.
> + * @param nr
> + *   The index of the bit.
> + */
> +#define rte_bit_clear(addr, nr)  \
> + _Generic((addr),\
> +  uint32_t *: rte_bit_clear32,   \
> +  uint64_t *: rte_bit_clear64)(addr, nr)
> +
> +/**
> + * Assign a value to a bit in 

Re: RTE lock

[Tyler Retzlaff]

On Tue, Mar 05, 2024 at 09:18:20PM +0100, Mattias Rönnblom wrote:
> Shouldn't we have a DPDK-native mutex API, rather than using direct
> POSIX mutex lock calls?

David raised this a while back and the consensus is yes. I admit it's
been on my radar for a long time for the obvious reasons you list below
but with other work hasn't been a priority (yet).

> 
> There are two reasons for this, as I see it
> 1) more cleanly support non-POSIX operating system (i.e., Microsoft
> Windows).
> 2) to discourage mechanical use of spinlocks in places where a
> regular mutex lock is more appropriate.
> 
> I think (and hope) DPDK developers will tend to pick DPDK-native
> rather than other APIs as their first choice.

I spent some time evaluating C11 mutex but it really didn't strike me as
being fit for purpose so I think DPDK-native is probably the only way to
go. If behind the scenes particular locks relied on something standard
for Windows perhaps it could be hidden as an implementation detail.

> 
> For locks, they go for spinlocks, even in control (non-fast
> path/non-packet processing) code paths (e.g., calls made by the
> typical non-EAL thread).
> 
> Using spinlocks to synchronize threads that may be preempted aren't
> great idea.

If you're thinking of looking into this i'd be happy to see it solved.

ty

Re: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

[Patrick Robb]

Recheck-request: iol-unit-arm64-testing

Re: [PATCH v2] config/arm: add Marvell Odyssey

[Ruifeng Wang]

On 2024/3/5 7:13 PM, Anoob Joseph wrote:

Add meson build configuration for Marvell Odyssey platform with 64-bit
ARM Neoverse V2 cores.

Signed-off-by: Anoob Joseph 
---

Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")

Changes in v2:
- Renamed config file

  config/arm/arm64_odyssey_linux_gcc | 17 +
  config/arm/meson.build | 15 +++
  2 files changed, 32 insertions(+)
  create mode 100644 config/arm/arm64_odyssey_linux_gcc

diff --git a/config/arm/arm64_odyssey_linux_gcc 
b/config/arm/arm64_odyssey_linux_gcc
new file mode 100644
index 00..69b5cd42d8
--- /dev/null
+++ b/config/arm/arm64_odyssey_linux_gcc
@@ -0,0 +1,17 @@
+[binaries]
+c = ['ccache', 'aarch64-marvell-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-marvell-linux-gnu-g++']
+ar = 'aarch64-marvell-linux-gnu-gcc-ar'
+strip = 'aarch64-marvell-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv9-a'
+endian = 'little'
+
+[properties]
+platform = 'odyssey'
+
+[built-in options]
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3886d0e2dc..94159efaa4 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -500,6 +500,20 @@ soc_n2 = {
  'numa': false
  }
  
+soc_odyssey = {

+'description' : 'Marvell Odyssey',
+'implementer' : '0x41',
+'flags': [
+['RTE_MAX_LCORE', 80],
+['RTE_MAX_NUMA_NODES', 1],
+['RTE_MEMPOOL_ALIGN', 128],
+],
+'part_number': '0xd4f',
+'extra_march_features': ['crypto'],
+'numa': false,
+'sve_acle': false
+}
+
  soc_cn9k = {
  'description': 'Marvell OCTEON 9',
  'implementer': '0x43',
@@ -617,6 +631,7 @@ socs = {
  'kunpeng930': soc_kunpeng930,
  'n1sdp': soc_n1sdp,
  'n2': soc_n2,
+'odyssey' : soc_odyssey,


The SoC string list above also needs update. It is for documentation.
With the change:
Reviewed-by: Ruifeng Wang 


  'stingray': soc_stingray,
  'thunderx2': soc_thunderx2,
  'thunderxt88': soc_thunderxt88,

Re: [PATCH v2] config/arm: add Marvell Odyssey

[Honnappa Nagarahalli]

> On Mar 5, 2024, at 5:13 AM, Anoob Joseph  wrote:
> 
> Add meson build configuration for Marvell Odyssey platform with 64-bit
> ARM Neoverse V2 cores.
> 
> Signed-off-by: Anoob Joseph 
> ---
> 
> Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")
> 
> Changes in v2:
> - Renamed config file
> 
> config/arm/arm64_odyssey_linux_gcc | 17 +
> config/arm/meson.build | 15 +++
> 2 files changed, 32 insertions(+)
> create mode 100644 config/arm/arm64_odyssey_linux_gcc
> 
> diff --git a/config/arm/arm64_odyssey_linux_gcc 
> b/config/arm/arm64_odyssey_linux_gcc
> new file mode 100644
> index 00..69b5cd42d8
> --- /dev/null
> +++ b/config/arm/arm64_odyssey_linux_gcc
> @@ -0,0 +1,17 @@
> +[binaries]
> +c = ['ccache', 'aarch64-marvell-linux-gnu-gcc']
> +cpp = ['ccache', 'aarch64-marvell-linux-gnu-g++']
> +ar = 'aarch64-marvell-linux-gnu-gcc-ar'
> +strip = 'aarch64-marvell-linux-gnu-strip'
> +pkgconfig = 'aarch64-linux-gnu-pkg-config'
> +
> +[host_machine]
> +system = 'linux'
> +cpu_family = 'aarch64'
> +cpu = 'armv9-a'
> +endian = 'little'
> +
> +[properties]
> +platform = 'odyssey'
> +
> +[built-in options]

Just thinking out loud, given that this is a 80 core V2 machine, do we need 
cross compilation support? I have the same question for Grace machine as well. 
I am thinking we should have cross compilation support only for embedded 
platforms.


> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 3886d0e2dc..94159efaa4 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -500,6 +500,20 @@ soc_n2 = {
> 'numa': false
> }
> 
> +soc_odyssey = {
> +'description' : 'Marvell Odyssey',
> +'implementer' : '0x41',
> +'flags': [
> +['RTE_MAX_LCORE', 80],
> +['RTE_MAX_NUMA_NODES', 1],
> +['RTE_MEMPOOL_ALIGN', 128],
> +],
> +'part_number': '0xd4f',
> +'extra_march_features': ['crypto'],
> +'numa': false,
> +'sve_acle': false
> +}
> +
Can you move it such that it is sorted alphabetically?

> soc_cn9k = {
> 'description': 'Marvell OCTEON 9',
> 'implementer': '0x43',
> @@ -617,6 +631,7 @@ socs = {
> 'kunpeng930': soc_kunpeng930,
> 'n1sdp': soc_n1sdp,
> 'n2': soc_n2,
> +'odyssey' : soc_odyssey,
> 'stingray': soc_stingray,
> 'thunderx2': soc_thunderx2,
> 'thunderxt88': soc_thunderxt88,
> -- 
> 2.25.1
> 

Re: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

[Patrick Robb]

On Tue, Mar 5, 2024 at 6:30 PM Patrick Robb  wrote:
>
> Recheck-request: iol-unit-arm64-testing

https://mails.dpdk.org/archives/test-report/2024-March/601582.html

Hello. I wanted to flag this as still failing on arm after running the
testing using the new tag Wathsala published today. We did it via a
debian 12 container image which we rebuilt today with all the ipsec
dependencies and arm ipsec install. We simply:

git clone --depth 1 --branch SECLIB-IPSEC-2024.03.05
https://git.gitlab.arm.com/arm-reference-solutions/ipsec-mb.git
make -j $(nproc)
make install

then build DPDK.

Wathsala, what do you think? Might I be missing something here?

RE: [PATCH v2] config/arm: add Marvell Odyssey

[Anoob Joseph]

Hi Honnappa,

Thanks for the review. Please see inline.

Thanks,
Anoob

> -Original Message-
> From: Honnappa Nagarahalli 
> Sent: Wednesday, March 6, 2024 8:50 AM
> To: Anoob Joseph 
> Cc: Juraj Linkeš ; tho...@monjalon.net; David
> Marchand ; Jerin Jacob ; nd
> ; Pavan Nikhilesh Bhagavatula ;
> Ruifeng Wang ; Wathsala Wathawana Vithanage
> ; dev@dpdk.org
> Subject: [EXTERNAL] Re: [PATCH v2] config/arm: add Marvell Odyssey
> 
> Prioritize security for external emails: Confirm sender and content safety 
> before
> clicking links or opening attachments
> 
> --
> 
> 
> > On Mar 5, 2024, at 5:13 AM, Anoob Joseph  wrote:
> >
> > Add meson build configuration for Marvell Odyssey platform with 64-bit
> > ARM Neoverse V2 cores.
> >
> > Signed-off-by: Anoob Joseph 
> > ---
> >
> > Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")
> >
> > Changes in v2:
> > - Renamed config file
> >
> > config/arm/arm64_odyssey_linux_gcc | 17 +
> > config/arm/meson.build | 15 +++
> > 2 files changed, 32 insertions(+)
> > create mode 100644 config/arm/arm64_odyssey_linux_gcc
> >
> > diff --git a/config/arm/arm64_odyssey_linux_gcc
> > b/config/arm/arm64_odyssey_linux_gcc
> > new file mode 100644
> > index 00..69b5cd42d8
> > --- /dev/null
> > +++ b/config/arm/arm64_odyssey_linux_gcc
> > @@ -0,0 +1,17 @@
> > +[binaries]
> > +c = ['ccache', 'aarch64-marvell-linux-gnu-gcc'] cpp = ['ccache',
> > +'aarch64-marvell-linux-gnu-g++'] ar =
> > +'aarch64-marvell-linux-gnu-gcc-ar'
> > +strip = 'aarch64-marvell-linux-gnu-strip'
> > +pkgconfig = 'aarch64-linux-gnu-pkg-config'
> > +
> > +[host_machine]
> > +system = 'linux'
> > +cpu_family = 'aarch64'
> > +cpu = 'armv9-a'
> > +endian = 'little'
> > +
> > +[properties]
> > +platform = 'odyssey'
> > +
> > +[built-in options]
> 
> Just thinking out loud, given that this is a 80 core V2 machine, do we need 
> cross
> compilation support? I have the same question for Grace machine as well. I am
> thinking we should have cross compilation support only for embedded platforms.

[Anoob] DPDK binaries may not be built natively in all cases. When there are 
standard release packages with pre-built binaries, it would help in having 
cross compilation. 

> 
> 
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 3886d0e2dc..94159efaa4 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -500,6 +500,20 @@ soc_n2 = {
> > 'numa': false
> > }
> >
> > +soc_odyssey = {
> > +'description' : 'Marvell Odyssey',
> > +'implementer' : '0x41',
> > +'flags': [
> > +['RTE_MAX_LCORE', 80],
> > +['RTE_MAX_NUMA_NODES', 1],
> > +['RTE_MEMPOOL_ALIGN', 128],
> > +],
> > +'part_number': '0xd4f',
> > +'extra_march_features': ['crypto'],
> > +'numa': false,
> > +'sve_acle': false
> > +}
> > +
> Can you move it such that it is sorted alphabetically?

[Anoob] soc_cn9k portion is not following alphabetical order. I think it is so 
because of the renaming from soc_octeontx2 to soc_cn9k. I can push a separate 
patch to have this addressed. New addition in this patch is following 
alphabetical order. soc_odyssey is added between n2 & stingray.

> 
> > soc_cn9k = {
> > 'description': 'Marvell OCTEON 9',
> > 'implementer': '0x43',
> > @@ -617,6 +631,7 @@ socs = {
> > 'kunpeng930': soc_kunpeng930,
> > 'n1sdp': soc_n1sdp,
> > 'n2': soc_n2,
> > +'odyssey' : soc_odyssey,
> > 'stingray': soc_stingray,
> > 'thunderx2': soc_thunderx2,
> > 'thunderxt88': soc_thunderxt88,
> > --
> > 2.25.1
> >

Reminder - DPDK Tech Board Call - Tomorrow, Wed. Mar 6 , 2024 - 7am Pacific/10am Eastern/1500h UTC

[Nathan Southern]

Good evening Dpdk Community,

Tomorrow morning is the biweekly meeting - as always please put your agenda
items here in advance:

 https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db



And zoom information to follow. see you soon

Thanks,

Nathan

You have been invited to a recurring meeting for Data Plane Development Kit
(DPDK)

Minutes:
http://core.dpdk.org/techboard/minutes


Ways to join meeting:

1. Join from PC, Mac, iPad, or Android

https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?password=d808f1f6-0a28-4165-929e-5a5bcae7efeb


2. Join via audio

One tap mobile:
US: +12532158782,,96459488340# or +13462487799,,96459488340

Or dial:
US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715
8592 or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or
855 880 1246 (Toll Free)
Canada: +1 647 374 4685 or +1 647 558 0588 or +1 778 907 2071 or +1 204 272
7920 or +1 438 809 7799 or +1 587 328 1099 or 855 703 8985 (Toll Free)

Meeting ID: 96459488340

Meeting Passcode: 699526


International numbers: https://zoom.us/u/alwnPIaVT

RE: RFC: Using and renaming 8-bit reserved field of rte_crypto_op for implementation specific

[Kundapura, Ganapati]

Hi Akhil,
No changes in sequence of API's by adding 'uint8_t impl_opaque' to 'struct 
rte_crypto_op'.
It's required in case application/event dispatcher passes some implementation 
specific value in rte_event::impl_opaque, to restore the value
back on to rte_event::impl_opaque after enqueue to and dequeue from cryptodev.

Here is the pseudocode for one of the use case
Application/event dispatcher passes implementation specific value in 
rte_event::impl_opaque.
struct rte_event ev;
rte_event_dequeue_burst(..., &ev, ...)
struct rte_crypto_op *crypto_op = ev.event_ptr;   // ev.impl_opaque some 
implementation specific value
rte_cryptodev_enqueue_burst(..., crypto_op, ...) ; // ev.impl_opaque is not 
passed to crypto_op

With rte_crypto_op::impl_opaque field which is unchanged in library/driver
crypto_op->impl_opaque = ev.impl_opaque;
rte_cryptodev_enqueue_burst(..., crypto_op, ...) ;

...
rte_crypto_dequeue_burst(..., crypto_op, ...)
ev.event_ptr = crypto_op;
...
rte_event_enqueue_burst(..., &ev, ...);  // ev::impl_opaque value is lost

with rte_crypto_op::impl_opaque field
ev.event_ptr = crypto_op;
ev.impl_opaque = crypto_op->impl_opaque; // implementation specific value in 
rte_event::impl_opaque restored back
rte_event_enqueue_burst(..., &ev, ...);

Thanks,
Ganapati


From: Akhil Goyal 
Sent: Tuesday, March 5, 2024 10:18 PM
To: Kundapura, Ganapati ; dpdk-dev 
; fanzhang@gmail.com; Ji, Kai ; Power, 
Ciara ; Kusztal, ArkadiuszX 
; Gujjar, Abhinandan S 
; Jayatheerthan, Jay 
; Jerin Jacob 
Subject: RE: RFC: Using and renaming 8-bit reserved field of rte_crypto_op for 
implementation specific

Hi Ganapati,

Can you please explain the flow with a sequence of APIs to be used.

Regards,
Akhil

From: Kundapura, Ganapati 
mailto:ganapati.kundap...@intel.com>>
Sent: Tuesday, March 5, 2024 12:44 PM
To: dpdk-dev mailto:dev@dpdk.org>>; Akhil Goyal 
mailto:gak...@marvell.com>>; 
fanzhang@gmail.com; Ji, Kai 
mailto:kai...@intel.com>>; Power, Ciara 
mailto:ciara.po...@intel.com>>; Kusztal, ArkadiuszX 
mailto:arkadiuszx.kusz...@intel.com>>; Gujjar, 
Abhinandan S mailto:abhinandan.guj...@intel.com>>; 
Jayatheerthan, Jay 
mailto:jay.jayatheert...@intel.com>>; Jerin Jacob 
mailto:jerinjac...@gmail.com>>
Subject: [EXTERNAL] RFC: Using and renaming 8-bit reserved field of 
rte_crypto_op for implementation specific

Prioritize security for external emails: Confirm sender and content safety 
before clicking links or opening attachments

Hi dpdk-dev,
   Can 'uint8_t reserved[1]' of 'struct rte_crypto_op' be renamed
to 'uint8_t impl_opaque' for implementation specific?

An implementation may use this field to hold implementation specific
value to share value between dequeue and enqueue operation and crypto 
library/driver
can also use this field to share implementation specfic value to event crypto 
adapter/application.

'struct rte_event' has 'uint8_t impl_opaque' member
struct rte_event {
...
uint8_t impl_opaque;
/**< Implementation specific opaque value.
* An implementation may use this field to hold
* implementation specific value to share between
* dequeue and enqueue operation.
* The application should not modify this field.
*/
...
};

Event crypto adapter, on dequeuing the event, enqueues rte_event::event_ptr
to cryptodev as rte_crypto_op and converts the dequeued crypto op to rte_event
without restoring the implementation specific opaque value.

By having the 'uint8_t impl_opaque' member in 'struct rte_crypto_op' as
diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h
index dbc2700..af46ec9 100644
--- a/lib/cryptodev/rte_crypto.h
+++ b/lib/cryptodev/rte_crypto.h
@@ -146,10 +146,13 @@ struct rte_crypto_op {
/**< TLS record */
} param1;
/**< Additional per operation parameter 1. */
-   uint8_t reserved[1];
-   /**< Reserved bytes to fill 64 bits for
-* future additions
+   uint8_t impl_opaque;
+   /**< Implementation specific opaque value.
+* An implementation may use this field to hold
+* implementation specific value to share between
+* dequeue and enqueue operation.
 */
+

which is untouched in library/driver and rte_event::impl_opaque field can be 
restored
while enqueuing the event back to eventdev.

Also crypto library/driver can use rte_crypto_op::impl_opaque field to
share implementation specific opaque value to the event crypto 
adapter/application.

I look forward to feedback on this proposal. Patch will be submitted
for review once the initial feedback is received.

Thank you,
Ganapati

Re: [PATCH v2] config/arm: add Marvell Odyssey

[Honnappa Nagarahalli]

> On Mar 5, 2024, at 10:41 PM, Anoob Joseph  wrote:
> 
> Hi Honnappa,
> 
> Thanks for the review. Please see inline.
> 
> Thanks,
> Anoob
> 
>> -Original Message-
>> From: Honnappa Nagarahalli 
>> Sent: Wednesday, March 6, 2024 8:50 AM
>> To: Anoob Joseph 
>> Cc: Juraj Linkeš ; tho...@monjalon.net; David
>> Marchand ; Jerin Jacob ; nd
>> ; Pavan Nikhilesh Bhagavatula ;
>> Ruifeng Wang ; Wathsala Wathawana Vithanage
>> ; dev@dpdk.org
>> Subject: [EXTERNAL] Re: [PATCH v2] config/arm: add Marvell Odyssey
>> 
>> Prioritize security for external emails: Confirm sender and content safety 
>> before
>> clicking links or opening attachments
>> 
>> --
>> 
>> 
>>> On Mar 5, 2024, at 5:13 AM, Anoob Joseph  wrote:
>>> 
>>> Add meson build configuration for Marvell Odyssey platform with 64-bit
>>> ARM Neoverse V2 cores.
>>> 
>>> Signed-off-by: Anoob Joseph 
>>> ---
>>> 
>>> Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")
>>> 
>>> Changes in v2:
>>> - Renamed config file
>>> 
>>> config/arm/arm64_odyssey_linux_gcc | 17 +
>>> config/arm/meson.build | 15 +++
>>> 2 files changed, 32 insertions(+)
>>> create mode 100644 config/arm/arm64_odyssey_linux_gcc
>>> 
>>> diff --git a/config/arm/arm64_odyssey_linux_gcc
>>> b/config/arm/arm64_odyssey_linux_gcc
>>> new file mode 100644
>>> index 00..69b5cd42d8
>>> --- /dev/null
>>> +++ b/config/arm/arm64_odyssey_linux_gcc
>>> @@ -0,0 +1,17 @@
>>> +[binaries]
>>> +c = ['ccache', 'aarch64-marvell-linux-gnu-gcc'] cpp = ['ccache',
>>> +'aarch64-marvell-linux-gnu-g++'] ar =
>>> +'aarch64-marvell-linux-gnu-gcc-ar'
>>> +strip = 'aarch64-marvell-linux-gnu-strip'
>>> +pkgconfig = 'aarch64-linux-gnu-pkg-config'
>>> +
>>> +[host_machine]
>>> +system = 'linux'
>>> +cpu_family = 'aarch64'
>>> +cpu = 'armv9-a'
>>> +endian = 'little'
>>> +
>>> +[properties]
>>> +platform = 'odyssey'
>>> +
>>> +[built-in options]
>> 
>> Just thinking out loud, given that this is a 80 core V2 machine, do we need 
>> cross
>> compilation support? I have the same question for Grace machine as well. I am
>> thinking we should have cross compilation support only for embedded 
>> platforms.
> 
> [Anoob] DPDK binaries may not be built natively in all cases. When there are 
> standard release packages with pre-built binaries, it would help in having 
> cross compilation.
Ack

> 
>> 
>> 
>>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
>>> 3886d0e2dc..94159efaa4 100644
>>> --- a/config/arm/meson.build
>>> +++ b/config/arm/meson.build
>>> @@ -500,6 +500,20 @@ soc_n2 = {
>>>'numa': false
>>> }
>>> 
>>> +soc_odyssey = {
>>> +'description' : 'Marvell Odyssey',
>>> +'implementer' : '0x41',
>>> +'flags': [
>>> +['RTE_MAX_LCORE', 80],
>>> +['RTE_MAX_NUMA_NODES', 1],
>>> +['RTE_MEMPOOL_ALIGN', 128],
>>> +],
>>> +'part_number': '0xd4f',
>>> +'extra_march_features': ['crypto'],
>>> +'numa': false,
>>> +'sve_acle': false
>>> +}
>>> +
>> Can you move it such that it is sorted alphabetically?
> 
> [Anoob] soc_cn9k portion is not following alphabetical order. I think it is 
> so because of the renaming from soc_octeontx2 to soc_cn9k. I can push a 
> separate patch to have this addressed. New addition in this patch is 
> following alphabetical order. soc_odyssey is added between n2 & stingray.
Yes, please push a separate patch for cn9k.

> 
>> 
>>> soc_cn9k = {
>>>'description': 'Marvell OCTEON 9',
>>>'implementer': '0x43',
>>> @@ -617,6 +631,7 @@ socs = {
>>>'kunpeng930': soc_kunpeng930,
>>>'n1sdp': soc_n1sdp,
>>>'n2': soc_n2,
>>> +'odyssey' : soc_odyssey,
>>>'stingray': soc_stingray,
>>>'thunderx2': soc_thunderx2,
>>>'thunderxt88': soc_thunderxt88,
>>> --
>>> 2.25.1
>>> 
> 

Re: [PATCH v2] config/arm: add Marvell Odyssey

[Honnappa Nagarahalli]

> On Mar 5, 2024, at 5:13 AM, Anoob Joseph  wrote:
> 
> Add meson build configuration for Marvell Odyssey platform with 64-bit
> ARM Neoverse V2 cores.
> 
> Signed-off-by: Anoob Joseph 
Reviewed-by: Honnappa Nagarahalli 

> ---
> 
> Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")
> 
> Changes in v2:
> - Renamed config file
> 
> config/arm/arm64_odyssey_linux_gcc | 17 +
> config/arm/meson.build | 15 +++
> 2 files changed, 32 insertions(+)
> create mode 100644 config/arm/arm64_odyssey_linux_gcc
> 
> diff --git a/config/arm/arm64_odyssey_linux_gcc 
> b/config/arm/arm64_odyssey_linux_gcc
> new file mode 100644
> index 00..69b5cd42d8
> --- /dev/null
> +++ b/config/arm/arm64_odyssey_linux_gcc
> @@ -0,0 +1,17 @@
> +[binaries]
> +c = ['ccache', 'aarch64-marvell-linux-gnu-gcc']
> +cpp = ['ccache', 'aarch64-marvell-linux-gnu-g++']
> +ar = 'aarch64-marvell-linux-gnu-gcc-ar'
> +strip = 'aarch64-marvell-linux-gnu-strip'
> +pkgconfig = 'aarch64-linux-gnu-pkg-config'
> +
> +[host_machine]
> +system = 'linux'
> +cpu_family = 'aarch64'
> +cpu = 'armv9-a'
> +endian = 'little'
> +
> +[properties]
> +platform = 'odyssey'
> +
> +[built-in options]
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 3886d0e2dc..94159efaa4 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -500,6 +500,20 @@ soc_n2 = {
> 'numa': false
> }
> 
> +soc_odyssey = {
> +'description' : 'Marvell Odyssey',
> +'implementer' : '0x41',
> +'flags': [
> +['RTE_MAX_LCORE', 80],
> +['RTE_MAX_NUMA_NODES', 1],
> +['RTE_MEMPOOL_ALIGN', 128],
> +],
> +'part_number': '0xd4f',
> +'extra_march_features': ['crypto'],
> +'numa': false,
> +'sve_acle': false
> +}
> +
> soc_cn9k = {
> 'description': 'Marvell OCTEON 9',
> 'implementer': '0x43',
> @@ -617,6 +631,7 @@ socs = {
> 'kunpeng930': soc_kunpeng930,
> 'n1sdp': soc_n1sdp,
> 'n2': soc_n2,
> +'odyssey' : soc_odyssey,
> 'stingray': soc_stingray,
> 'thunderx2': soc_thunderx2,
> 'thunderxt88': soc_thunderxt88,
> -- 
> 2.25.1
> 

[PATCH v3] config/arm: add Marvell Odyssey

[Anoob Joseph]

Add meson build configuration for Marvell Odyssey platform with 64-bit
ARM Neoverse V2 cores.

Signed-off-by: Anoob Joseph 
Reviewed-by: Honnappa Nagarahalli 
Reviewed-by: Ruifeng Wang 
---

Depends-on: series-31141 ("config/arm: add Neoverse V2 part number")

Changes in v3:
- Added string for Odyssey
- Minor shuffling of fields to make it similar to other entries

Changes in v2:
- Renamed config file

 config/arm/arm64_odyssey_linux_gcc | 17 +
 config/arm/meson.build | 15 +++
 2 files changed, 32 insertions(+)
 create mode 100644 config/arm/arm64_odyssey_linux_gcc

diff --git a/config/arm/arm64_odyssey_linux_gcc 
b/config/arm/arm64_odyssey_linux_gcc
new file mode 100644
index 00..69b5cd42d8
--- /dev/null
+++ b/config/arm/arm64_odyssey_linux_gcc
@@ -0,0 +1,17 @@
+[binaries]
+c = ['ccache', 'aarch64-marvell-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-marvell-linux-gnu-g++']
+ar = 'aarch64-marvell-linux-gnu-gcc-ar'
+strip = 'aarch64-marvell-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv9-a'
+endian = 'little'
+
+[properties]
+platform = 'odyssey'
+
+[built-in options]
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3886d0e2dc..f6c9a41a88 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -500,6 +500,19 @@ soc_n2 = {
 'numa': false
 }
 
+soc_odyssey = {
+'description': 'Marvell Odyssey',
+'implementer': '0x41',
+'part_number': '0xd4f',
+'extra_march_features': ['crypto'],
+'numa': false,
+'flags': [
+['RTE_MAX_LCORE', 80],
+['RTE_MAX_NUMA_NODES', 1],
+['RTE_MEMPOOL_ALIGN', 128],
+],
+}
+
 soc_cn9k = {
 'description': 'Marvell OCTEON 9',
 'implementer': '0x43',
@@ -583,6 +596,7 @@ kunpeng920:  HiSilicon Kunpeng 920
 kunpeng930:  HiSilicon Kunpeng 930
 n1sdp:   Arm Neoverse N1SDP
 n2:  Arm Neoverse N2
+odyssey: Marvell Odyssey
 stingray:Broadcom Stingray
 thunderx2:   Marvell ThunderX2 T99
 thunderxt88: Marvell ThunderX T88
@@ -617,6 +631,7 @@ socs = {
 'kunpeng930': soc_kunpeng930,
 'n1sdp': soc_n1sdp,
 'n2': soc_n2,
+'odyssey' : soc_odyssey,
 'stingray': soc_stingray,
 'thunderx2': soc_thunderx2,
 'thunderxt88': soc_thunderxt88,
-- 
2.25.1

[PATCH] net/mlx5: fix mlx5dr context release ordering

[Maayan Kashani]

Creating rules on group >0, creates a jump action on the group table.
Non template code releases the group data under shared mlx5dr free code,
And the mlx5dr context was already closed in HWS code.

Remove mlx5dr context release from hws resource release function.

Fixes: b401400db24e ("net/mlx5: add port flow configuration")
Cc: sta...@dpdk.org
Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.c | 7 +++
 drivers/net/mlx5/mlx5_flow_hw.c | 2 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 39dc1830d1..8b54843a43 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -2355,6 +2355,7 @@ mlx5_dev_close(struct rte_eth_dev *dev)
mlx5_indirect_list_handles_release(dev);
 #ifdef HAVE_MLX5_HWS_SUPPORT
flow_hw_destroy_vport_action(dev);
+   /* dr context will be closed after mlx5_os_free_shared_dr. */
flow_hw_resource_release(dev);
flow_hw_clear_port_info(dev);
if (priv->tlv_options != NULL) {
@@ -2391,6 +2392,12 @@ mlx5_dev_close(struct rte_eth_dev *dev)
mlx5_hlist_destroy(priv->mreg_cp_tbl);
mlx5_mprq_free_mp(dev);
mlx5_os_free_shared_dr(priv);
+#ifdef HAVE_MLX5_HWS_SUPPORT
+   if (priv->dr_ctx) {
+   claim_zero(mlx5dr_context_close(priv->dr_ctx));
+   priv->dr_ctx = NULL;
+   }
+#endif
if (priv->rss_conf.rss_key != NULL)
mlx5_free(priv->rss_conf.rss_key);
if (priv->reta_idx != NULL)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 4216433c6e..f52093a59a 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -10707,13 +10707,11 @@ flow_hw_resource_release(struct rte_eth_dev *dev)
}
mlx5_free(priv->hw_q);
priv->hw_q = NULL;
-   claim_zero(mlx5dr_context_close(priv->dr_ctx));
if (priv->shared_host) {
struct mlx5_priv *host_priv = 
priv->shared_host->data->dev_private;
__atomic_fetch_sub(&host_priv->shared_refcnt, 1, 
__ATOMIC_RELAXED);
priv->shared_host = NULL;
}
-   priv->dr_ctx = NULL;
mlx5_free(priv->hw_attr);
priv->hw_attr = NULL;
priv->nb_queue = 0;
-- 
2.25.1

Re: [PATCH] doc: update size parameter details

[Varghese, Vipin]

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


For configuration parameters `mem_size` and `buf_size` are represented
as megabytes and bytes respectively in application. Update the
documentation to represent the same.

Signed-off-by: Vipin Varghese 
---
  doc/guides/tools/dmaperf.rst | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/tools/dmaperf.rst b/doc/guides/tools/dmaperf.rst
index 9e3e78a6b7..6f85fceb8a 100644
--- a/doc/guides/tools/dmaperf.rst
+++ b/doc/guides/tools/dmaperf.rst
@@ -74,10 +74,10 @@ Configuration Parameters
Currently supported types are ``DMA_MEM_COPY`` and ``CPU_MEM_COPY``.

  ``mem_size``
-  The size of the memory footprint.
+  The size of the memory footprint in megabytes (MB) for source and 
destination.

  ``buf_size``
-  The memory size of a single operation.
+  The memory size of a single operation in bytes (B).

  ``dma_ring_size``
The DMA ring buffer size. Must be a power of two, and between ``64`` and 
``4096``.

Hi Chengwen, can you please help us to review the changes ?

--
2.34.1

Re: [PATCH v4 2/7] ethdev: add telemetry cmd for registers

[Jie Hai]

Hi, Chengwen,
Thanks for your review, all will be modified in next version.

Best Regards,
Jie Hai
On 2024/2/26 17:09, fengchengwen wrote:

Hi Jie,

On 2024/2/26 11:07, Jie Hai wrote:

This patch adds a telemetry command for registers dump,
and supports get registers with specified names.
The length of the string exported by telemetry is limited
by MAX_OUTPUT_LEN. Therefore, the filter should be more
precise.

An example usage is shown below:
--> /ethdev/regs,0,INTR
{
   "/ethdev/regs": {
 "registers_length": 318,
 "registers_width": 4,
 "register_offset": "0x0",
 "version": "0x1140011",
 "group_0": {
   "HNS3_CMDQ_INTR_STS_REG": "0x0",
   "HNS3_CMDQ_INTR_EN_REG": "0x2",
   "HNS3_CMDQ_INTR_GEN_REG": "0x0",
   "queue_0_HNS3_TQP_INTR_CTRL_REG": "0x0",
   "queue_0_HNS3_TQP_INTR_GL0_REG": "0xa",
   "queue_0_HNS3_TQP_INTR_GL1_REG": "0xa",
   "queue_0_HNS3_TQP_INTR_GL2_REG": "0x0",
   ...
   },
 "group_1": {
 ...
 },
 ...
}

or as below if the number of registers not exceed the
RTE_TEL_MAX_DICT_ENTRIES:
--> /ethdev/regs,0,ppp
{
   "/ethdev/regs": {
 "registers_length": 156,
 "registers_width": 4,
 "register_offset": "0x0",
 "version": "0x1140011",
 "ppp_key_drop_num": "0x0",
 "ppp_rlt_drop_num": "0x0",
 "ssu_ppp_mac_key_num_l": "0x1",
 "ssu_ppp_mac_key_num_h": "0x0",
 "ssu_ppp_host_key_num_l": "0x1",
 "ssu_ppp_host_key_num_h": "0x0",
 "ppp_ssu_mac_rlt_num_l": "0x1",
 ...
}
}

Signed-off-by: Jie Hai 
---
  lib/ethdev/rte_ethdev_telemetry.c | 126 ++
  1 file changed, 126 insertions(+)

diff --git a/lib/ethdev/rte_ethdev_telemetry.c 
b/lib/ethdev/rte_ethdev_telemetry.c
index 6b873e7abe68..f1ebb2fae632 100644
--- a/lib/ethdev/rte_ethdev_telemetry.c
+++ b/lib/ethdev/rte_ethdev_telemetry.c
@@ -5,6 +5,7 @@
  #include 
  #include 
  
+#include 

  #include 
  #include 
  
@@ -1395,6 +1396,129 @@ eth_dev_handle_port_tm_node_caps(const char *cmd __rte_unused,

return ret;
  }
  
+static int

+eth_dev_store_regs(struct rte_tel_data *d, struct rte_dev_reg_info *reg_info)
+{
+   struct rte_tel_data *groups[RTE_TEL_MAX_DICT_ENTRIES] = {NULL};


no need zero.


+   char group_name[RTE_TEL_MAX_STRING_LEN] = {0};
+   struct rte_tel_data *group = NULL;
+   uint32_t grp_num = 0;
+   uint32_t *data;
+   int ret = 0;
+   uint32_t i;
+
+   rte_tel_data_start_dict(d);
+   rte_tel_data_add_dict_uint(d, "register_length", reg_info->length);
+   rte_tel_data_add_dict_uint(d, "register_width", reg_info->width);
+   rte_tel_data_add_dict_uint_hex(d, "register_offset", reg_info->offset, 
0);
+   rte_tel_data_add_dict_uint_hex(d, "version", reg_info->version, 0);
+
+   data = reg_info->data;
+   if (reg_info->length <= RTE_TEL_MAX_DICT_ENTRIES) {
+   for (i = 0; i < reg_info->length; i++, data++)
+   rte_tel_data_add_dict_uint_hex(d,
+   reg_info->names[i].name, *data, 0);


The above format is OK for reg_info->width==4.
There maybe reg_info->width == 8, pls support it.


+   return 0;
+   }
+
+   for (i = 0; i < reg_info->length; i++, data++) {
+   if (i % RTE_TEL_MAX_DICT_ENTRIES == 0) {
+   if (i != 0)
+   rte_tel_data_add_dict_container(d, group_name,
+   group, 0);
+
+   group = rte_tel_data_alloc();
+   if (group == NULL) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   rte_tel_data_start_dict(group);
+   snprintf(group_name, RTE_TEL_MAX_STRING_LEN,
+   "group_%u", grp_num);


grp_num + 1 ?


+   if (grp_num >= RTE_TEL_MAX_DICT_ENTRIES) {
+   RTE_ETHDEV_LOG_LINE(NOTICE,
+   "Too many regs, please filter");


how about add more descrip: stop format!


+   return 0;


this group's memory was leak.

How about move the extream case before for loop:

uint32_t length = reg_info->lenght;
if (length > RTE_TEL_MAX_DICT_ENTRIES * RTE_TEL_MAX_DICT_ENTRIES) {
 LOG(xxx);
 length = RTE_TEL_MAX_DICT_ENTRIES * RTE_TEL_MAX_DICT_ENTRIES;
}


+   }
+   groups[grp_num++] = group;
+   }
+   rte_tel_data_add_dict_uint_hex(group, reg_info->names[i].name,
+   *data, 0);
+   }
+   if (i % RTE_TEL_MAX_DICT_ENTRIES != 0)
+   rte_tel_data_add_dict_container(d, group_name, group, 0);


how about move all add dict in here.
for (i = 0; i < grp_num; i++) {
 snprintf(group_name, xxx);
 rte_tel_data_add_dict_containe

Re: [PATCH v4 1/7] ethdev: support report register names and filter

[Jie Hai]

Hi, fengchengwen,
On 2024/2/26 16:01, fengchengwen wrote:

Hi Jie,

On 2024/2/26 11:07, Jie Hai wrote:

This patch adds "filter" and "names" fields to "rte_dev_reg_info"
structure. Names of registers in data fields can be reported and
the registers can be filtered by their names.

The new API rte_eth_dev_get_reg_info_ext() is added to support
reporting names and filtering by names. And the original API
rte_eth_dev_get_reg_info() does not use the name and filter fields.
A local variable is used in rte_eth_dev_get_reg_info for
compatibility. If the drivers does not report the names, set them
to "offset_XXX".

Signed-off-by: Jie Hai 
---
  doc/guides/rel_notes/release_24_03.rst |  8 ++
  lib/ethdev/rte_dev_info.h  | 11 +
  lib/ethdev/rte_ethdev.c| 34 ++
  lib/ethdev/rte_ethdev.h| 28 +
  lib/ethdev/version.map |  1 +
  5 files changed, 82 insertions(+)

diff --git a/doc/guides/rel_notes/release_24_03.rst 
b/doc/guides/rel_notes/release_24_03.rst
index 32d0ad8cf6a7..fa46da427dca 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -132,6 +132,11 @@ New Features
  to support TLS v1.2, TLS v1.3 and DTLS v1.2.
* Added PMD API to allow raw submission of instructions to CPT.
  
+  * **Added support for dumping registers with names and filter.**

+
+* Added new API functions ``rte_eth_dev_get_reg_info_ext()`` to and filter
+  the registers by their names and get the information of registers(names,
+  values and other attributes).
  
  Removed Items

  -
@@ -197,6 +202,9 @@ ABI Changes
  
  * No ABI change that would break compatibility with 23.11.
  
+* ethdev: Added ``filter`` and ``names`` fields to ``rte_dev_reg_info``

+  structure for reporting names of registers and filtering them by names.
+
  
  Known Issues

  
diff --git a/lib/ethdev/rte_dev_info.h b/lib/ethdev/rte_dev_info.h
index 67cf0ae52668..0ad4a43b9526 100644
--- a/lib/ethdev/rte_dev_info.h
+++ b/lib/ethdev/rte_dev_info.h
@@ -11,6 +11,11 @@ extern "C" {
  
  #include 
  
+#define RTE_ETH_REG_NAME_SIZE 128


Almost all stats name size is 64, why not keep consistent?


will correct.

+struct rte_eth_reg_name {
+   char name[RTE_ETH_REG_NAME_SIZE];
+};
+
  /*
   * Placeholder for accessing device registers
   */
@@ -20,6 +25,12 @@ struct rte_dev_reg_info {
uint32_t length; /**< Number of registers to fetch */
uint32_t width; /**< Size of device register */
uint32_t version; /**< Device version */
+   /**
+* Filter for target subset of registers.
+* This field could affects register selection for data/length/names.
+*/
+   const char *filter;
+   struct rte_eth_reg_name *names; /**< Registers name saver */
  };
  
  /*

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index f1c658f49e80..9ef50c633ce3 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6388,8 +6388,37 @@ rte_eth_read_clock(uint16_t port_id, uint64_t *clock)
  
  int

  rte_eth_dev_get_reg_info(uint16_t port_id, struct rte_dev_reg_info *info)
+{
+   struct rte_dev_reg_info reg_info = { 0 };
+   int ret;
+
+   if (info == NULL) {
+   RTE_ETHDEV_LOG_LINE(ERR,
+   "Cannot get ethdev port %u register info to NULL",
+   port_id);
+   return -EINVAL;
+   }
+
+   reg_info.length = info->length;
+   reg_info.data = info->data;
+
+   ret = rte_eth_dev_get_reg_info_ext(port_id, ®_info);
+   if (ret != 0)
+   return ret;
+
+   info->length = reg_info.length;
+   info->width = reg_info.width;
+   info->version = reg_info.version;
+   info->offset = reg_info.offset;
+
+   return 0;
+}
+
+int
+rte_eth_dev_get_reg_info_ext(uint16_t port_id, struct rte_dev_reg_info *info)
  {
struct rte_eth_dev *dev;
+   uint32_t i;
int ret;
  
  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);

@@ -6408,6 +6437,11 @@ rte_eth_dev_get_reg_info(uint16_t port_id, struct 
rte_dev_reg_info *info)
  
  	rte_ethdev_trace_get_reg_info(port_id, info, ret);
  
+	/* Report the default names if drivers not report. */

+   if (info->names != NULL && strlen(info->names[0].name) == 0)
+   for (i = 0; i < info->length; i++)
+   snprintf(info->names[i].name, RTE_ETH_REG_NAME_SIZE,
+   "offset_%x", info->offset + i * info->width);


%x has no prefix "0x", may lead to confused.
How about use %u ?


That sounds better.

Another question, if app don't zero names' memory, then its value is random, so 
it will not enter this logic.
Suggest memset item[0]'s name memory before invoke PMD ops.


return ret;
  }
  
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h

index ed27360447a3..09e2d5fdb49b 100644
--- a/lib/ethd

Symmetric RSS Hashing support in DPDK

[Balakrishnan K]

Hello,
   Our application needs symmetric hashing to handle the reverse traffic on the 
same core, also to
Improve performance by distributing the traffic across core.
Tried using rss config as below .
action_rss_tcp.types = ETH_RSS_NONFRAG_IPV4_TCP | ETH_RSS_L3_SRC_ONLY| 
ETH_RSS_L3_DST_ONLY | ETH_RSS_L4_SRC_ONLY | ETH_RSS_L4_DST_ONLY;
but could not get desired result.
Is there any options or API available to enable symmetric RSS hashing .
We are using dpdk 20.11 and intel NIC X710 10GbE .

Regards,
Bala

[PATCH] net/mlx5: fix pattern template size validation

[Gregory Etelson]

PMD running in HWS FDB mode can be configured to steer group 0 to FW.
In that case PMD activates legacy DV pattern processing.
There are control flows that require HWS pattern processing
in group 0.

Pattern template validation tried to create a matcher both in group 0
and HWS group.
As the result, during group 0 validation HWS tuned pattern was
processed as DV.

The patch removed pattern validation for group 0.

Fixes: f3aadd103358 ("net/mlx5: improve pattern template validation")
Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 49 +++--
 1 file changed, 29 insertions(+), 20 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 4216433c6e..b37348c972 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -7668,48 +7668,57 @@ flow_hw_pattern_has_sq_match(const struct rte_flow_item 
*items)
return false;
 }
 
+/*
+ * Verify that the tested flow patterns fits STE size limit in HWS group.
+ *
+ *
+ * Return values:
+ * 0   : Tested patterns fit STE size limit
+ * -EINVAL : Invalid parameters detected
+ * -E2BIG  : Tested patterns exceed STE size limit
+ */
 static int
 pattern_template_validate(struct rte_eth_dev *dev,
  struct rte_flow_pattern_template *pt[], uint32_t 
pt_num)
 {
-   uint32_t group = 0;
+   struct rte_flow_error error;
struct mlx5_flow_template_table_cfg tbl_cfg = {
-   .attr = (struct rte_flow_template_table_attr) {
+   .attr = {
.nb_flows = 64,
.insertion_type = RTE_FLOW_TABLE_INSERTION_TYPE_PATTERN,
.hash_func = RTE_FLOW_TABLE_HASH_FUNC_DEFAULT,
.flow_attr = {
+   .group = 1,
.ingress = pt[0]->attr.ingress,
.egress = pt[0]->attr.egress,
.transfer = pt[0]->attr.transfer
}
-   },
-   .external = true
+   }
};
struct mlx5_priv *priv = dev->data->dev_private;
struct rte_flow_actions_template *action_template;
+   struct rte_flow_template_table *tmpl_tbl;
+   int ret;
 
-   if (pt[0]->attr.ingress) {
+   if (pt[0]->attr.ingress)
action_template = 
priv->action_template_drop[MLX5DR_TABLE_TYPE_NIC_RX];
-   } else if (pt[0]->attr.egress) {
+   else if (pt[0]->attr.egress)
action_template = 
priv->action_template_drop[MLX5DR_TABLE_TYPE_NIC_TX];
-   } else if (pt[0]->attr.transfer) {
+   else if (pt[0]->attr.transfer)
action_template = 
priv->action_template_drop[MLX5DR_TABLE_TYPE_FDB];
+   else
+   return -EINVAL;
+   if (pt[0]->item_flags & MLX5_FLOW_ITEM_COMPARE)
+   tbl_cfg.attr.nb_flows = 1;
+   tmpl_tbl = flow_hw_table_create(dev, &tbl_cfg, pt, pt_num,
+   &action_template, 1, NULL);
+   if (tmpl_tbl) {
+   ret = 0;
+   flow_hw_table_destroy(dev, tmpl_tbl, &error);
} else {
-   rte_errno = EINVAL;
-   return rte_errno;
+   ret = rte_errno == E2BIG ? -E2BIG : 0;
}
-   do {
-   struct rte_flow_template_table *tmpl_tbl;
-
-   tbl_cfg.attr.flow_attr.group = group;
-   tmpl_tbl = flow_hw_table_create(dev, &tbl_cfg, pt, pt_num,
-   &action_template, 1, NULL);
-   if (!tmpl_tbl)
-   return rte_errno;
-   flow_hw_table_destroy(dev, tmpl_tbl, NULL);
-   } while (++group <= 1);
-   return 0;
+   return ret;
 }
 
 /**
-- 
2.39.2