* [PATCH v6 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: liujie5 @ 2026-06-02 15:52 UTC (permalink / raw)
To: stephen; +Cc: dev, Jie Liu
In-Reply-To: <20260602055414.630859-21-liujie5@linkdatatechnology.com>
From: Jie Liu <liujie5@linkdatatechnology.com>
This patch set implements core functionality for the SXE2 PMD,
including basic driver framework, data path setup, and advanced
offload features (VLAN, RSS,TM, PTP etc.).
V6:
- Addressed AI comments
Jie Liu (20):
net/sxe2: support AVX512 vectorized path for Rx and Tx
net/sxe2: add AVX2 vector data path for Rx and Tx
drivers: add supported packet types get callback
net/sxe2: support L2 filtering and MAC config
drivers: support RSS feature
net/sxe2: support TM hierarchy and shaping
net/sxe2: support IPsec inline protocol offload
net/sxe2: support statistics and multi-process
drivers: interrupt handling
net/sxe2: add NEON vec Rx/Tx burst functions
drivers: add support for VF representors
net/sxe2: add support for custom UDP tunnel ports
net/sxe2: support firmware version reading
net/sxe2: implement get monitor address
common/sxe2: add shared SFP module definitions
net/sxe2: support SFP module info and EEPROM access
net/sxe2: implement private dump info
net/sxe2: add mbuf validation in Tx debug mode
drivers: add testpmd commands for private features
net/sxe2: update sxe2 feature matrix docs
doc/guides/nics/features/sxe2.ini | 69 +
drivers/common/sxe2/sxe2_common.c | 156 ++
drivers/common/sxe2/sxe2_common.h | 4 +
drivers/common/sxe2/sxe2_flow_public.h | 633 +++++++
drivers/common/sxe2/sxe2_ioctl_chnl.c | 178 +-
drivers/common/sxe2/sxe2_ioctl_chnl_func.h | 18 +
drivers/common/sxe2/sxe2_msg.h | 118 ++
drivers/common/sxe2/sxe2_ptype.h | 1793 ++++++++++++++++++
drivers/net/sxe2/meson.build | 56 +-
drivers/net/sxe2/sxe2_cmd_chnl.c | 1587 +++++++++++++++-
drivers/net/sxe2/sxe2_cmd_chnl.h | 139 ++
drivers/net/sxe2/sxe2_drv_cmd.h | 521 +++++-
drivers/net/sxe2/sxe2_dump.c | 304 +++
drivers/net/sxe2/sxe2_dump.h | 12 +
drivers/net/sxe2/sxe2_ethdev.c | 1531 +++++++++++++++-
drivers/net/sxe2/sxe2_ethdev.h | 112 +-
drivers/net/sxe2/sxe2_ethdev_repr.c | 610 ++++++
drivers/net/sxe2/sxe2_ethdev_repr.h | 32 +
drivers/net/sxe2/sxe2_filter.c | 895 +++++++++
drivers/net/sxe2/sxe2_filter.h | 100 +
drivers/net/sxe2/sxe2_flow.c | 1391 ++++++++++++++
drivers/net/sxe2/sxe2_flow.h | 30 +
drivers/net/sxe2/sxe2_flow_define.h | 144 ++
drivers/net/sxe2/sxe2_flow_parse_action.c | 1182 ++++++++++++
drivers/net/sxe2/sxe2_flow_parse_action.h | 23 +
drivers/net/sxe2/sxe2_flow_parse_engine.c | 106 ++
drivers/net/sxe2/sxe2_flow_parse_engine.h | 13 +
drivers/net/sxe2/sxe2_flow_parse_pattern.c | 1935 ++++++++++++++++++++
drivers/net/sxe2/sxe2_flow_parse_pattern.h | 46 +
drivers/net/sxe2/sxe2_ipsec.c | 1565 ++++++++++++++++
drivers/net/sxe2/sxe2_ipsec.h | 254 +++
drivers/net/sxe2/sxe2_irq.c | 1025 +++++++++++
drivers/net/sxe2/sxe2_irq.h | 25 +
drivers/net/sxe2/sxe2_mac.c | 535 ++++++
drivers/net/sxe2/sxe2_mac.h | 84 +
drivers/net/sxe2/sxe2_mp.c | 414 +++++
drivers/net/sxe2/sxe2_mp.h | 67 +
drivers/net/sxe2/sxe2_queue.c | 17 +-
drivers/net/sxe2/sxe2_rss.c | 584 ++++++
drivers/net/sxe2/sxe2_rss.h | 81 +
drivers/net/sxe2/sxe2_rx.c | 38 +
drivers/net/sxe2/sxe2_rx.h | 2 +
drivers/net/sxe2/sxe2_security.c | 335 ++++
drivers/net/sxe2/sxe2_security.h | 77 +
drivers/net/sxe2/sxe2_stats.c | 591 ++++++
drivers/net/sxe2/sxe2_stats.h | 39 +
drivers/net/sxe2/sxe2_switchdev.c | 332 ++++
drivers/net/sxe2/sxe2_switchdev.h | 33 +
drivers/net/sxe2/sxe2_testpmd.c | 733 ++++++++
drivers/net/sxe2/sxe2_testpmd_lib.c | 969 ++++++++++
drivers/net/sxe2/sxe2_testpmd_lib.h | 142 ++
drivers/net/sxe2/sxe2_tm.c | 1169 ++++++++++++
drivers/net/sxe2/sxe2_tm.h | 78 +
drivers/net/sxe2/sxe2_tx.c | 7 +
drivers/net/sxe2/sxe2_txrx.c | 176 +-
drivers/net/sxe2/sxe2_txrx.h | 4 +
drivers/net/sxe2/sxe2_txrx_check_mbuf.c | 595 ++++++
drivers/net/sxe2/sxe2_txrx_check_mbuf.h | 38 +
drivers/net/sxe2/sxe2_txrx_poll.c | 243 ++-
drivers/net/sxe2/sxe2_txrx_vec.c | 46 +-
drivers/net/sxe2/sxe2_txrx_vec.h | 38 +-
drivers/net/sxe2/sxe2_txrx_vec_avx2.c | 776 ++++++++
drivers/net/sxe2/sxe2_txrx_vec_avx512.c | 897 +++++++++
drivers/net/sxe2/sxe2_txrx_vec_common.h | 1 +
drivers/net/sxe2/sxe2_txrx_vec_neon.c | 721 ++++++++
drivers/net/sxe2/sxe2_vsi.c | 146 ++
drivers/net/sxe2/sxe2_vsi.h | 12 +-
drivers/net/sxe2/sxe2vf_regs.h | 85 +
68 files changed, 26588 insertions(+), 124 deletions(-)
create mode 100644 drivers/common/sxe2/sxe2_flow_public.h
create mode 100644 drivers/common/sxe2/sxe2_msg.h
create mode 100644 drivers/common/sxe2/sxe2_ptype.h
create mode 100644 drivers/net/sxe2/sxe2_dump.c
create mode 100644 drivers/net/sxe2/sxe2_dump.h
create mode 100644 drivers/net/sxe2/sxe2_ethdev_repr.c
create mode 100644 drivers/net/sxe2/sxe2_ethdev_repr.h
create mode 100644 drivers/net/sxe2/sxe2_filter.c
create mode 100644 drivers/net/sxe2/sxe2_filter.h
create mode 100644 drivers/net/sxe2/sxe2_flow.c
create mode 100644 drivers/net/sxe2/sxe2_flow.h
create mode 100644 drivers/net/sxe2/sxe2_flow_define.h
create mode 100644 drivers/net/sxe2/sxe2_flow_parse_action.c
create mode 100644 drivers/net/sxe2/sxe2_flow_parse_action.h
create mode 100644 drivers/net/sxe2/sxe2_flow_parse_engine.c
create mode 100644 drivers/net/sxe2/sxe2_flow_parse_engine.h
create mode 100644 drivers/net/sxe2/sxe2_flow_parse_pattern.c
create mode 100644 drivers/net/sxe2/sxe2_flow_parse_pattern.h
create mode 100644 drivers/net/sxe2/sxe2_ipsec.c
create mode 100644 drivers/net/sxe2/sxe2_ipsec.h
create mode 100644 drivers/net/sxe2/sxe2_irq.c
create mode 100644 drivers/net/sxe2/sxe2_mac.c
create mode 100644 drivers/net/sxe2/sxe2_mac.h
create mode 100644 drivers/net/sxe2/sxe2_mp.c
create mode 100644 drivers/net/sxe2/sxe2_mp.h
create mode 100644 drivers/net/sxe2/sxe2_rss.c
create mode 100644 drivers/net/sxe2/sxe2_rss.h
create mode 100644 drivers/net/sxe2/sxe2_security.c
create mode 100644 drivers/net/sxe2/sxe2_security.h
create mode 100644 drivers/net/sxe2/sxe2_stats.c
create mode 100644 drivers/net/sxe2/sxe2_stats.h
create mode 100644 drivers/net/sxe2/sxe2_switchdev.c
create mode 100644 drivers/net/sxe2/sxe2_switchdev.h
create mode 100644 drivers/net/sxe2/sxe2_testpmd.c
create mode 100644 drivers/net/sxe2/sxe2_testpmd_lib.c
create mode 100644 drivers/net/sxe2/sxe2_testpmd_lib.h
create mode 100644 drivers/net/sxe2/sxe2_tm.c
create mode 100644 drivers/net/sxe2/sxe2_tm.h
create mode 100644 drivers/net/sxe2/sxe2_txrx_check_mbuf.c
create mode 100644 drivers/net/sxe2/sxe2_txrx_check_mbuf.h
create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_avx2.c
create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_avx512.c
create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_neon.c
create mode 100644 drivers/net/sxe2/sxe2vf_regs.h
--
2.52.0
^ permalink raw reply
* [PATCH v4 2/2] net/intel: optimize for fast-free hint
From: Bruce Richardson @ 2026-06-02 15:45 UTC (permalink / raw)
To: dev; +Cc: mb, ciara.loftus, Bruce Richardson
In-Reply-To: <20260602154513.1079865-1-bruce.richardson@intel.com>
When the fast-free hint is provided to the driver we know that the mbufs
have refcnt of 1 and are from the same mempool. Therefore, we can
optimize a bit for this case by:
* resetting the necessary mbuf fields, ie. nb_seg and next pointer when
we are accessing the mbuf on writing the descriptor.
* on cleanup of buffers after transmit, we can just write those buffers
straight to the mempool without accessing them.
* when doing buffer cleanup, we can follow the model of the vector
driver where we cleanup in fixed bursts which don't wrap, and where we
track the mbufs between tx_tail and last_cleaned as invalid, so we
don't need to set them to NULL. [We only set to NULL valid mbuf slots
where we have a context descriptor or segment not backed by an mbuf]
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Ciara Loftus <ciara.loftus@intel.com>
---
drivers/net/intel/common/tx.h | 21 ++++--
drivers/net/intel/common/tx_scalar.h | 95 +++++++++++++++++++++-------
2 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/drivers/net/intel/common/tx.h b/drivers/net/intel/common/tx.h
index 23a8c39cf2..5fe71aed12 100644
--- a/drivers/net/intel/common/tx.h
+++ b/drivers/net/intel/common/tx.h
@@ -329,13 +329,22 @@ ci_txq_release_all_mbufs(struct ci_tx_queue *txq, bool use_ctx)
return;
if (!txq->use_vec_entry) {
- /* Regular scalar path uses sw_ring with ci_tx_entry */
- for (uint16_t i = 0; i < txq->nb_tx_desc; i++) {
- if (txq->sw_ring[i].mbuf != NULL) {
- rte_pktmbuf_free_seg(txq->sw_ring[i].mbuf);
- txq->sw_ring[i].mbuf = NULL;
- }
+ /* Free mbufs from (last_desc_cleaned + 1) to (tx_tail - 1). */
+ const uint16_t start = (txq->last_desc_cleaned + 1) % txq->nb_tx_desc;
+ const uint16_t nb_desc = txq->nb_tx_desc;
+ const uint16_t end = txq->tx_tail;
+
+ uint16_t i = start;
+ if (end < i) {
+ for (; i < nb_desc; i++)
+ if (txq->sw_ring[i].mbuf != NULL)
+ rte_pktmbuf_free_seg(txq->sw_ring[i].mbuf);
+ i = 0;
}
+ for (; i < end; i++)
+ if (txq->sw_ring[i].mbuf != NULL)
+ rte_pktmbuf_free_seg(txq->sw_ring[i].mbuf);
+ memset(txq->sw_ring, 0, sizeof(txq->sw_ring[0]) * nb_desc);
return;
}
diff --git a/drivers/net/intel/common/tx_scalar.h b/drivers/net/intel/common/tx_scalar.h
index 7809bd53e8..11ab6c08fc 100644
--- a/drivers/net/intel/common/tx_scalar.h
+++ b/drivers/net/intel/common/tx_scalar.h
@@ -197,16 +197,66 @@ ci_tx_xmit_cleanup(struct ci_tx_queue *txq)
const uint16_t rs_idx = (last_desc_cleaned == nb_tx_desc - 1) ?
0 :
(last_desc_cleaned + 1) >> txq->log2_rs_thresh;
- uint16_t desc_to_clean_to = (rs_idx << txq->log2_rs_thresh) + (txq->tx_rs_thresh - 1);
+ const uint16_t dd_idx = txq->rs_last_id[rs_idx];
+ const uint16_t first_to_clean = rs_idx << txq->log2_rs_thresh;
- /* Check if descriptor is done */
- if ((txd[txq->rs_last_id[rs_idx]].cmd_type_offset_bsz &
- rte_cpu_to_le_64(CI_TXD_QW1_DTYPE_M)) !=
- rte_cpu_to_le_64(CI_TX_DESC_DTYPE_DESC_DONE))
+ /* Check if descriptor is done - all drivers use 0xF as done value in bits 3:0 */
+ if ((txd[dd_idx].cmd_type_offset_bsz & rte_cpu_to_le_64(CI_TXD_QW1_DTYPE_M)) !=
+ rte_cpu_to_le_64(CI_TX_DESC_DTYPE_DESC_DONE))
+ /* Descriptor not yet processed by hardware */
return -1;
+ /* DD bit is set, descriptors are done. Now free the mbufs. */
+ /* Note: nb_tx_desc is guaranteed to be a multiple of tx_rs_thresh,
+ * validated during queue setup. This means cleanup never wraps around
+ * the ring within a single burst (e.g., ring=256, rs_thresh=32 gives
+ * bursts of 0-31, 32-63, ..., 224-255).
+ */
+ const uint16_t nb_to_clean = txq->tx_rs_thresh;
+ struct ci_tx_entry *sw_ring = txq->sw_ring;
+
+ /* fast_free_mp is NULL only when the fast free is disabled*/
+ if (txq->fast_free_mp != NULL) {
+ /* FAST_FREE path: mbufs are already reset, just return to pool */
+ struct rte_mbuf *free[CI_TX_MAX_FREE_BUF_SZ];
+ uint16_t nb_free = 0;
+
+ /* Get cached mempool pointer, or cache it on first use.
+ * Read from mbuf at dd_idx, as it is guaranteed to be non-NULL.
+ */
+ struct rte_mempool *mp =
+ likely(txq->fast_free_mp != (void *)UINTPTR_MAX) ?
+ txq->fast_free_mp :
+ (txq->fast_free_mp = sw_ring[dd_idx].mbuf->pool);
+
+ /* Pack non-NULL mbufs in-place at start of sw_ring range.
+ * No modulo needed in loop since we're guaranteed not to wrap.
+ */
+ for (uint16_t i = 0; i < nb_to_clean; i++) {
+ struct rte_mbuf *m = sw_ring[first_to_clean + i].mbuf;
+ if (m == NULL)
+ continue;
+ free[nb_free++] = m;
+ if (unlikely(nb_free == CI_TX_MAX_FREE_BUF_SZ)) {
+ rte_mbuf_raw_free_bulk(mp, free, nb_free);
+ nb_free = 0;
+ }
+ }
+
+ /* Bulk return to mempool using packed sw_ring entries directly */
+ if (nb_free > 0)
+ rte_mbuf_raw_free_bulk(mp, free, nb_free);
+ } else {
+ /* Non-FAST_FREE path: use free_seg for refcount checks and freeing */
+ for (uint16_t i = 0; i < nb_to_clean; i++) {
+ struct rte_mbuf *m = sw_ring[first_to_clean + i].mbuf;
+ if (m != NULL)
+ rte_pktmbuf_free_seg(m);
+ }
+ }
+
/* Update the txq to reflect the last descriptor that was cleaned */
- txq->last_desc_cleaned = desc_to_clean_to;
+ txq->last_desc_cleaned = first_to_clean + txq->tx_rs_thresh - 1;
txq->nb_tx_free += txq->tx_rs_thresh;
return 0;
@@ -450,8 +500,6 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
txd = &ci_tx_ring[tx_id];
tx_id = txe->next_id;
- if (txe->mbuf)
- rte_pktmbuf_free_seg(txe->mbuf);
txe->mbuf = tx_pkt;
/* Setup TX Descriptor */
td_cmd |= CI_TX_DESC_CMD_EOP;
@@ -471,11 +519,7 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
uint64_t *ctx_txd = RTE_CAST_PTR(uint64_t *, &ci_tx_ring[tx_id]);
txn = &sw_ring[txe->next_id];
- RTE_MBUF_PREFETCH_TO_FREE(txn->mbuf);
- if (txe->mbuf) {
- rte_pktmbuf_free_seg(txe->mbuf);
- txe->mbuf = NULL;
- }
+ txe->mbuf = NULL;
write_txd(ctx_txd, cd_qw0, cd_qw1);
@@ -488,11 +532,7 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
uint64_t *ipsec_txd = RTE_CAST_PTR(uint64_t *, &ci_tx_ring[tx_id]);
txn = &sw_ring[txe->next_id];
- RTE_MBUF_PREFETCH_TO_FREE(txn->mbuf);
- if (txe->mbuf) {
- rte_pktmbuf_free_seg(txe->mbuf);
- txe->mbuf = NULL;
- }
+ txe->mbuf = NULL;
ipsec_txd[0] = ipsec_qw0;
ipsec_txd[1] = ipsec_qw1;
@@ -507,8 +547,19 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
txd = &ci_tx_ring[tx_id];
txn = &sw_ring[txe->next_id];
- if (txe->mbuf)
- rte_pktmbuf_free_seg(txe->mbuf);
+ /* For FAST_FREE: reset mbuf fields while we have it in cache.
+ * [Fast free is indicated by txq->fast_free_mp being non-NULL.]
+ * FAST_FREE guarantees refcnt=1 and direct mbufs, so we only
+ * need to reset nb_segs and next pointer as per rte_pktmbuf_prefree_seg.
+ * Save next pointer before resetting since we need it for loop iteration.
+ */
+ struct rte_mbuf *next_seg = m_seg->next;
+ if (txq->fast_free_mp != NULL) {
+ if (m_seg->nb_segs != 1)
+ m_seg->nb_segs = 1;
+ if (next_seg != NULL)
+ m_seg->next = NULL;
+ }
/* Setup TX Descriptor */
/* Calculate segment length, using IPsec callback if provided */
@@ -539,7 +590,7 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
}
/* fill the last descriptor with End of Packet (EOP) bit */
- if (m_seg->next == NULL)
+ if (next_seg == NULL)
td_cmd |= CI_TX_DESC_CMD_EOP;
const uint64_t cmd_type_offset_bsz = CI_TX_DESC_DTYPE_DATA |
@@ -552,7 +603,7 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
tx_id = txe->next_id;
txe = txn;
- m_seg = m_seg->next;
+ m_seg = next_seg;
} while (m_seg);
end_pkt:
txq->nb_tx_free = (uint16_t)(txq->nb_tx_free - nb_used);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/2] net/intel: write mbuf for last Tx desc of segment
From: Bruce Richardson @ 2026-06-02 15:45 UTC (permalink / raw)
To: dev; +Cc: mb, ciara.loftus, Bruce Richardson
In-Reply-To: <20260602154513.1079865-1-bruce.richardson@intel.com>
When a single mbuf segment has more data than can be handled by a single
Tx data descriptor in the TSO case, adjust how the storing of mbufs is
being done. Rather than putting the mbuf pointer in the first slot for
that segment, store it in the last slot instead. This guarantees for us
that the descriptor for which we have desc-done (DD) writeback always
has a valid mbuf associated with it.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
drivers/net/intel/common/tx_scalar.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/intel/common/tx_scalar.h b/drivers/net/intel/common/tx_scalar.h
index 9fcd2e4733..7809bd53e8 100644
--- a/drivers/net/intel/common/tx_scalar.h
+++ b/drivers/net/intel/common/tx_scalar.h
@@ -509,7 +509,6 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
if (txe->mbuf)
rte_pktmbuf_free_seg(txe->mbuf);
- txe->mbuf = m_seg;
/* Setup TX Descriptor */
/* Calculate segment length, using IPsec callback if provided */
@@ -528,6 +527,7 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
((uint64_t)CI_MAX_DATA_PER_TXD << CI_TXD_QW1_TX_BUF_SZ_S) |
((uint64_t)td_tag << CI_TXD_QW1_L2TAG1_S);
write_txd(txd, buf_dma_addr, cmd_type_offset_bsz);
+ txe->mbuf = NULL;
buf_dma_addr += CI_MAX_DATA_PER_TXD;
slen -= CI_MAX_DATA_PER_TXD;
@@ -548,6 +548,7 @@ ci_xmit_pkts(struct ci_tx_queue *txq,
((uint64_t)slen << CI_TXD_QW1_TX_BUF_SZ_S) |
((uint64_t)td_tag << CI_TXD_QW1_L2TAG1_S);
write_txd(txd, buf_dma_addr, cmd_type_offset_bsz);
+ txe->mbuf = m_seg;
tx_id = txe->next_id;
txe = txn;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/2] net/intel: optimize for fast-free hint
From: Bruce Richardson @ 2026-06-02 15:45 UTC (permalink / raw)
To: dev; +Cc: mb, ciara.loftus, Bruce Richardson
In-Reply-To: <20260123112032.2174361-1-bruce.richardson@intel.com>
When the fast-free hint is provided to the driver we know that the mbufs
have refcnt of 1 and are from the same mempool. Therefore, we can
optimize a bit for this case even in the scalar path of our drivers.
---
v4:
* add precursor patch to adjust mbuf pointers so that the DD bit
is written to a descriptor with a valid mbuf pointer associated
with it.
v3:
* used mbuf_raw_free_bulk rather than mempool function directly
* check for fast_free via mp pointer rather than flags
* remove unnecessary prefetches
V2: Fix issues with original submission:
* missed check for NULL mbufs
* fixed issue with freeing directly from sw_ring in scalar path which
doesn't work as thats not a flag array of pointers
* fixed missing null assignment in case of large segments for TSO
Bruce Richardson (2):
net/intel: write mbuf for last Tx desc of segment
net/intel: optimize for fast-free hint
drivers/net/intel/common/tx.h | 21 ++++--
drivers/net/intel/common/tx_scalar.h | 98 +++++++++++++++++++++-------
2 files changed, 90 insertions(+), 29 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v3] net/intel: optimize for fast-free hint
From: Bruce Richardson @ 2026-06-02 15:36 UTC (permalink / raw)
To: Loftus, Ciara; +Cc: dev@dpdk.org, mb@smartsharesystems.com
In-Reply-To: <DM3PPF7D18F34A17BA228196DB8843D7D6F8E092@DM3PPF7D18F34A1.namprd11.prod.outlook.com>
On Thu, May 28, 2026 at 02:23:00PM +0100, Loftus, Ciara wrote:
> > Subject: [PATCH v3] net/intel: optimize for fast-free hint
> >
>
> snip
>
> > diff --git a/drivers/net/intel/common/tx_scalar.h
> > b/drivers/net/intel/common/tx_scalar.h
> > index 9fcd2e4733..d27df34dfa 100644
> > --- a/drivers/net/intel/common/tx_scalar.h
> > +++ b/drivers/net/intel/common/tx_scalar.h
> > @@ -197,16 +197,64 @@ ci_tx_xmit_cleanup(struct ci_tx_queue *txq)
> > const uint16_t rs_idx = (last_desc_cleaned == nb_tx_desc - 1) ?
> > 0 :
> > (last_desc_cleaned + 1) >> txq->log2_rs_thresh;
> > - uint16_t desc_to_clean_to = (rs_idx << txq->log2_rs_thresh) + (txq-
> > >tx_rs_thresh - 1);
> > + const uint16_t dd_idx = txq->rs_last_id[rs_idx];
> > + const uint16_t first_to_clean = rs_idx << txq->log2_rs_thresh;
> >
> > - /* Check if descriptor is done */
> > - if ((txd[txq->rs_last_id[rs_idx]].cmd_type_offset_bsz &
> > - rte_cpu_to_le_64(CI_TXD_QW1_DTYPE_M)) !=
> > -
> > rte_cpu_to_le_64(CI_TX_DESC_DTYPE_DESC_DONE))
> > + /* Check if descriptor is done - all drivers use 0xF as done value in bits
> > 3:0 */
> > + if ((txd[dd_idx].cmd_type_offset_bsz &
> > rte_cpu_to_le_64(CI_TXD_QW1_DTYPE_M)) !=
> > + rte_cpu_to_le_64(CI_TX_DESC_DTYPE_DESC_DONE))
> > + /* Descriptor not yet processed by hardware */
> > return -1;
> >
> > + /* DD bit is set, descriptors are done. Now free the mbufs. */
> > + /* Note: nb_tx_desc is guaranteed to be a multiple of tx_rs_thresh,
> > + * validated during queue setup. This means cleanup never wraps
> > around
> > + * the ring within a single burst (e.g., ring=256, rs_thresh=32 gives
> > + * bursts of 0-31, 32-63, ..., 224-255).
> > + */
> > + const uint16_t nb_to_clean = txq->tx_rs_thresh;
> > + struct ci_tx_entry *sw_ring = txq->sw_ring;
> > +
> > + /* fast_free_mp is NULL only when the fast free is disabled*/
> > + if (txq->fast_free_mp != NULL) {
> > + /* FAST_FREE path: mbufs are already reset, just return to
> > pool */
> > + struct rte_mbuf *free[CI_TX_MAX_FREE_BUF_SZ];
> > + uint16_t nb_free = 0;
> > +
> > + /* Get cached mempool pointer, or cache it on first use */
> > + struct rte_mempool *mp =
> > + likely(txq->fast_free_mp != (void *)UINTPTR_MAX) ?
> > + txq->fast_free_mp :
> > + (txq->fast_free_mp = sw_ring[dd_idx].mbuf->pool);
>
> Is the mbuf you are dereferencing here guaranteed to be non NULL?
>
Good point. It almost certainly is, but checking through the logic of the
code, the one possible error condition is where we have the last segment of
the packet being a large segment using TSO which is to be split across
multiple data descriptors. In that case (only) the mbuf pointer can be
NULL. In all other cases, it should be valid, because the DD bit can only
be set on a data descriptor.
Rather than trying to fix that issue here on cleanup, I think the better
solution is to adjust the large segment handling so that the last
descriptor of the segment, rather than the first, has the mbuf pointer.
That way we can always know that the descriptor that has DD set on it will
have a valid mbuf. Will implement this as a separate patch in v4.
/Bruce
^ permalink raw reply
* Re: [PATCH v4 06/10] net/mlx5: support selective Rx
From: Stephen Hemminger @ 2026-06-02 13:53 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Gregory Etelson, Dariusz Sosnowski, Viacheslav Ovsiienko,
Bing Zhao, Ori Kam, Suanming Mou, Matan Azrad
In-Reply-To: <20260529133522.2646044-7-thomas@monjalon.net>
On Fri, 29 May 2026 15:34:00 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:
> From: Gregory Etelson <getelson@nvidia.com>
>
> Selective Rx may save some PCI bandwidth.
> Implement selective Rx in the (quite slow) scalar SPRQ Rx path
> mlx5_rx_burst() where the performance impact
> of the added condition branches is acceptable.
> Other Rx functions do not support this feature.
> When using selective Rx, mlx5_rx_burst will be selected.
>
> A null Memory Region (MR) is always allocated
> at shared device context initialization.
> The selective Rx capability is not advertised
> if this special MR allocation fails.
>
> For each Rx segment configured with a NULL mempool,
> a "null mbuf" is created.
> It is a fake mbuf allocated outside any mempool,
> used as a placeholder in the Rx ring.
> The null MR lkey is used in the WQE for these segments
> so the NIC writes received data to a discard buffer.
> The mbuf data room size is resolved from the first segment having a pool.
> For null segments, the buffer length is from the last seen pool,
> so that the WQE stride size remains consistent.
>
> In mlx5_rx_burst, discarded segments are not chained
> into the packet mbuf list, NB_SEGS is decremented accordingly,
> and no replacement buffer is allocated.
> A separate data_seg_len accumulator tracks the total length
> of delivered segments only.
> The packet length is adjusted to reflect only the data
> actually delivered to the application.
>
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
AI review with Opus 4.8 and High setting found one issue:
Patch 6: net/mlx5: support selective Rx
Error: NULL pointer dereference when the first configured Rx segment is a
discard segment (mp == NULL).
In mlx5_rx_burst() the head mbuf and the chain tail are tracked like this:
if (pkt) {
if (rep->pool)
NEXT(tail) = rep;
else
--NB_SEGS(pkt);
}
...
if (seg->pool) {
tail = seg;
...
}
tail is only ever assigned inside "if (seg->pool)", and pkt is set to the
first processed segment unconditionally (pkt = seg in the !pkt block, no
pool guard). So if the first segment of a packet is a discard segment:
pkt becomes the null_mbuf (pool == NULL), tail stays NULL;
on the next (real) segment, rep->pool is set, so NEXT(tail) = rep executes with tail == NULL -> write through NULL.
Even without the crash, returning the pool-less null_mbuf as the packet
head is wrong: the application later frees it back to a NULL pool.
This is reachable, not theoretical. testpmd (patch 3) inserts a leading
mp==NULL segment whenever the first offset is > 0 (seg_offset > next_offset
with next_offset starting at 0), ethdev check_split (patch 2) now permits a
leading NULL mp, and mlx5_rxq_new() accepts it (first_mp is just the first
non-NULL pool; there is no requirement that rxseg[0].mp != NULL). The DTS
cases selective_rx_payload_only (rxoffs=[34]) and selective_rx_two_segments
(rxoffs=[14,...]) in patch 10 configure exactly this layout, and
mlx5_selective_rx_enabled() forces the scalar mlx5_rx_burst path, so the
buggy path is the one that runs.
Trace for rxoffs=34 / rxpkts=payload (segments: discard[0,34) real[34,290)
discard[290,max)):
iter0 (discard head): pkt == NULL, seg->pool == NULL -> pkt = null_mbuf,
tail not set; len(290) > DATA_LEN(34) -> ++NB_SEGS, continue.
iter1 (real seg): pkt set, rep->pool != NULL -> NEXT(tail==NULL)=rep.
Suggested fix: a discard segment must not become the packet head/tail.
Either reject rxseg[0].mp == NULL in mlx5_rxq_new() (cleanest, matches the
"deliver last N bytes" case being unsupported here), or make the data path
skip leading discard segments without assigning them to pkt and only set
pkt/tail on the first segment with a pool. If leading discard is intended
to be supported, the head selection and NEXT(tail) linking both need to
account for tail == NULL.
The same head/tail assumption also means a packet that falls entirely
within a leading discard segment would be returned with a NULL-pool head;
fixing the above covers that too.
^ permalink raw reply
* [PATCH] graph/conn: fix memory leak on socket init failure
From: Alexey Simakov @ 2026-06-02 13:12 UTC (permalink / raw)
To: Sunil Kumar Kori
Cc: Alexey Simakov, Rakesh Kudurumalla, Nithin Dabilpuram,
Jerin Jacob, dev, sdl.dpdk
In conn_init(), conn_free() does not release the buffer allocated
for conn structure, resulting in a memory leak when server socket
creation fails.
Add missing free(c->buf) call to conn_free().
Fixes: 3f90eda5b7fb ("app/graph: add telnet connectivity")
Cc: skori@marvell.com
Signed-off-by: Alexey Simakov <bigalex934@gmail.com>
---
app/graph/conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/graph/conn.c b/app/graph/conn.c
index c5e1c1ae1b..e73e929a08 100644
--- a/app/graph/conn.c
+++ b/app/graph/conn.c
@@ -197,6 +197,7 @@ conn_free(struct conn *c)
free(c->msg_in);
free(c->prompt);
free(c->welcome);
+ free(c->buf);
free(c);
}
--
2.34.1
^ permalink raw reply related
* RE: [RFC PATCH 3/3] build: deprecate HPET build option
From: Morten Brørup @ 2026-06-02 12:41 UTC (permalink / raw)
To: David Marchand, Bruce Richardson; +Cc: dev
In-Reply-To: <CAJFAV8x5_JihAXe_bruriVu01b5wmF4fJ7vD42yFfNwpJQwDtQ@mail.gmail.com>
> On the other hand, did you consider dropping HPET altogether?
Google AI says that - on modern CPUs - the HPET has no advantages over the TSC.
This supports David's idea.
Suggestion:
Rewrite HPET APIs as a shim to TSC, and deprecate the HPET APIs.
-Morten
^ permalink raw reply
* Re: [RFC PATCH 3/3] build: deprecate HPET build option
From: Bruce Richardson @ 2026-06-02 12:37 UTC (permalink / raw)
To: David Marchand; +Cc: Morten Brørup, dev
In-Reply-To: <CAJFAV8x5_JihAXe_bruriVu01b5wmF4fJ7vD42yFfNwpJQwDtQ@mail.gmail.com>
On Tue, Jun 02, 2026 at 01:39:42PM +0200, David Marchand wrote:
> On Tue, 2 Jun 2026 at 12:47, Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Tuesday, 2 June 2026 11.09
> > >
> > > We can enable the building of the HPET code by default on Linux, since
> > > the timers are not used - or even initialized - by default. Instead an
> > > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> > > APIs. Therefore, let's simplify the user experience by deprecating the
> > > option "use_hpet" and make it a no-op.
> > >
> > > To avoid issue with the dpdk-test binary which was trying to initialize
> > > the hpet on startup, move the hpet init call to the timer autotest -
> > > the
> > > only place where it was used.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > ---
> >
> > Careful!
> > I think this patch has unintended side effects:
> >
> > On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
> >
> > So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
> > We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
> >
> > I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
> > But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
>
> I don't see a functional impact.
>
> There may be an impact on performance?
> But users can switch to rte_get_tsc_cycles() to avoid the added branch.
>
I'd be very surprised if there was an impact from that. Any timers we have
already take a measurable number of cycles, so the extra branch is going to
be unnoticable IMHO.
>
> On the other hand, did you consider dropping HPET altogether?
>
I did, but that I considered a bit riskier and harder to do, as we don't
know who might actually be using it. This was a simple way to get rid of
the unnecessary option without impacting apps.
IIRC the main reason we had HPET off by default was that lots of distro
kernels in the past had the necessary MMAP_HPET support disabled by
default, making it awkward to use - the user had to compile the kernel.
However, I was pleasantly surprised to discover that Ubuntu has it enabled
by default so the HPET now works out of the box, and it's interesting to
see the timer_autotest doing TSC and HPET clock comparisons.
/Bruce
^ permalink raw reply
* Re: [RFC PATCH 3/3] build: deprecate HPET build option
From: Bruce Richardson @ 2026-06-02 12:27 UTC (permalink / raw)
To: Morten Brørup; +Cc: dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F658D8@smartserver.smartshare.dk>
On Tue, Jun 02, 2026 at 12:47:00PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 2 June 2026 11.09
> >
> > We can enable the building of the HPET code by default on Linux, since
> > the timers are not used - or even initialized - by default. Instead an
> > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> > APIs. Therefore, let's simplify the user experience by deprecating the
> > option "use_hpet" and make it a no-op.
> >
> > To avoid issue with the dpdk-test binary which was trying to initialize
> > the hpet on startup, move the hpet init call to the timer autotest -
> > the
> > only place where it was used.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> Careful!
> I think this patch has unintended side effects:
>
> On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
>
> So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
> We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
>
> I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
> But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
>
Good point, I hadn't considered if end applications had code guarded by
USE_HPET.
However, even if HPET support is build-enabled, it still requires apps to
explicitly opt-in a) to use it and then b) to make it the default for timer
operations. That means that if apps have got the code present to use HPET
by default, then they must have a valid reason for doing so and have
explicitly opted in to doing so by adding the hpet API calls. It's not
possible for apps to "accidentally" start using HPET. [I suppose there may
be a risk from old/legacy code in apps, maybe where hpet was used in the
past and forgotten about, but otherwise I can't see there being an issue.]
More review and testing is welcome though, to ensure I'm not actually
missing something here...
/Bruce
^ permalink raw reply
* RE: [PATCH 2/2] doc: update Arm IPsec-MB references for cryptodev PMDs
From: Hemant Agrawal @ 2026-06-02 12:10 UTC (permalink / raw)
To: Wathsala Vithanage, Kai Ji, Pablo de Lara
Cc: dev@dpdk.org, nd@arm.com, paul.elliott@arm.com,
dhruv.tripathi@arm.com, shebu.vargheseKuriakose@arm.com
In-Reply-To: <20260529210404.1986896-1-wathsala.vithanage@arm.com>
> -----Original Message-----
> From: Wathsala Vithanage <wathsala.vithanage@arm.com>
> Sent: 30 May 2026 02:34
> To: Kai Ji <kai.ji@intel.com>; Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; nd@arm.com; paul.elliott@arm.com;
> dhruv.tripathi@arm.com; shebu.vargheseKuriakose@arm.com; Wathsala
> Vithanage <wathsala.vithanage@arm.com>
> Subject: [PATCH 2/2] doc: update Arm IPsec-MB references for cryptodev
> PMDs
>
> Document Arm/ARM64 IPsec-MB source and supported tag level for
> aesni_mb, aesni_gcm, snow3g, and zuc cryptodev guides.
>
> - Add Arm library reference to aesni_mb and aesni_gcm docs.
> - Update snow3g and zuc IPsec-MB library tag to SECLIB-IPSEC-2026.05.30.
>
> Signed-off-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
> ---
> doc/guides/cryptodevs/aesni_gcm.rst | 4 ++++
> doc/guides/cryptodevs/aesni_mb.rst | 4 ++++
> doc/guides/cryptodevs/snow3g.rst | 2 +-
> doc/guides/cryptodevs/zuc.rst | 2 +-
> 4 files changed, 10 insertions(+), 2 deletions(-)
>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply
* RE: [PATCH 1/2] crypto/ipsec_mb: allow aesni_mb and aesni_gcm vdevs on Arm
From: Hemant Agrawal @ 2026-06-02 12:09 UTC (permalink / raw)
To: Wathsala Vithanage, Kai Ji, Pablo de Lara
Cc: dev@dpdk.org, nd@arm.com, Paul.Elliott@arm.com,
Dhruv.Tripathi@arm.com, Shebu.VargheseKuriakose@arm.com
In-Reply-To: <20260529205512.1985844-1-wathsala.vithanage@arm.com>
> -----Original Message-----
> From: Wathsala Vithanage <wathsala.vithanage@arm.com>
> Sent: 30 May 2026 02:25
> To: Kai Ji <kai.ji@intel.com>; Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; nd@arm.com; Paul.Elliott@arm.com;
> Dhruv.Tripathi@arm.com; Shebu.VargheseKuriakose@arm.com; Wathsala
> Vithanage <wathsala.vithanage@arm.com>
> Subject: [PATCH 1/2] crypto/ipsec_mb: allow aesni_mb and aesni_gcm vdevs
> on Arm
>
> Extend Arm PMD gating in ipsec_mb_create() to permit
> IPSEC_MB_PMD_TYPE_AESNI_MB and IPSEC_MB_PMD_TYPE_AESNI_GCM in
> addition to existing SNOW3G and ZUC.
>
> This removes -ENOTSUP rejection for crypto_aesni_mb and crypto_aesni_gcm
> on Arm, enabling these vdevs to probe and run when backed by a compatible
> ipsec-mb library.
>
> Signed-off-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
> ---
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply
* Re: [RFC PATCH 3/3] build: deprecate HPET build option
From: David Marchand @ 2026-06-02 11:39 UTC (permalink / raw)
To: Morten Brørup, Bruce Richardson; +Cc: dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F658D8@smartserver.smartshare.dk>
On Tue, 2 Jun 2026 at 12:47, Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 2 June 2026 11.09
> >
> > We can enable the building of the HPET code by default on Linux, since
> > the timers are not used - or even initialized - by default. Instead an
> > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> > APIs. Therefore, let's simplify the user experience by deprecating the
> > option "use_hpet" and make it a no-op.
> >
> > To avoid issue with the dpdk-test binary which was trying to initialize
> > the hpet on startup, move the hpet init call to the timer autotest -
> > the
> > only place where it was used.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> Careful!
> I think this patch has unintended side effects:
>
> On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
>
> So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
> We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
>
> I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
> But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
I don't see a functional impact.
There may be an impact on performance?
But users can switch to rte_get_tsc_cycles() to avoid the added branch.
On the other hand, did you consider dropping HPET altogether?
--
David Marchand
^ permalink raw reply
* RE: [RFC PATCH 3/3] build: deprecate HPET build option
From: Morten Brørup @ 2026-06-02 10:47 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260602090847.905721-4-bruce.richardson@intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
>
> We can enable the building of the HPET code by default on Linux, since
> the timers are not used - or even initialized - by default. Instead an
> app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> APIs. Therefore, let's simplify the user experience by deprecating the
> option "use_hpet" and make it a no-op.
>
> To avoid issue with the dpdk-test binary which was trying to initialize
> the hpet on startup, move the hpet init call to the timer autotest -
> the
> only place where it was used.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Careful!
I think this patch has unintended side effects:
On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
^ permalink raw reply
* Re: [PATCH] gpu/metax: add new driver for Metax GPU
From: Thomas Monjalon @ 2026-06-02 10:01 UTC (permalink / raw)
To: 许玲燕; +Cc: dev, eagostini
In-Reply-To: <6c18e957-c1c2-4b43-9b2c-b36424c1e9af.lingyan.xu@metax-tech.com>
Hello,
01/06/2026 07:47, 许玲燕:
> I am writing to propose a new driver for the Metax GPU,
How do you access the GPU?
Are you using a specific library or kernel module?
> which I believe will significantly enhance our support
> and performance for this hardware.
> The patch attached includes the initial implementation of the driver,
> with key features such as:
>
> * Basic initialization and configuration
> * Memory management and allocation
> * Core functionality for rendering and compute tasks
I am familiar with connecting compute tasks of a GPU
with DPDK networking, but I'm surprised by the rendering functionality.
Do you mean graphical rendering of data coming from the network?
> Please review the code and let me know if you have any feedback or suggestions.
> I am more than happy to make any necessary adjustments and improvements.
Thank you for working on this.
I recommend following this guide to introduce a new driver:
https://doc.dpdk.org/guides/contributing/new_driver.html
^ permalink raw reply
* RE: [RFC PATCH 2/3] build: deprecate standalone tests option
From: Morten Brørup @ 2026-06-02 9:26 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260602090847.905721-3-bruce.richardson@intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
>
> The unit tests can be disabled in DPDK in a couple of ways. Firstly,
> there is the original "tests" boolean option - when set to false, the
> tests are skipped as part of the build. However, the newer
> enable_apps/disable_apps options also can be used to disable the tests
> [you can disable using the "enable" option by omitting "tests" from the
> list to enable].
>
> This duplication of functionality is unnecessary, so let's remove the
> standalone tests option.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Good cleanup.
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* RE: [RFC PATCH 1/3] build: deprecate kernel dir option
From: Morten Brørup @ 2026-06-02 9:24 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260602090847.905721-2-bruce.richardson@intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
>
> The kernel_dir option does nothing, so it can be deprecated and removed
> in future.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Good cleanup.
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* RE: [PATCH] ring: avoid extra store at move head
From: Morten Brørup @ 2026-06-02 9:21 UTC (permalink / raw)
To: Konstantin Ananyev, Stephen Hemminger; +Cc: dev
In-Reply-To: <580828b0214b4e1fb22e2f6d4079eadf@huawei.com>
> > Then had Claude compare results:
> >
> > Key metric (two physical cores legacy MP/MC bulk n=128):
> > main: 5.380 cycles/elem
> > sync-bool: 5.377 cycles/elem (-0.07%)
> > avoid-store: 5.892 cycles/elem (+9.52%) ← regresses
> >
> >
> > Looking at the dissassembly of ring_enqueue_bulk:
> >
> > The inner loop of main and sync-bool versions is:
> > mov 0x80(%rdi),%r11d ; load d->head via displacement
> > mov 0x104(%rdi),%ebx ; load s->tail
> > add %ecx,%ebx
> > sub %r11d,%ebx
> > cmp %ebx,%r12d
> > jae [exit]
> > lea (%r8,%r11,1),%r13d ; new_head = old_head + n
> > mov %r11d,%eax ; expected → eax
> > lock cmpxchg %r13d,0x80(%rdi) ; ← displacement addressing
> > jne [retry] ; ← direct jne, eax preserved
> >
> > Using atomic_compare_exchange and your patch:
> > mov 0x38(%rdi),%r10d
> > mov 0x80(%rdi),%eax ; load d->head directly into %eax
> > lea 0x80(%rdi),%rcx ; ← MATERIALIZE &d->head into
> %rcx
> > lea -0x1(%r8),%r12d
> > mov 0x104(%rdi),%r11d
> > add %r10d,%r11d
> > sub %eax,%r11d
> > cmp %r11d,%r12d
> > jae [exit]
> > lea (%r8,%rax,1),%r13d ; new_head
> > lock cmpxchg %r13d,(%rcx) ; ← INDIRECT addressing via %rcx
> > mov %eax,%ebx ; ← EXTRA: save post-CAS %eax to
> %ebx
> > jne [retry]
> >
> > Bottom line: good idea but still fighting with Gcc optimizer here.
>
> Thanks for trying.
> On my box (AMD EPYC 9534) with same test, there is no much difference
> between all of them:
> use-sync-bool: 2.2273
> use-c11-current-version: 2.2422
> use-c11-patched: 2.2431
> Anyway, -10% on some boxes - that's probably good enough reason to keep
> specific version
> for __rte_ring_headtail_move_head_mt().
> My ask would be to have some special macro for it, so users can
> enable/disable it via 'meson setup' at will.
This seems very exotic as a meson command line option.
Either put it in rte_config.h, or make it CPU specific.
^ permalink raw reply
* [RFC PATCH 3/3] build: deprecate HPET build option
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
In-Reply-To: <20260602090847.905721-1-bruce.richardson@intel.com>
We can enable the building of the HPET code by default on Linux, since
the timers are not used - or even initialized - by default. Instead an
app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
APIs. Therefore, let's simplify the user experience by deprecating the
option "use_hpet" and make it a no-op.
To avoid issue with the dpdk-test binary which was trying to initialize
the hpet on startup, move the hpet init call to the timer autotest - the
only place where it was used.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test.c | 7 -------
app/test/test_timer.c | 5 +++++
config/meson.build | 2 +-
doc/guides/linux_gsg/enable_func.rst | 2 --
doc/guides/rel_notes/deprecation.rst | 2 ++
lib/eal/linux/meson.build | 5 +----
meson_options.txt | 2 +-
7 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/app/test/test.c b/app/test/test.c
index 58ef52f312..99d6e90f8b 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -180,13 +180,6 @@ main(int argc, char **argv)
goto out;
}
-#ifdef RTE_LIBEAL_USE_HPET
- if (rte_eal_hpet_init(1) < 0)
-#endif
- RTE_LOG(INFO, APP,
- "HPET is not enabled, using TSC as default timer\n");
-
-
char *dpdk_test = getenv("DPDK_TEST");
if (dpdk_test && strlen(dpdk_test) > 0)
diff --git a/app/test/test_timer.c b/app/test/test_timer.c
index c936843ddc..dcb26c4395 100644
--- a/app/test/test_timer.c
+++ b/app/test/test_timer.c
@@ -501,6 +501,11 @@ static int
timer_sanity_check(void)
{
#ifdef RTE_LIBEAL_USE_HPET
+ if (rte_eal_hpet_init(1) < 0) {
+ printf("HPET is not enabled, using TSC as default timer\n");
+ return 0;
+ }
+
if (eal_timer_source != EAL_TIMER_HPET) {
printf("Not using HPET, can't sanity check timer sources\n");
return 0;
diff --git a/config/meson.build b/config/meson.build
index 9ba7b9a338..6012a3c243 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -381,7 +381,7 @@ endforeach
# set other values pulled from the build options
dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
-dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
+dpdk_conf.set('RTE_LIBEAL_USE_HPET', is_linux)
dpdk_conf.set('RTE_ENABLE_STDATOMIC', get_option('enable_stdatomic'))
dpdk_conf.set('RTE_ENABLE_TRACE_FP', get_option('enable_trace_fp'))
dpdk_conf.set('RTE_PKTMBUF_HEADROOM', get_option('pkt_mbuf_headroom'))
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index 4e1a939f35..1d5b030172 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -176,8 +176,6 @@ To enable HPET support in DPDK:
Note that this may involve doing a kernel rebuild,
as many common linux distributions do *not* have this setting
enabled by default in their kernel builds.
-#. Enable DPDK support for HPET by using the build-time meson option ``use_hpet``,
- for example, ``meson configure -Duse_hpet=true``
For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls,
and optionally to make the HPET the default time source for the rte_timer library,
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 15459851d0..42ad118c92 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -21,6 +21,8 @@ Deprecation Notices
- ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
- ``tests``: disabling tests can be achieved by using the ``enable_apps`` / ``disable_apps`` options instead.
+ - ``use_hpet``: option unused as HPET is only supported on Linux
+ and is runtime-enabled using ``rte_eal_hpet_init()`` API.
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
diff --git a/lib/eal/linux/meson.build b/lib/eal/linux/meson.build
index 29ba313218..8b0519c9a1 100644
--- a/lib/eal/linux/meson.build
+++ b/lib/eal/linux/meson.build
@@ -15,14 +15,11 @@ sources += files(
'eal_memory.c',
'eal_thread.c',
'eal_timer.c',
+ 'eal_timer_hpet.c',
'eal_vfio.c',
'eal_vfio_mp_sync.c',
)
-if dpdk_conf.get('RTE_LIBEAL_USE_HPET')
- sources += files('eal_timer_hpet.c')
-endif
-
deps += ['kvargs', 'telemetry']
if has_libnuma
dpdk_conf.set10('RTE_EAL_NUMA_AWARE_HUGEPAGES', true)
diff --git a/meson_options.txt b/meson_options.txt
index 323a3901e1..242de6681f 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -57,4 +57,4 @@ option('enable_trace_fp', type: 'boolean', value: false, description:
option('tests', type: 'boolean', value: true, description:
'[Deprecated] Value unused. Add "tests" to disable_apps setting to disable the unit tests')
option('use_hpet', type: 'boolean', value: false, description:
- 'use HPET timer in EAL')
+ '[Deprecated] Value unused. HPET can be runtime-enabled on Linux using rte_eal_hpet_init().')
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 2/3] build: deprecate standalone tests option
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
In-Reply-To: <20260602090847.905721-1-bruce.richardson@intel.com>
The unit tests can be disabled in DPDK in a couple of ways. Firstly,
there is the original "tests" boolean option - when set to false, the
tests are skipped as part of the build. However, the newer
enable_apps/disable_apps options also can be used to disable the tests
[you can disable using the "enable" option by omitting "tests" from the
list to enable].
This duplication of functionality is unnecessary, so let's remove the
standalone tests option.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/meson.build | 6 +-----
doc/guides/rel_notes/deprecation.rst | 1 +
meson_options.txt | 2 +-
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/app/meson.build b/app/meson.build
index 1798db3ae4..52f704ec94 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -17,6 +17,7 @@ apps = [
'graph',
'pdump',
'proc-info',
+ 'test',
'test-acl',
'test-bbdev',
'test-cmdline',
@@ -35,11 +36,6 @@ apps = [
'test-security-perf',
]
-if get_option('tests')
-# build the auto test app if enabled.
- apps += 'test'
-endif
-
default_cflags = machine_args + ['-DALLOW_EXPERIMENTAL_API']
default_ldflags = []
if get_option('default_library') == 'static' and not is_windows
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ed1dda6008..15459851d0 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,6 +20,7 @@ Deprecation Notices
* build: The following meson build options are deprecated and will be removed in a future release:
- ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
+ - ``tests``: disabling tests can be achieved by using the ``enable_apps`` / ``disable_apps`` options instead.
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
diff --git a/meson_options.txt b/meson_options.txt
index 7bd5ebc084..323a3901e1 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -55,6 +55,6 @@ option('enable_stdatomic', type: 'boolean', value: false, description:
option('enable_trace_fp', type: 'boolean', value: false, description:
'enable fast path trace points.')
option('tests', type: 'boolean', value: true, description:
- 'build unit tests')
+ '[Deprecated] Value unused. Add "tests" to disable_apps setting to disable the unit tests')
option('use_hpet', type: 'boolean', value: false, description:
'use HPET timer in EAL')
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 1/3] build: deprecate kernel dir option
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
In-Reply-To: <20260602090847.905721-1-bruce.richardson@intel.com>
The kernel_dir option does nothing, so it can be deprecated and removed
in future.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
meson_options.txt | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 17f90a6352..ed1dda6008 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,6 +17,10 @@ Other API and ABI deprecation notices are to be posted below.
Deprecation Notices
-------------------
+* build: The following meson build options are deprecated and will be removed in a future release:
+
+ - ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
+
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
diff --git a/meson_options.txt b/meson_options.txt
index e28d24054c..7bd5ebc084 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -33,7 +33,7 @@ option('ibverbs_link', type: 'combo', choices : ['static', 'shared', 'dlopen'],
option('include_subdir_arch', type: 'string', value: '', description:
'subdirectory where to install arch-dependent headers')
option('kernel_dir', type: 'string', value: '', description:
- 'Path to the kernel for building kernel modules. Headers must be in $kernel_dir or $kernel_dir/build. Modules will be installed in /lib/modules.')
+ '[Deprecated] Value unused. Previously, path to the kernel for building kernel modules.')
option('machine', type: 'string', value: 'auto', description:
'Alias of cpu_instruction_set.')
option('max_ethports', type: 'integer', value: 32, description:
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 0/3] remove unneeded build options
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Having unnecessary build options just makes things confusing for
the user, and expands the set of potential builds. This set
makes 3 build options no-ops, and marks them as deprecated for
future removal.
Bruce Richardson (3):
build: deprecate kernel dir option
build: deprecate standalone tests option
build: deprecate HPET build option
app/meson.build | 6 +-----
app/test/test.c | 7 -------
app/test/test_timer.c | 5 +++++
config/meson.build | 2 +-
doc/guides/linux_gsg/enable_func.rst | 2 --
doc/guides/rel_notes/deprecation.rst | 7 +++++++
lib/eal/linux/meson.build | 5 +----
meson_options.txt | 6 +++---
8 files changed, 18 insertions(+), 22 deletions(-)
--
2.53.0
^ permalink raw reply
* RE: [PATCH] crypto/openssl: fix use-after-free bug and cleanup
From: Akhil Goyal @ 2026-06-02 9:03 UTC (permalink / raw)
To: Pratik Senapati, dev@dpdk.org
Cc: Anoob Joseph, Gowrishankar Muthukrishnan, kai.ji@intel.com,
stable@dpdk.org
In-Reply-To: <20260528075822.2206494-1-psenapati@marvell.com>
> -----Original Message-----
> From: Pratik Senapati <psenapati@marvell.com>
> Sent: Thursday, May 28, 2026 1:28 PM
> To: dev@dpdk.org
> Cc: Akhil Goyal <gakhil@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
> Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>; kai.ji@intel.com;
> stable@dpdk.org
> Subject: [PATCH] crypto/openssl: fix use-after-free bug and cleanup
>
> params is freed before it is used by
> EVP_PKEY_decapsulate_init() causing a
> use-after-free issue. Pass NULL to
> EVP_PKEY_decapsulate_init() instead of params
> to avoid it.
>
> Add resource cleanup for all error paths in the ML-KEM
> decapsulate handler and consolidate cleanup into
> two goto labels err_pkey and err_decap.
>
> Fixes: 5f761d7b60 ("crypto/openssl: support ML-KEM and ML-DSA")
> Cc: stable@dpdk.org
> Signed-off-by: Pratik Senapati <psenapati@marvell.com>
> ---
Fix compilation.
^ permalink raw reply
* RE: [PATCH] app/crypto-perf: support ML DSA
From: Akhil Goyal @ 2026-06-02 9:02 UTC (permalink / raw)
To: Pratik Senapati, dev@dpdk.org
Cc: Anoob Joseph, Gowrishankar Muthukrishnan, kai.ji@intel.com
In-Reply-To: <20260528075853.2206573-2-psenapati@marvell.com>
Please send this patch as a series with ML KEM support so that CI can run successfully.
^ permalink raw reply
* RE: [PATCH] ring: avoid extra store at move head
From: Konstantin Ananyev @ 2026-06-02 9:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev@dpdk.org
In-Reply-To: <20260601152313.1946d438@phoenix.local>
> > C11 __rte_ring_headtail_move_head_mt() uses output
> > parameter: 'uint32_t *old_head' directly within CAS operation.
> > In x86_64 that cause gcc to generate extra instructions to
> > store return value of CAS (eax) within 'old_head' memory location,
> > even when CAS was not successful and another attempt should be
> > performed. In some cases, even extra branch can be observed.
> > To be more specific the code like that is generated:
> > // start of 'do { } while();' loop
> > .L2
> > ...
> > lock cmpxchgl %r8d, (%rdi)
> > jne .L17 //
> > .L1: // <---- successful completion of CAS, finish
> > movl %edx, %eax
> > ret
> > .L17: // <---- unsuccessful completion of CAS, repeat
> > movl %eax, (%r9)
> > jmp .L2
> >
> > In constrast, x86 specific version that uses
> > __sync_bool_compare_and_swap() doesn't exibit such problem,
> > as __sync_bool_compare_and_swap() doesn't update the 'old_head'
> > with new value, and we have to re-read it explicitly on each iteration.
> >
> > Overcome that problem by using local variable 'head' inside the loop,
> > and updaing '*old_head' value only at exit.
> > With such change gcc manages to avoid extra store(/branch).
> >
> > Depends-on: series-38225 ("deprecate rte_atomicNN family")
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > ---
>
> I used the standard ring perf tests and ran 10 times via:
> ! /bin/bash
> if [ -z "$1" ]; then
> echo "Usage $0 version"
> exit 1
> fi
>
> VERSION=$1
> for i in $(seq 1 10); do
> sudo DPDK_TEST=ring_perf_autotest \
> ./build/app/dpdk-test -l 2-5 -n 4 --no-pci --file-prefix=run$i \
> > ~/DPDK/ring_perf_results/${VERSION}_run${i}.log 2>&1
> echo "${VERSION} run $i done"
> done
>
>
> Then had Claude compare results:
>
> Key metric (two physical cores legacy MP/MC bulk n=128):
> main: 5.380 cycles/elem
> sync-bool: 5.377 cycles/elem (-0.07%)
> avoid-store: 5.892 cycles/elem (+9.52%) ← regresses
>
>
> Looking at the dissassembly of ring_enqueue_bulk:
>
> The inner loop of main and sync-bool versions is:
> mov 0x80(%rdi),%r11d ; load d->head via displacement
> mov 0x104(%rdi),%ebx ; load s->tail
> add %ecx,%ebx
> sub %r11d,%ebx
> cmp %ebx,%r12d
> jae [exit]
> lea (%r8,%r11,1),%r13d ; new_head = old_head + n
> mov %r11d,%eax ; expected → eax
> lock cmpxchg %r13d,0x80(%rdi) ; ← displacement addressing
> jne [retry] ; ← direct jne, eax preserved
>
> Using atomic_compare_exchange and your patch:
> mov 0x38(%rdi),%r10d
> mov 0x80(%rdi),%eax ; load d->head directly into %eax
> lea 0x80(%rdi),%rcx ; ← MATERIALIZE &d->head into %rcx
> lea -0x1(%r8),%r12d
> mov 0x104(%rdi),%r11d
> add %r10d,%r11d
> sub %eax,%r11d
> cmp %r11d,%r12d
> jae [exit]
> lea (%r8,%rax,1),%r13d ; new_head
> lock cmpxchg %r13d,(%rcx) ; ← INDIRECT addressing via %rcx
> mov %eax,%ebx ; ← EXTRA: save post-CAS %eax to %ebx
> jne [retry]
>
> Bottom line: good idea but still fighting with Gcc optimizer here.
Thanks for trying.
On my box (AMD EPYC 9534) with same test, there is no much difference between all of them:
use-sync-bool: 2.2273
use-c11-current-version: 2.2422
use-c11-patched: 2.2431
Anyway, -10% on some boxes - that's probably good enough reason to keep specific version
for __rte_ring_headtail_move_head_mt().
My ask would be to have some special macro for it, so users can enable/disable it via
'meson setup' at will.
Konstantin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox