* [RFC 2/7] eal: reimplement rte_smp_*mb with rte_atomic_thread_fence
From: Stephen Hemminger @ 2026-05-21 4:17 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Wathsala Vithanage, Bibo Mao,
David Christensen, Sun Yuechi, Bruce Richardson,
Konstantin Ananyev
In-Reply-To: <20260521042043.1590536-1-stephen@networkplumber.org>
The rte_smp_mb(), rte_smp_wmb() and rte_smp_rmb() functions were
flagged as deprecated by commit 3ec965b6de12 ("doc: update atomic
operation deprecation") in 2021 but nothing came of it.
Reimplement them as inline wrappers over rte_atomic_thread_fence()
and drop the deprecation notice.
The API is preserved; only the implementation changes.
Generated code is unchanged on x86 (seq_cst keeps the lock-addl
trick, release/acquire collapse to a compiler barrier under TSO).
On arm64, release/acquire emit dmb ish instead of dmb ishst/ishld;
the difference is below measurement noise.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 8 --
lib/eal/arm/include/rte_atomic_32.h | 6 --
lib/eal/arm/include/rte_atomic_64.h | 6 --
lib/eal/include/generic/rte_atomic.h | 106 +++++++++++--------------
lib/eal/loongarch/include/rte_atomic.h | 6 --
lib/eal/ppc/include/rte_atomic.h | 6 --
lib/eal/riscv/include/rte_atomic.h | 6 --
lib/eal/x86/include/rte_atomic.h | 33 +++-----
8 files changed, 57 insertions(+), 120 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 346c517623..03b763b472 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -47,14 +47,6 @@ Deprecation Notices
operations must be used for patches that need to be merged in 20.08 onwards.
This change will not introduce any performance degradation.
-* rte_smp_*mb: These APIs provide full barrier functionality. However, many
- use cases do not require full barriers. To support such use cases, DPDK has
- adopted atomic operations from
- https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. These
- operations and a new wrapper ``rte_atomic_thread_fence`` instead of
- ``__atomic_thread_fence`` must be used for patches that need to be merged in
- 20.08 onwards. This change will not introduce any performance degradation.
-
* lib: will fix extending some enum/define breaking the ABI. There are multiple
samples in DPDK that enum/define terminated with a ``.*MAX.*`` value which is
used by iterators, and arrays holding these values are sized with this
diff --git a/lib/eal/arm/include/rte_atomic_32.h b/lib/eal/arm/include/rte_atomic_32.h
index 0b9a0dfa30..3809ddefb7 100644
--- a/lib/eal/arm/include/rte_atomic_32.h
+++ b/lib/eal/arm/include/rte_atomic_32.h
@@ -21,12 +21,6 @@ extern "C" {
#define rte_rmb() __sync_synchronize()
-#define rte_smp_mb() rte_mb()
-
-#define rte_smp_wmb() rte_wmb()
-
-#define rte_smp_rmb() rte_rmb()
-
#define rte_io_mb() rte_mb()
#define rte_io_wmb() rte_wmb()
diff --git a/lib/eal/arm/include/rte_atomic_64.h b/lib/eal/arm/include/rte_atomic_64.h
index 181bb60929..c9b41f6212 100644
--- a/lib/eal/arm/include/rte_atomic_64.h
+++ b/lib/eal/arm/include/rte_atomic_64.h
@@ -24,12 +24,6 @@ extern "C" {
#define rte_rmb() asm volatile("dmb oshld" : : : "memory")
-#define rte_smp_mb() asm volatile("dmb ish" : : : "memory")
-
-#define rte_smp_wmb() asm volatile("dmb ishst" : : : "memory")
-
-#define rte_smp_rmb() asm volatile("dmb ishld" : : : "memory")
-
#define rte_io_mb() rte_mb()
#define rte_io_wmb() rte_wmb()
diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
index 0a4f3f8528..4e9d230f85 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -49,69 +49,8 @@ static inline void rte_wmb(void);
* occur before the LOAD operations generated after.
*/
static inline void rte_rmb(void);
-///@}
-
-/** @name SMP Memory Barrier
- */
-///@{
-/**
- * General memory barrier between lcores
- *
- * Guarantees that the LOAD and STORE operations that precede the
- * rte_smp_mb() call are globally visible across the lcores
- * before the LOAD and STORE operations that follows it.
- *
- * @note
- * This function is deprecated.
- * It provides similar synchronization primitive as atomic fence,
- * but has different syntax and memory ordering semantic. Hence
- * deprecated for the simplicity of memory ordering semantics in use.
- *
- * rte_atomic_thread_fence(rte_memory_order_acq_rel) should be used instead.
- */
-static inline void rte_smp_mb(void);
-/**
- * Write memory barrier between lcores
- *
- * Guarantees that the STORE operations that precede the
- * rte_smp_wmb() call are globally visible across the lcores
- * before the STORE operations that follows it.
- *
- * @note
- * This function is deprecated.
- * It provides similar synchronization primitive as atomic fence,
- * but has different syntax and memory ordering semantic. Hence
- * deprecated for the simplicity of memory ordering semantics in use.
- *
- * rte_atomic_thread_fence(rte_memory_order_release) should be used instead.
- * The fence also guarantees LOAD operations that precede the call
- * are globally visible across the lcores before the STORE operations
- * that follows it.
- */
-static inline void rte_smp_wmb(void);
-
-/**
- * Read memory barrier between lcores
- *
- * Guarantees that the LOAD operations that precede the
- * rte_smp_rmb() call are globally visible across the lcores
- * before the LOAD operations that follows it.
- *
- * @note
- * This function is deprecated.
- * It provides similar synchronization primitive as atomic fence,
- * but has different syntax and memory ordering semantic. Hence
- * deprecated for the simplicity of memory ordering semantics in use.
- *
- * rte_atomic_thread_fence(rte_memory_order_acquire) should be used instead.
- * The fence also guarantees LOAD operations that precede the call
- * are globally visible across the lcores before the STORE operations
- * that follows it.
- */
-static inline void rte_smp_rmb(void);
///@}
-
/** @name I/O Memory Barrier
*/
///@{
@@ -164,6 +103,51 @@ static inline void rte_io_rmb(void);
*/
static inline void rte_atomic_thread_fence(rte_memory_order memorder);
+
+/** @name SMP Memory Barrier
+ */
+///@{
+/**
+ * General memory barrier between lcores
+ *
+ * Guarantees that the LOAD and STORE operations that precede the
+ * rte_smp_mb() call are globally visible across the lcores
+ * before the LOAD and STORE operations that follows it.
+ */
+static __rte_always_inline void
+rte_smp_mb(void)
+{
+ rte_atomic_thread_fence(rte_memory_order_seq_cst);
+}
+
+/**
+ * Write memory barrier between lcores
+ *
+ * Guarantees that the STORE operations that precede the
+ * rte_smp_wmb() call are globally visible across the lcores
+ * before the STORE operations that follows it.
+ */
+static __rte_always_inline void
+rte_smp_wmb(void)
+{
+ rte_atomic_thread_fence(rte_memory_order_release);
+}
+
+/**
+ * Read memory barrier between lcores
+ *
+ * Guarantees that the LOAD operations that precede the
+ * rte_smp_rmb() call are globally visible across the lcores
+ * before the LOAD operations that follows it.
+ */
+static __rte_always_inline void
+rte_smp_rmb(void)
+{
+ rte_atomic_thread_fence(rte_memory_order_acquire);
+}
+
+///@}
+
/*------------------------- 16 bit atomic operations -------------------------*/
#ifndef RTE_TOOLCHAIN_MSVC
diff --git a/lib/eal/loongarch/include/rte_atomic.h b/lib/eal/loongarch/include/rte_atomic.h
index c8066a4612..49e0c67020 100644
--- a/lib/eal/loongarch/include/rte_atomic.h
+++ b/lib/eal/loongarch/include/rte_atomic.h
@@ -22,12 +22,6 @@ extern "C" {
#define rte_rmb() rte_mb()
-#define rte_smp_mb() rte_mb()
-
-#define rte_smp_wmb() rte_mb()
-
-#define rte_smp_rmb() rte_mb()
-
#define rte_io_mb() rte_mb()
#define rte_io_wmb() rte_mb()
diff --git a/lib/eal/ppc/include/rte_atomic.h b/lib/eal/ppc/include/rte_atomic.h
index 10acc238f9..1da5afccbf 100644
--- a/lib/eal/ppc/include/rte_atomic.h
+++ b/lib/eal/ppc/include/rte_atomic.h
@@ -24,12 +24,6 @@ extern "C" {
#define rte_rmb() asm volatile("sync" : : : "memory")
-#define rte_smp_mb() rte_mb()
-
-#define rte_smp_wmb() rte_wmb()
-
-#define rte_smp_rmb() rte_rmb()
-
#define rte_io_mb() rte_mb()
#define rte_io_wmb() rte_wmb()
diff --git a/lib/eal/riscv/include/rte_atomic.h b/lib/eal/riscv/include/rte_atomic.h
index 66346ad474..dd10ad5127 100644
--- a/lib/eal/riscv/include/rte_atomic.h
+++ b/lib/eal/riscv/include/rte_atomic.h
@@ -27,12 +27,6 @@ extern "C" {
#define rte_rmb() asm volatile("fence r, r" : : : "memory")
-#define rte_smp_mb() rte_mb()
-
-#define rte_smp_wmb() rte_wmb()
-
-#define rte_smp_rmb() rte_rmb()
-
#define rte_io_mb() asm volatile("fence iorw, iorw" : : : "memory")
#define rte_io_wmb() asm volatile("fence orw, ow" : : : "memory")
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index e071e4234e..a850b0257c 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -23,10 +23,6 @@
#define rte_rmb() _mm_lfence()
-#define rte_smp_wmb() rte_compiler_barrier()
-
-#define rte_smp_rmb() rte_compiler_barrier()
-
#ifdef __cplusplus
extern "C" {
#endif
@@ -63,20 +59,6 @@ extern "C" {
* So below we use that technique for rte_smp_mb() implementation.
*/
-static __rte_always_inline void
-rte_smp_mb(void)
-{
-#ifdef RTE_TOOLCHAIN_MSVC
- _mm_mfence();
-#else
-#ifdef RTE_ARCH_I686
- asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
-#else
- asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
-#endif
-#endif
-}
-
#define rte_io_mb() rte_mb()
#define rte_io_wmb() rte_compiler_barrier()
@@ -93,10 +75,19 @@ rte_smp_mb(void)
static __rte_always_inline void
rte_atomic_thread_fence(rte_memory_order memorder)
{
- if (memorder == rte_memory_order_seq_cst)
- rte_smp_mb();
- else
+ if (memorder == rte_memory_order_seq_cst) {
+#ifdef RTE_TOOLCHAIN_MSVC
+ _mm_mfence();
+#else
+#ifdef RTE_ARCH_I686
+ asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
+#else
+ asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
+#endif
+#endif
+ } else {
__rte_atomic_thread_fence(memorder);
+ }
}
#ifdef __cplusplus
--
2.53.0
^ permalink raw reply related
* [RFC 1/7] doc: update versions in deprecation file
From: Stephen Hemminger @ 2026-05-21 4:17 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
In-Reply-To: <20260521042043.1590536-1-stephen@networkplumber.org>
This document was mentioned 23.11 release and needs update
for upcoming 26.11.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/deprecation.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 35c9b4e06c..346c517623 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -7,8 +7,8 @@ ABI and API Deprecation
See the guidelines document for details of the :doc:`ABI policy
<../contributing/abi_policy>`.
-With DPDK 23.11, there will be a new major ABI version: 24.
-This means that during the development of 23.11,
+With DPDK 26.11, there will be a new major ABI version: 27.
+This means that during the development of 26.11,
new items may be added to structs or enums,
even if those additions involve an ABI compatibility breakage.
--
2.53.0
^ permalink raw reply related
* [RFC 0/7] prepare deprecation of rte_atomicNN_*() family
From: Stephen Hemminger @ 2026-05-21 4:17 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The goal is to land every deprecation currently listed in the release
notes by the 26.11 ABI bump. Working back from there: any function to
be removed in 26.11 needs to be marked __rte_deprecated by 26.07, and
all in-tree users converted off it before the marker patch goes in so
CI stays clean.
This series is the preparatory work for the rte_atomicNN_*() family
under that plan. It does not yet add the __rte_deprecated marker;
that's a separate follow-up once the remaining in-tree users are
converted. Other items on the deprecation list (VXLAN_GPE,
pipeline/table/port legacy API, the MAX enum fix, regexdev, pdump,
TM locks) will follow as their own series on the same timeline.
Patch 3 is the load-bearing change: the last lib/ caller of
rte_atomic32_cmpset() is converted, clearing the way.
Patch 7 drops RTE_FORCE_INTRINSICS entirely. With the option always on,
the asm implementations of atomics, spinlock and byteorder become dead
code. ~900 lines deleted; the patch most worth review attention.
This makes it easier to flag the rte_atomicNN as deprecated
since they are all in one place.
Patch 2 retires the rte_smp_*mb deprecation notice (open since 2021)
by reimplementing those APIs as wrappers over rte_atomic_thread_fence,
preserving the API for readability. Patches 5 and 6 convert and clean
up two driver users (bonding, nbl).
Patch 4 is a preparatory workaround for a pre-existing GCC bitfield
-Wmaybe-uninitialized false positive in net/zxdh, surfaced by the
improved compiler visibility after patch 7. Placed ahead of patch 7
to keep every commit bisectable.
Follow on patches will mechanically convert drivers.
If driver writer fixes it themselves; all the beter.
Stephen Hemminger (7):
doc: update versions in deprecation file
eal: reimplement rte_smp_*mb with rte_atomic_thread_fence
ring: use C11 atomic operations for MP/SP head/tail
net/zxdh: work around GCC bitfield uninit false positive
net/bonding: use stdatomic
net/nbl: remove unused rte_atomic16 field
config: use RTE_FORCE_INTRINSICS on all platforms
config/arm/meson.build | 1 -
config/loongarch/meson.build | 1 -
config/meson.build | 3 -
config/riscv/meson.build | 1 -
doc/guides/rel_notes/deprecation.rst | 12 +-
doc/guides/rel_notes/release_26_07.rst | 5 +
drivers/net/bonding/eth_bond_8023ad_private.h | 4 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 18 +-
drivers/net/nbl/nbl_hw/nbl_resource.h | 1 -
drivers/net/zxdh/zxdh_msg.c | 4 +-
lib/eal/arm/include/rte_atomic_32.h | 9 -
lib/eal/arm/include/rte_atomic_64.h | 9 -
lib/eal/arm/include/rte_byteorder.h | 3 -
lib/eal/arm/include/rte_spinlock.h | 3 -
lib/eal/include/generic/rte_atomic.h | 164 ++++----------
lib/eal/include/generic/rte_byteorder.h | 2 -
lib/eal/include/generic/rte_spinlock.h | 10 -
lib/eal/loongarch/include/rte_atomic.h | 9 -
lib/eal/loongarch/include/rte_spinlock.h | 3 -
lib/eal/ppc/include/rte_atomic.h | 179 ---------------
lib/eal/ppc/include/rte_byteorder.h | 13 --
lib/eal/ppc/include/rte_spinlock.h | 26 ---
lib/eal/riscv/include/rte_atomic.h | 9 -
lib/eal/riscv/include/rte_spinlock.h | 3 -
lib/eal/x86/include/rte_atomic.h | 205 +-----------------
lib/eal/x86/include/rte_atomic_32.h | 188 ----------------
lib/eal/x86/include/rte_atomic_64.h | 157 --------------
lib/eal/x86/include/rte_byteorder.h | 49 -----
lib/eal/x86/include/rte_spinlock.h | 49 -----
lib/ring/rte_ring_generic_pvt.h | 64 ++++--
30 files changed, 118 insertions(+), 1086 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH] net/ena: use C11 atomic operations in platform header
From: Stephen Hemminger @ 2026-05-21 4:07 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Shai Brandes, Evgeny Schemeilin, Ron Beider,
Amit Bernstein, Wajeeh Atrash
Convert the legacy rte_atomic32_t and rte_atomic32_{inc,dec,set,read}
macros to C11 stdatomic equivalents. This clears another user of the
rte_atomicNN_*() family ahead of its deprecation.
Memory ordering is kept at seq_cst, matching the implicit ordering of
the legacy API. The ena_com access patterns can be audited and orderings
tightened in a follow-up.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/ena/base/ena_plat_dpdk.h | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ena/base/ena_plat_dpdk.h b/drivers/net/ena/base/ena_plat_dpdk.h
index c84420de22..83b354d9da 100644
--- a/drivers/net/ena/base/ena_plat_dpdk.h
+++ b/drivers/net/ena/base/ena_plat_dpdk.h
@@ -40,7 +40,7 @@ typedef uint64_t dma_addr_t;
#endif
#define ENA_PRIu64 PRIu64
-#define ena_atomic32_t rte_atomic32_t
+typedef RTE_ATOMIC(int32_t) ena_atomic32_t;
#define ena_mem_handle_t const struct rte_memzone *
#define SZ_256 (256U)
@@ -267,10 +267,14 @@ ena_mem_alloc_coherent(struct rte_eth_dev_data *data, size_t size,
#define ENA_REG_READ32(bus, reg) \
__extension__ ({ (void)(bus); rte_read32_relaxed((reg)); })
-#define ATOMIC32_INC(i32_ptr) rte_atomic32_inc(i32_ptr)
-#define ATOMIC32_DEC(i32_ptr) rte_atomic32_dec(i32_ptr)
-#define ATOMIC32_SET(i32_ptr, val) rte_atomic32_set(i32_ptr, val)
-#define ATOMIC32_READ(i32_ptr) rte_atomic32_read(i32_ptr)
+#define ATOMIC32_INC(i32_ptr) \
+ rte_atomic_fetch_add_explicit((i32_ptr), 1, rte_memory_order_seq_cst)
+#define ATOMIC32_DEC(i32_ptr) \
+ rte_atomic_fetch_sub_explicit((i32_ptr), 1, rte_memory_order_seq_cst)
+#define ATOMIC32_SET(i32_ptr, val) \
+ rte_atomic_store_explicit((i32_ptr), (val), rte_memory_order_seq_cst)
+#define ATOMIC32_READ(i32_ptr) \
+ rte_atomic_load_explicit((i32_ptr), rte_memory_order_seq_cst)
#define msleep(x) rte_delay_us(x * 1000)
#define udelay(x) rte_delay_us(x)
--
2.53.0
^ permalink raw reply related
* [PATCH v4] ring: fix zero-copy burst API documentation
From: Zhiguang Jin @ 2026-05-21 3:00 UTC (permalink / raw)
To: Thomas Monjalon, Konstantin Ananyev, Wathsala Vithanage,
Dharmik Thakkar, Honnappa Nagarahalli
Cc: dev, Zhiguang Jin, stable
In-Reply-To: <20260519133853.889-1-jinzhiguang@kylinos.cn>
These are burst APIs relying on RTE_RING_QUEUE_VARIABLE behavior, they
operate on a best-effort basis and return the actual number of
objects processed (between 0 and n).
Update description to match implementation.
Fixes: 47bec9a5ca9f ("ring: add zero copy API")
Cc: stable@dpdk.org
Signed-off-by: Zhiguang Jin <jinzhiguang@kylinos.cn>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
---
Notes:
v4:
- The name in the .mailmap file has been corrected and placed in the correct location.
v3:
- Resend properly threaded to the v1 patch. (No code/text changes)
v2:
- Update description to match actual behavior per Maintainer's suggestion.
.mailmap | 1 +
lib/ring/rte_ring_peek_zc.h | 8 ++++----
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/.mailmap b/.mailmap
index 4d26d9c286..3172cb08e3 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1934,6 +1934,7 @@ Zhichao Zeng <zhichaox.zeng@intel.com>
Zhigang Hu <zhigang.hu@intel.com>
Zhigang Lu <zlu@ezchip.com>
Zhiguang He <hezhiguang3@huawei.com>
+Zhiguang Jin <jinzhiguang@kylinos.cn>
Zhihong Peng <zhihongx.peng@intel.com>
Zhihong Wang <wangzhihong.wzh@bytedance.com> <zhihong.wang@intel.com>
Zhike Wang <wangzhike@jd.com> <wangzk320@163.com>
diff --git a/lib/ring/rte_ring_peek_zc.h b/lib/ring/rte_ring_peek_zc.h
index 3254fe0481..43d6a53075 100644
--- a/lib/ring/rte_ring_peek_zc.h
+++ b/lib/ring/rte_ring_peek_zc.h
@@ -235,7 +235,7 @@ rte_ring_enqueue_zc_bulk_start(struct rte_ring *r, unsigned int n,
* If non-NULL, returns the amount of space in the ring after the
* reservation operation has finished.
* @return
- * The number of objects that can be enqueued, either 0 or n
+ * The actual number of objects that can be enqueued.
*/
static __rte_always_inline unsigned int
rte_ring_enqueue_zc_burst_elem_start(struct rte_ring *r, unsigned int esize,
@@ -265,7 +265,7 @@ rte_ring_enqueue_zc_burst_elem_start(struct rte_ring *r, unsigned int esize,
* If non-NULL, returns the amount of space in the ring after the
* reservation operation has finished.
* @return
- * The number of objects that can be enqueued, either 0 or n.
+ * The actual number of objects that can be enqueued.
*/
static __rte_always_inline unsigned int
rte_ring_enqueue_zc_burst_start(struct rte_ring *r, unsigned int n,
@@ -442,7 +442,7 @@ rte_ring_dequeue_zc_bulk_start(struct rte_ring *r, unsigned int n,
* If non-NULL, returns the number of remaining ring entries after the
* dequeue has finished.
* @return
- * The number of objects that can be dequeued, either 0 or n.
+ * The actual number of objects that can be dequeued.
*/
static __rte_always_inline unsigned int
rte_ring_dequeue_zc_burst_elem_start(struct rte_ring *r, unsigned int esize,
@@ -471,7 +471,7 @@ rte_ring_dequeue_zc_burst_elem_start(struct rte_ring *r, unsigned int esize,
* If non-NULL, returns the number of remaining ring entries after the
* dequeue has finished.
* @return
- * The number of objects that can be dequeued, either 0 or n.
+ * The actual number of objects that can be dequeued.
*/
static __rte_always_inline unsigned int
rte_ring_dequeue_zc_burst_start(struct rte_ring *r, unsigned int n,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] ring: fix zero-copy burst API documentation
From: jinzhiguang @ 2026-05-21 2:54 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Konstantin Ananyev, Wathsala Vithanage, Dharmik Thakkar,
Honnappa Nagarahalli, dev, stable
In-Reply-To: <D6Rbi5-MSBSppW6LoqeJTg@monjalon.net>
On 2026/5/20 16:59:42, Thomas Monjalon wrote:
> 19/05/2026 15:38, jinzhiguang:
>> --- a/.mailmap
>> +++ b/.mailmap
>> @@ -756,6 +756,7 @@ Jing Chen <jing.d.chen@intel.com>
>> Jingguo Fu <jingguox.fu@intel.com>
>> Jingjing Wu <jingjing.wu@intel.com>
>> Jingzhao Ni <jingzhao.ni@arm.com>
>> +jinzhiguang <jinzhiguang@kylinos.cn>
> Maybe you want to insert a space? What is your first name and family name?
> Please use capital letters where appropriate.
Thank you for the review! I will update the .mailmap in the v4 version
of the patch.
^ permalink raw reply
* Re: [PATCH v2 19/23] dma/idxd: remove specific bus type
From: Bruce Richardson @ 2026-05-20 17:20 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stephen, Kevin Laatz
In-Reply-To: <20260506155201.2709810-20-david.marchand@redhat.com>
On Wed, May 06, 2026 at 05:51:51PM +0200, David Marchand wrote:
> There is nothing that requires a specific bus type.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
This patch exposes an underlying issue with the DSA driver. When applied,
attempting to probe the workqueues gives the output:
"EAL: Device wq0.0 is already probed"
For each device. This is because the device is not zeroed in the scan
function, leaving a non-NULL driver pointer. See inline below.
/Bruce
> ---
> drivers/dma/idxd/idxd_bus.c | 38 ++++++++++++++-----------------------
> 1 file changed, 14 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/dma/idxd/idxd_bus.c b/drivers/dma/idxd/idxd_bus.c
> index 93bde69ff9..daf5f48ac1 100644
> --- a/drivers/dma/idxd/idxd_bus.c
> +++ b/drivers/dma/idxd/idxd_bus.c
> @@ -41,34 +41,24 @@ struct rte_dsa_device {
> };
>
> /* forward prototypes */
> -struct dsa_bus;
> static int dsa_scan(void);
> static bool dsa_match(const struct rte_driver *drv, const struct rte_device *dev);
> static int dsa_probe_device(struct rte_driver *drv, struct rte_device *dev);
> static enum rte_iova_mode dsa_get_iommu_class(void);
> static int dsa_addr_parse(const char *name, void *addr);
>
> -/**
> - * Structure describing the DSA bus
> - */
> -struct dsa_bus {
> - struct rte_bus bus; /**< Inherit the generic class */
> - struct rte_driver driver; /**< Driver struct for devices to point to */
> +struct rte_bus dsa_bus = {
> + .scan = dsa_scan,
> + .probe = rte_bus_generic_probe,
> + .match = dsa_match,
> + .probe_device = dsa_probe_device,
> + .find_device = rte_bus_generic_find_device,
> + .get_iommu_class = dsa_get_iommu_class,
> + .parse = dsa_addr_parse,
> };
>
> -struct dsa_bus dsa_bus = {
> - .bus = {
> - .scan = dsa_scan,
> - .probe = rte_bus_generic_probe,
> - .match = dsa_match,
> - .probe_device = dsa_probe_device,
> - .find_device = rte_bus_generic_find_device,
> - .get_iommu_class = dsa_get_iommu_class,
> - .parse = dsa_addr_parse,
> - },
> - .driver = {
> - .name = "dmadev_idxd",
> - },
> +struct rte_driver dsa_driver = {
> + .name = "dmadev_idxd",
> };
>
> static inline const char *
> @@ -267,7 +257,7 @@ static bool dsa_match(const struct rte_driver *drv, const struct rte_device *dev
> {
> const struct rte_dsa_device *dsa_dev = RTE_BUS_DEVICE(dev, *dsa_dev);
>
> - if (drv == &dsa_bus.driver) {
> + if (drv == &dsa_driver) {
> char type[64], name[64];
>
> if (read_wq_string(dsa_dev, "type", type, sizeof(type)) >= 0 &&
> @@ -319,7 +309,7 @@ dsa_scan(void)
> continue;
> }
> strlcpy(dev->wq_name, wq->d_name, sizeof(dev->wq_name));
> - rte_bus_add_device(&dsa_bus.bus, &dev->device);
> + rte_bus_add_device(&dsa_bus, &dev->device);
The issue with the driver is here. Before the strlcpy, and the previous
dsa_addr_parse() call, we just need to add:
memset(dev, 0, sizeof(*dev));
Since malloc does not zero the memory. [Alternatively, we can change malloc
to a zeroing equivalent].
Do you want me to do a separate patch to fix this, or roll the fix change
into this patch?
> devcount++;
>
> read_device_int(dev, "numa_node", &numa_node);
> @@ -357,8 +347,8 @@ dsa_addr_parse(const char *name, void *addr)
> return 0;
> }
>
> -RTE_REGISTER_BUS(dsa, dsa_bus.bus);
> +RTE_REGISTER_BUS(dsa, dsa_bus);
> RTE_INIT(dsa_bus_init)
> {
> - rte_bus_add_driver(&dsa_bus.bus, &dsa_bus.driver);
> + rte_bus_add_driver(&dsa_bus, &dsa_driver);
> }
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH] eal: fix data race in hugepage prefault
From: Stephen Hemminger @ 2026-05-20 17:08 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, stable, Michal Sieron, Thomas Monjalon,
Anatoly Burakov, Bruce Richardson
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
The prefault step in alloc_seg() reads a value from the hugepage and
writes it back unchanged to force the kernel to commit the backing
page. The read and write were not atomic, which races with concurrent
access to the same physical page from a secondary process attaching
to the hugetlbfs-backed mapping during rte_eal_init().
Replace the non-atomic load+store with a single atomic fetch-or of
zero. This touches the page with an atomic read-modify-write without
changing its contents, eliminating the race while preserving the
original intent of forcing a write fault.
Fixes: 0f1631be24bd ("mem: fix page fault trigger")
Cc: stable@dpdk.org
Reported-by: Michal Sieron <michal.sieron@nokia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
.mailmap | 1 +
lib/eal/linux/eal_memalloc.c | 7 ++++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/.mailmap b/.mailmap
index 4d26d9c286..07c49eb32f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1086,6 +1086,7 @@ Michal Mazurek <maz@semihalf.com>
Michal Michalik <michal.michalik@intel.com>
Michal Nowak <michal2.nowak@intel.com>
Michal Schmidt <mschmidt@redhat.com>
+Michal Sieron <michal.sieron@nokia.com>
Michal Swiatkowski <michal.swiatkowski@intel.com>
Michal Wilczynski <michal.wilczynski@intel.com>
Michał Mirosław <michal.miroslaw@atendesoftware.pl> <mirq-linux@rere.qmqm.pl>
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index a39bc31c7b..e73a0c11a6 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -25,6 +25,7 @@
#include <linux/falloc.h>
#include <linux/mman.h> /* for hugetlb-related mmap flags */
+#include <rte_atomic.h>
#include <rte_common.h>
#include <rte_log.h>
#include <rte_eal.h>
@@ -597,10 +598,10 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
/* we need to trigger a write to the page to enforce page fault and
* ensure that page is accessible to us, but we can't overwrite value
- * that is already there, so read the old value, and write itback.
- * kernel populates the page with zeroes initially.
+ * that is already there.
+ * Use an atomic OR with zero to touch the page without changing its contents.
*/
- *(volatile int *)addr = *(volatile int *)addr;
+ (void)rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
iova = rte_mem_virt2iova(addr);
if (iova == RTE_BAD_PHYS_ADDR) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Stephen Hemminger @ 2026-05-20 17:07 UTC (permalink / raw)
To: Michal Sieron; +Cc: dev
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
On Wed, 20 May 2026 14:57:56 +0200
Michal Sieron <michal.sieron@nokia.com> wrote:
> In rare cases, when a secondary process calls rte_eal_init() it can
> cause a data race during page prefaulting in alloc_seg().
>
> An atomic compare-exchange in a loop should eliminate the data race.
>
> Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
> ---
AI had good suggestion when reviewing this.
Your version is still racy (on the read side).
A simple non-racy, and no loop version would be:
rte_atomic_fetch_or_explicit((int *)addr, 0, rte_memory_order_relaxed);
^ permalink raw reply
* Re: [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Stephen Hemminger @ 2026-05-20 16:47 UTC (permalink / raw)
To: Michal Sieron; +Cc: dev
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
On Wed, 20 May 2026 14:57:56 +0200
Michal Sieron <michal.sieron@nokia.com> wrote:
> In rare cases, when a secondary process calls rte_eal_init() it can
> cause a data race during page prefaulting in alloc_seg().
>
> An atomic compare-exchange in a loop should eliminate the data race.
>
> Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
> ---
Build fails. Fix and resubmit.
Looks like you did this against older version of DPDK before stdatomic.
FAILED: [code=1] lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o
ccache clang -Ilib/librte_eal.a.p -Ilib -I../lib -Ilib/eal/common -I../lib/eal/common -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include -I../kernel/linux -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log -Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/argparse -I../lib/argparse -Xclang -fcolor-diagnostics -fsanitize=undefined -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -include rte_config.h -Wvla -Wcast-qual -Wcomma -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=corei7 -mrtm -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API '-DABI_VERSION="26.2"' -DRTE_EAL_PTHREAD_ATTR_SETAFFINITY_NP -DRTE_LOG_DEFAULT_LOGTYPE=lib.eal -DRTE_ANNOTATE_LOCKS -Wthread-safety -MD -MQ lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o -MF lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o.d -o lib/librte_eal.a.p/eal_linux_eal_memalloc.c.o -c ../lib/eal/linux/eal_memalloc.c
../lib/eal/linux/eal_memalloc.c:605:10: error: implicit declaration of function 'rte_atomic_compare_exchange_strong' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
while (!rte_atomic_compare_exchange_strong((volatile int *)addr, &snapshot, snapshot))
^
../lib/eal/linux/eal_memalloc.c:605:10: note: did you mean '__atomic_compare_exchange_n'?
../lib/eal/include/generic/rte_rwlock.h:189:6: note: '__atomic_compare_exchange_n' declared here
rte_atomic_compare_exchange_weak_explicit(&rwl->cnt, &x, x + RTE_RWLOCK_WRITE,
^
../lib/eal/include/rte_stdatomic.h:151:2: note: expanded from macro 'rte_atomic_compare_exchange_weak_explicit'
__atomic_compare_exchange_n(ptr, expected, desired, 1, \
^
1 error generated.
^ permalink raw reply
* Re: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Stephen Hemminger @ 2026-05-20 16:45 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
In-Reply-To: <ag1me_1XSByq3p9V@bricha3-mobl1.ger.corp.intel.com>
On Wed, 20 May 2026 08:44:59 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Tue, May 19, 2026 at 12:43:32PM -0700, Stephen Hemminger wrote:
> > On Tue, 19 May 2026 16:05:57 +0000
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > > This RFC proposed to replace all instances of rte_memcpy in Intel
> > > (and former-Intel) net drivers with just regular memcpy. This is
> > > done on the basis that the memcpy use is not datapath, but is used
> > > for flow configuration, virt-channel (to firmware or PF) messaging
> > > and other control path functions.
> >
> > Makes sense. You might also want to look for where structure
> > assignment can be used instead of memcpy. Keeping data types
> > is a good thing.
>
> Yes, it would be nice to use in places. However, it's not a mechanical
> change so I've not taken the time to do the analysis. Just a quick set of
> sed replacements for this RFC.
>
> /Bruce
There is a coccinelle script already to do this.
It is slow but does find things.
There doesn't seem to find any matches even after this patchset
^ permalink raw reply
* Re: [PATCH] net/ice: improve log messages for DDP loading
From: Bruce Richardson @ 2026-05-20 15:52 UTC (permalink / raw)
To: David Marchand; +Cc: dev, patrick.mahan, Anatoly Burakov
In-Reply-To: <20260516101942.443871-1-david.marchand@redhat.com>
On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote:
> Some nics may not provide a serial number (PCI capability
> RTE_PCI_EXT_CAP_ID_DSN).
>
> This results in a confusing ERROR log:
> ICE_INIT: ice_dev_init(): Failed to read device serial number
>
> This is confusing as DDP loading does *not* require the serial number to
> be present for the port to be functional afterwards.
>
> Besides, after trying various path, if the default DDP is not present on
> the runtime system, the port initialisation ends up with a vague error:
> ICE_INIT: ice_load_pkg(): failed to search file path
>
> Improve the situation with adjusting the log level when reading the
> SN fails, then add more debug context to DDP file loading and end up
> with a ERROR log mentioning the expected file.
>
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/updates/intel/ice/ddp/ice.pkg
> ICE_INIT: ice_firmware_read(): Cannot read DDP file
> /lib/firmware/intel/ice/ddp/ice.pkg
> ICE_INIT: ice_load_pkg(): Failed to load default DDP package
> /lib/firmware/intel/ice/ddp/ice.pkg
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [PATCH] net/ice: improve log messages for DDP loading
From: Bruce Richardson @ 2026-05-20 15:52 UTC (permalink / raw)
To: David Marchand; +Cc: dev, patrick.mahan, Anatoly Burakov
In-Reply-To: <CAJFAV8yLBFGVqOvfQ4SEZmy61g7xR4vrra7vyxG_NCc=4y1O7g@mail.gmail.com>
On Wed, May 20, 2026 at 05:44:14PM +0200, David Marchand wrote:
> On Tue, 19 May 2026 at 19:58, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote:
> > > Some nics may not provide a serial number (PCI capability
> > > RTE_PCI_EXT_CAP_ID_DSN).
> > >
> > > This results in a confusing ERROR log:
> > > ICE_INIT: ice_dev_init(): Failed to read device serial number
> > >
> > > This is confusing as DDP loading does *not* require the serial number to
> > > be present for the port to be functional afterwards.
> > >
> > > Besides, after trying various path, if the default DDP is not present on
> > > the runtime system, the port initialisation ends up with a vague error:
> > > ICE_INIT: ice_load_pkg(): failed to search file path
> > >
> > > Improve the situation with adjusting the log level when reading the
> > > SN fails, then add more debug context to DDP file loading and end up
> > > with a ERROR log mentioning the expected file.
> > >
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/updates/intel/ice/ddp/ice.pkg
> > > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > > /lib/firmware/intel/ice/ddp/ice.pkg
> > > ICE_INIT: ice_load_pkg(): Failed to load default DDP package
> > > /lib/firmware/intel/ice/ddp/ice.pkg
> > >
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > ---
> > > drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++----------
> > > 1 file changed, 21 insertions(+), 10 deletions(-)
> > >
> > On top of the changes made in this patch, how about something like the
> > below to extend things?
> >
> > Rather than just debug logging the failed paths, we change the debug logs
> > to always log each load attempt. We also record the path as it's attempted,
> > and then on failure to load any path we use that record to print out an
> > error message for each failure, so the user can see in the error logs ALL
> > the failed paths, rather than having to re-run the app at debug level to
> > find them.
> >
> > WDYT?
>
> That's a lot of code for something that is usually detected right at
> the first installation/run of your DPDK application.
> When you are at this point, restarting testpmd with the right debug
> level is the usual way.
>
> But let's say you can't restart your application, log levels can be
> changed dynamically (possible with testpmd, grout and OVS)
> before/after trying to probe the E810 device.
>
Yes, true. Probably not worth the effort at this point.
/Bruce
^ permalink raw reply
* Re: [PATCH] net/ice: improve log messages for DDP loading
From: David Marchand @ 2026-05-20 15:44 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, patrick.mahan, Anatoly Burakov
In-Reply-To: <agykrWAcEnOBZvY-@bricha3-mobl1.ger.corp.intel.com>
On Tue, 19 May 2026 at 19:58, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Sat, May 16, 2026 at 12:19:41PM +0200, David Marchand wrote:
> > Some nics may not provide a serial number (PCI capability
> > RTE_PCI_EXT_CAP_ID_DSN).
> >
> > This results in a confusing ERROR log:
> > ICE_INIT: ice_dev_init(): Failed to read device serial number
> >
> > This is confusing as DDP loading does *not* require the serial number to
> > be present for the port to be functional afterwards.
> >
> > Besides, after trying various path, if the default DDP is not present on
> > the runtime system, the port initialisation ends up with a vague error:
> > ICE_INIT: ice_load_pkg(): failed to search file path
> >
> > Improve the situation with adjusting the log level when reading the
> > SN fails, then add more debug context to DDP file loading and end up
> > with a ERROR log mentioning the expected file.
> >
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/updates/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/intel/ice/ddp/ice-b49691ffffe6e69c.pkg
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/updates/intel/ice/ddp/ice.pkg
> > ICE_INIT: ice_firmware_read(): Cannot read DDP file
> > /lib/firmware/intel/ice/ddp/ice.pkg
> > ICE_INIT: ice_load_pkg(): Failed to load default DDP package
> > /lib/firmware/intel/ice/ddp/ice.pkg
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > drivers/net/intel/ice/ice_ethdev.c | 31 ++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> On top of the changes made in this patch, how about something like the
> below to extend things?
>
> Rather than just debug logging the failed paths, we change the debug logs
> to always log each load attempt. We also record the path as it's attempted,
> and then on failure to load any path we use that record to print out an
> error message for each failure, so the user can see in the error logs ALL
> the failed paths, rather than having to re-run the app at debug level to
> find them.
>
> WDYT?
That's a lot of code for something that is usually detected right at
the first installation/run of your DPDK application.
When you are at this point, restarting testpmd with the right debug
level is the usual way.
But let's say you can't restart your application, log levels can be
changed dynamically (possible with testpmd, grout and OVS)
before/after trying to probe the E810 device.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v19 00/11]net/sxe2: fix logic errors and address feedback
From: Stephen Hemminger @ 2026-05-20 15:38 UTC (permalink / raw)
To: liujie5; +Cc: dev
In-Reply-To: <20260520021809.4019054-1-liujie5@linkdatatechnology.com>
On Wed, 20 May 2026 10:17:58 +0800
liujie5@linkdatatechnology.com wrote:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set addresses the feedback received on the v10 and v18
> submissions for the sxe2 PMD. The primary focus is on fixing vector
> path selection, ensuring memory safety during mbuf initialization,
> and cleaning up redundant logic in the configuration functions.
>
> v19 Changes:
> - Fixed vector Rx burst function being overwritten by scalar selection.
> - Refactored Rx/Tx mode set functions to seed flags from caps first,
> eliminating tautological checks.
> - Added memset for mbuf_def in vector init to avoid uninitialized reads.
> - Converted pci_map_addr_info to designated initializers.
> - Removed dead Windows-only code in meson.build.
> - Added NULL checks for mbuf free for driver-wide consistency.
> - Updated burst_mode_get to accurately report AVX paths.
> - Adjusted SXE2_ETH_OVERHEAD to match actual VLAN capabilities.
>
> Jie Liu (11):
> mailmap: add Jie Liu
> doc: add sxe2 guide and release notes
> common/sxe2: add sxe2 basic structures
> drivers: add base driver skeleton
> drivers: add base driver probe skeleton
> drivers: support PCI BAR mapping
> common/sxe2: add ioctl interface for DMA map and unmap
> net/sxe2: support queue setup and control
> drivers: add data path for Rx and Tx
> net/sxe2: add vectorized Rx and Tx
> net/sxe2: implement Tx done cleanup
>
> .mailmap | 1 +
> doc/guides/nics/features/sxe2.ini | 23 +
> doc/guides/nics/index.rst | 1 +
> doc/guides/nics/sxe2.rst | 34 +
> doc/guides/rel_notes/release_26_07.rst | 4 +
> drivers/common/sxe2/meson.build | 15 +
> drivers/common/sxe2/sxe2_common.c | 683 +++++++++++++
> drivers/common/sxe2/sxe2_common.h | 85 ++
> drivers/common/sxe2/sxe2_common_log.h | 81 ++
> drivers/common/sxe2/sxe2_host_regs.h | 707 +++++++++++++
> drivers/common/sxe2/sxe2_internal_ver.h | 33 +
> drivers/common/sxe2/sxe2_ioctl_chnl.c | 325 ++++++
> drivers/common/sxe2/sxe2_ioctl_chnl.h | 130 +++
> drivers/common/sxe2/sxe2_ioctl_chnl_func.h | 62 ++
> drivers/common/sxe2/sxe2_osal.h | 153 +++
> drivers/meson.build | 1 +
> drivers/net/meson.build | 1 +
> drivers/net/sxe2/meson.build | 32 +
> drivers/net/sxe2/sxe2_cmd_chnl.c | 323 ++++++
> drivers/net/sxe2/sxe2_cmd_chnl.h | 37 +
> drivers/net/sxe2/sxe2_drv_cmd.h | 388 ++++++++
> drivers/net/sxe2/sxe2_ethdev.c | 968 ++++++++++++++++++
> drivers/net/sxe2/sxe2_ethdev.h | 318 ++++++
> drivers/net/sxe2/sxe2_irq.h | 48 +
> drivers/net/sxe2/sxe2_queue.c | 66 ++
> drivers/net/sxe2/sxe2_queue.h | 195 ++++
> drivers/net/sxe2/sxe2_rx.c | 554 +++++++++++
> drivers/net/sxe2/sxe2_rx.h | 32 +
> drivers/net/sxe2/sxe2_tx.c | 420 ++++++++
> drivers/net/sxe2/sxe2_tx.h | 32 +
> drivers/net/sxe2/sxe2_txrx.c | 352 +++++++
> drivers/net/sxe2/sxe2_txrx.h | 23 +
> drivers/net/sxe2/sxe2_txrx_common.h | 540 ++++++++++
> drivers/net/sxe2/sxe2_txrx_poll.c | 1044 ++++++++++++++++++++
> drivers/net/sxe2/sxe2_txrx_poll.h | 20 +
> drivers/net/sxe2/sxe2_txrx_vec.c | 201 ++++
> drivers/net/sxe2/sxe2_txrx_vec.h | 63 ++
> drivers/net/sxe2/sxe2_txrx_vec_common.h | 235 +++++
> drivers/net/sxe2/sxe2_txrx_vec_sse.c | 549 ++++++++++
> drivers/net/sxe2/sxe2_vsi.c | 214 ++++
> drivers/net/sxe2/sxe2_vsi.h | 204 ++++
> 41 files changed, 9197 insertions(+)
> create mode 100644 doc/guides/nics/features/sxe2.ini
> create mode 100644 doc/guides/nics/sxe2.rst
> create mode 100644 drivers/common/sxe2/meson.build
> create mode 100644 drivers/common/sxe2/sxe2_common.c
> create mode 100644 drivers/common/sxe2/sxe2_common.h
> create mode 100644 drivers/common/sxe2/sxe2_common_log.h
> create mode 100644 drivers/common/sxe2/sxe2_host_regs.h
> create mode 100644 drivers/common/sxe2/sxe2_internal_ver.h
> create mode 100644 drivers/common/sxe2/sxe2_ioctl_chnl.c
> create mode 100644 drivers/common/sxe2/sxe2_ioctl_chnl.h
> create mode 100644 drivers/common/sxe2/sxe2_ioctl_chnl_func.h
> create mode 100644 drivers/common/sxe2/sxe2_osal.h
> create mode 100644 drivers/net/sxe2/meson.build
> create mode 100644 drivers/net/sxe2/sxe2_cmd_chnl.c
> create mode 100644 drivers/net/sxe2/sxe2_cmd_chnl.h
> create mode 100644 drivers/net/sxe2/sxe2_drv_cmd.h
> create mode 100644 drivers/net/sxe2/sxe2_ethdev.c
> create mode 100644 drivers/net/sxe2/sxe2_ethdev.h
> create mode 100644 drivers/net/sxe2/sxe2_irq.h
> create mode 100644 drivers/net/sxe2/sxe2_queue.c
> create mode 100644 drivers/net/sxe2/sxe2_queue.h
> create mode 100644 drivers/net/sxe2/sxe2_rx.c
> create mode 100644 drivers/net/sxe2/sxe2_rx.h
> create mode 100644 drivers/net/sxe2/sxe2_tx.c
> create mode 100644 drivers/net/sxe2/sxe2_tx.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_common.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_poll.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx_poll.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_common.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_sse.c
> create mode 100644 drivers/net/sxe2/sxe2_vsi.c
> create mode 100644 drivers/net/sxe2/sxe2_vsi.h
>
Applied to next-net with minor merge fixup to release note
^ permalink raw reply
* Re: [PATCH v2] net/ice: fix TM node ID validation against configured queues
From: Bruce Richardson @ 2026-05-20 15:24 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev, stable
In-Reply-To: <20260520150717.365942-1-ciara.loftus@intel.com>
On Wed, May 20, 2026 at 03:07:16PM +0000, Ciara Loftus wrote:
> The leaf node ID boundary is checked against the compile-time constant
> `RTE_MAX_QUEUES_PER_PORT` (1024) rather than the number of configured Tx
> queues. The rte_tm specification reserves IDs 0 to N-1 for leaf nodes
> where N is the configured queue count, so using the constant produces
> wrong results whenever N is less than 1024.
>
> Fix by using `nb_tx_queues` as the boundary when queues have been
> configured, falling back to `RTE_MAX_QUEUES_PER_PORT` when `nb_tx_queues`
> is zero. The zero case arises when the TM hierarchy is built before port
> queue configuration, which is required to support queue counts beyond
> the hardware default.
>
> Also add an explicit check in the non-leaf validation path that rejects
> IDs in the leaf-reserved range. This condition can be triggered two ways:
> adding a leaf node before its parent chain is complete (the node resolves
> to a non-leaf level), or assigning a leaf-range ID to a node intended
> as non-leaf.
>
> Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")
> Cc: stable@dpdk.org
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* [PATCH v2] net/ice: fix TM node ID validation against configured queues
From: Ciara Loftus @ 2026-05-20 15:07 UTC (permalink / raw)
To: dev; +Cc: Ciara Loftus, stable
In-Reply-To: <20260505123157.1387791-1-ciara.loftus@intel.com>
The leaf node ID boundary is checked against the compile-time constant
`RTE_MAX_QUEUES_PER_PORT` (1024) rather than the number of configured Tx
queues. The rte_tm specification reserves IDs 0 to N-1 for leaf nodes
where N is the configured queue count, so using the constant produces
wrong results whenever N is less than 1024.
Fix by using `nb_tx_queues` as the boundary when queues have been
configured, falling back to `RTE_MAX_QUEUES_PER_PORT` when `nb_tx_queues`
is zero. The zero case arises when the TM hierarchy is built before port
queue configuration, which is required to support queue counts beyond
the hardware default.
Also add an explicit check in the non-leaf validation path that rejects
IDs in the leaf-reserved range. This condition can be triggered two ways:
adding a leaf node before its parent chain is complete (the node resolves
to a non-leaf level), or assigning a leaf-range ID to a node intended
as non-leaf.
Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")
Cc: stable@dpdk.org
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
drivers/net/intel/ice/ice_tm.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/intel/ice/ice_tm.c b/drivers/net/intel/ice/ice_tm.c
index 015a827d7a..bf2ac117b1 100644
--- a/drivers/net/intel/ice/ice_tm.c
+++ b/drivers/net/intel/ice/ice_tm.c
@@ -88,8 +88,11 @@ ice_node_param_check(uint32_t node_id,
uint32_t priority, uint32_t weight,
const struct rte_tm_node_params *params,
bool is_leaf,
+ uint16_t nb_txq,
struct rte_tm_error *error)
{
+ uint32_t max_leaf_id = (nb_txq != 0) ? nb_txq : RTE_MAX_QUEUES_PER_PORT;
+
/* checked all the unsupported parameter */
if (node_id == RTE_TM_NODE_ID_NULL) {
error->type = RTE_TM_ERROR_TYPE_NODE_ID;
@@ -123,6 +126,11 @@ ice_node_param_check(uint32_t node_id,
/* for non-leaf node */
if (!is_leaf) {
+ if (node_id < max_leaf_id) {
+ error->type = RTE_TM_ERROR_TYPE_NODE_ID;
+ error->message = "node ID is reserved for leaf nodes";
+ return -EINVAL;
+ }
if (params->nonleaf.wfq_weight_mode) {
error->type =
RTE_TM_ERROR_TYPE_NODE_PARAMS_WFQ_WEIGHT_MODE;
@@ -146,7 +154,7 @@ ice_node_param_check(uint32_t node_id,
}
/* for leaf node */
- if (node_id >= RTE_MAX_QUEUES_PER_PORT) {
+ if (node_id >= max_leaf_id) {
error->type = RTE_TM_ERROR_TYPE_NODE_ID;
error->message = "Node ID out of range for a leaf node.";
return -EINVAL;
@@ -440,7 +448,8 @@ ice_tm_node_add(struct rte_eth_dev *dev, uint32_t node_id,
return -EINVAL;
}
- ret = ice_node_param_check(node_id, priority, weight, params, false, error);
+ ret = ice_node_param_check(node_id, priority, weight, params, false,
+ dev->data->nb_tx_queues, error);
if (ret)
return ret;
@@ -481,7 +490,8 @@ ice_tm_node_add(struct rte_eth_dev *dev, uint32_t node_id,
}
ret = ice_node_param_check(node_id, priority, weight,
- params, level_id == ice_get_leaf_level(pf), error);
+ params, level_id == ice_get_leaf_level(pf),
+ dev->data->nb_tx_queues, error);
if (ret)
return ret;
--
2.43.0
^ permalink raw reply related
* Re: [V1 1/1] net/hinic3: Add VXLAN TSO function
From: Stephen Hemminger @ 2026-05-20 15:06 UTC (permalink / raw)
To: Feifei Wang; +Cc: dev, Feifei Wang
In-Reply-To: <20260520065817.931-2-wff_light@vip.163.com>
On Wed, 20 May 2026 14:58:15 +0800
Feifei Wang <wff_light@vip.163.com> wrote:
> The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN TSO function
>
> Signed-off-by: Feifei Wang <wangfeifei40@huawei.com>
> ---
You need to do more than just advertise the capability to get the driver
to actually work right.
AI explanation:
Error: VXLAN TSO is advertised unconditionally but the underlying hardware
feature is not. The patch adds RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO to the
unconditional tx_offload_capa assignment in hinic3_dev_infos_get(), but
the Tx path in drivers/net/hinic3/hinic3_tx.c:306-313 rejects every VXLAN
tunnel mbuf when the hardware does not have NIC_F_VXLAN_OFFLOAD:
^ permalink raw reply
* RE: [PATCH] net/ice: fix TM node ID validation against configured queues
From: Loftus, Ciara @ 2026-05-20 15:03 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev@dpdk.org, stable@dpdk.org
In-Reply-To: <agx6kiQyvHZJ96ob@bricha3-mobl1.ger.corp.intel.com>
> >
> > Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")
>
> I think this fix will cause other issues when we want to use large numbers
> of queues. From the commit log for 715d449a965b:
>
> "If the HW/firmware allows it, allow creating up to 2k child
> nodes per scheduler node. Also expand the number of supported layers to
> the max available, rather than always just having 3 layers. One
> restriction on this change is that the topology needs to be configured
> and enabled before port queue setup"
>
> The last part is significant - the number of configured queues must be
> supported by a scheduler hierarchy with enough nodes at the next,
> queue-group level. Therefore, before configuring large numbers of queues we
> need to configure a non-default hierarchy. Therefore, when running this
> check the value of nb_txq is not known, which is why the original patch
> changed the check to RTE_MAX_QUEUES_PER_PORT.
>
> However, you correctly point out in this fix, that that is not according to
> the spec for rte_tm. Therefore, I suggest changing the check, if possible:
>
> * if nb_txq == 0 (i.e. no queues configured yet), then keep as-is with
> MAX_QUEUES
> * for cases where nb_txq != 0, then use nb_txq.
>
> Does that seem sensible, or any better alternatives you can see?
That makes sense Bruce, I cannot think of a better alternative.
I'll submit a v2 with your suggestion in place.
Thanks,
Ciara
>
> /Bruce
>
>
^ permalink raw reply
* Re: [PATCH 1/2] dmadev: include device name in telemetry list output
From: Stephen Hemminger @ 2026-05-20 15:03 UTC (permalink / raw)
To: Chengwen Feng; +Cc: thomas, dev
In-Reply-To: <20260520035641.50555-2-fengchengwen@huawei.com>
On Wed, 20 May 2026 11:56:40 +0800
Chengwen Feng <fengchengwen@huawei.com> wrote:
> After this commit:
> {
> "/dmadev/list": [
> "0 hisi_sec2-0-dma0",
> "1 hisi_sec2-0-dma1"
> ]
> }
That is awkward JSON. Better to not have the 0 and 1 prefixes.
Typical usage will read JSON in python and array index would
be implicit.
^ permalink raw reply
* Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names
From: Bruce Richardson @ 2026-05-20 14:58 UTC (permalink / raw)
To: Morten Brørup; +Cc: Chengwen Feng, thomas, stephen, dev, andrew.rybchenko
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65887@smartserver.smartshare.dk>
On Wed, May 20, 2026 at 03:29:36PM +0200, Morten Brørup wrote:
> > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > Sent: Wednesday, 20 May 2026 11.38
> >
> > Add /ethdev/list_names telemetry endpoint which returns a dictionary
> > keyed by port ID with device name as the value, so users can
> > identify ports by name directly from the telemetry output.
> >
> > Original /ethdev/list output:
> > {"/ethdev/list": [0, 1]}
> >
> > New /ethdev/list_names output:
> > {"/ethdev/list_names": {"0": "0000:7d:00.0",
> > "1": "0000:7d:00.1"}}
> >
>
> <rant>
>
> Unfortunately, the telemetry protocol in DPDK is not using a common design, but takes parameters specific to each path.
> It should have used OData or something similar, to standardize listing, filtering, etc.
> Then we could have queried this like:
> /ethdev/info?$select=port_id,name
If you are up for implementing something like that, it should be possible
to have syntax like the above work alongside our existing syntax too.
The current telemetry scheme was set up with the overarching objective
being simplicity.
> And return something like:
> [
> {
> "port_id": 0,
> "name": "0000:7d:00.0"
> },
> {
> "port_id": 1,
> "name": "0000:7d:00.1"
> }
> ]
> or:
> [
> {
> 0,
> "0000:7d:00.0"
> },
> {
> 1,
> "0000:7d:00.1"
> }
> ]
>
> But now we are stuck with what we have.
>
> </rant>
>
> So /etdev/list_names is OK.
>
> I'm not really familiar with the DPDK telemetry, so I wonder if indexed arrays are normally returned as an object, like in this patch?
>
> I would have expected a list function (such as list_names) to return an array.
> Either a simple list:
> {
> "/ethdev/list_names":
> [
> "0000:7d:00.0",
> "0000:7d:00.1"
> ]
> }
>
I think it would prefer this, but it does get a bit harder to read with a
long list.
> Or a list of objects:
> {
> "/ethdev/list_names":
> [
> {
> "port_id": 0,
> "name": "0000:7d:00.0"
> },
> {
> "port_id": 1,
> "name": "0000:7d:00.1"
> }
> ]
> }
>
Agree that this also would be slightly better.
However, a *completely* different approach would be to instead solve this
issue by adding additional functionality to the interactive telemetry
script itself. After all, the data for the list of names of ethdevs is
already available from the telemetry endpoints already present in DPDK. All
we need to do is to extend the python script to have "virtual endpoints" if
you will, which do the necessary queries in the background and then present
the data to the user. I think that would be a cleaner approach to things
like this, rather than always adding more C code.
/Bruce
^ permalink raw reply
* Re: [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Stephen Hemminger @ 2026-05-20 14:57 UTC (permalink / raw)
To: Michal Sieron; +Cc: dev
In-Reply-To: <20260520125756.530808-1-michal.sieron@nokia.com>
On Wed, 20 May 2026 14:57:56 +0200
Michal Sieron <michal.sieron@nokia.com> wrote:
> In rare cases, when a secondary process calls rte_eal_init() it can
> cause a data race during page prefaulting in alloc_seg().
>
> An atomic compare-exchange in a loop should eliminate the data race.
>
> Signed-off-by: Michal Sieron <michal.sieron@nokia.com>
> ---
> lib/eal/linux/eal_memalloc.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
> index a39bc31c7b..cb92fda2e8 100644
> --- a/lib/eal/linux/eal_memalloc.c
> +++ b/lib/eal/linux/eal_memalloc.c
> @@ -30,6 +30,7 @@
> #include <rte_eal.h>
> #include <rte_memory.h>
> #include <rte_cycles.h>
> +#include <rte_atomic.h>
>
> #include "eal_filesystem.h"
> #include "eal_internal_cfg.h"
> @@ -600,7 +601,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
> * that is already there, so read the old value, and write itback.
> * kernel populates the page with zeroes initially.
> */
> - *(volatile int *)addr = *(volatile int *)addr;
> + int snapshot = *(volatile int *)addr;
> + while (!rte_atomic_compare_exchange_strong((volatile int *)addr, &snapshot, snapshot))
> + ;
>
> iova = rte_mem_virt2iova(addr);
> if (iova == RTE_BAD_PHYS_ADDR) {
No don't use a loop with compare_exchange_strong here.
It could get stuck.
Should just a an relaxed load be enough to get the page in?
^ permalink raw reply
* Re: [PATCH 0/2] enhance telemetry list endpoint with device name
From: Stephen Hemminger @ 2026-05-20 14:54 UTC (permalink / raw)
To: Bruce Richardson; +Cc: fengchengwen, Morten Brørup, thomas, dev
In-Reply-To: <ag1nny7mJpM1pum6@bricha3-mobl1.ger.corp.intel.com>
On Wed, 20 May 2026 08:49:51 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Wed, May 20, 2026 at 03:31:57PM +0800, fengchengwen wrote:
> > On 5/20/2026 1:40 PM, Morten Brørup wrote:
> > >> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > >> Sent: Wednesday, 20 May 2026 05.57
> > >>
> > >> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
> > >> only integer IDs, making it hard to identify devices. This series
> > >> changes
> > >> both to output strings in "ID NAME" format for better usability.
> > >
> > > For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.
> >
> > The TEL_DICT could do {"ID", "NAME"}, which like:
> > "/ethdev/list": {
> > "0": "0000:7d:00.0",
> > "1": "0000:7d:00.1"
> > }
> >
> > Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
> > "/ethdev/list": {
> > 0: "0000:7d:00.0",
> > 1: "0000:7d:00.1"
> > }
> >
> > I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.
> >
> > What's your opinion?
> >
>
> I'm not sure about this change at all. This change is only relevant for
> those using the script interactively, for any other use, I would expect the
> the /ethdev/list call would be followed by the /ethdev/info calls for each
> port to get the name. That was the basic design in mind for this, the list
> call was purely to provide the ids, any other info you make separate calls
> for.
>
> Also, while not officially part of the ABI of DPDK, I think it would be
> wrong to go changing the types of the returned data from this /ethdev/list
> call. Any user-written interfaces to telemetry will be relying on the
> current behaviour to list and query ports. If you really want to have an
> easy way to get the names of the ports, I suggest adding instead an
> "/ethdev/list_names" API, which can either return the objects above, or
> else simply an array of names.
>
> /Bruce
The new wireshark extcap needs similar device list.
Ideally returning similar format to existing dpdk-dumpcap -D
^ permalink raw reply
* Re: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Bruce Richardson @ 2026-05-20 14:53 UTC (permalink / raw)
To: Morten Brørup; +Cc: Stephen Hemminger, dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65888@smartserver.smartshare.dk>
On Wed, May 20, 2026 at 03:50:34PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 20 May 2026 09.45
> PATCH 0/8] remove use of rte_memcpy from net/intel
> >
> > On Tue, May 19, 2026 at 12:43:32PM -0700, Stephen Hemminger wrote:
> > > On Tue, 19 May 2026 16:05:57 +0000
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > >
> > > > This RFC proposed to replace all instances of rte_memcpy in Intel
> > > > (and former-Intel) net drivers with just regular memcpy. This is
> > > > done on the basis that the memcpy use is not datapath, but is used
> > > > for flow configuration, virt-channel (to firmware or PF) messaging
> > > > and other control path functions.
> > >
> > > Makes sense. You might also want to look for where structure
> > > assignment can be used instead of memcpy. Keeping data types
> > > is a good thing.
> >
> > Yes, it would be nice to use in places. However, it's not a mechanical
> > change so I've not taken the time to do the analysis. Just a quick set
> > of sed replacements for this RFC.
>
> If you consider structure assignment, look out for fixed-size structures ending with field[1]; they are really (ill defined) flex-arrays.
>
Yep, they were mentioned in a previous discussion on-list with Anatoly too.
Three is always more cleanup to be done! :-)
^ permalink raw reply
* Re: [PATCH v5 0/2] Update Rx Timestamp in IAVF PMD
From: Bruce Richardson @ 2026-05-20 14:52 UTC (permalink / raw)
To: Soumyadeep Hore; +Cc: manoj.kumar.subbarao, aman.deep.singh, dev
In-Reply-To: <20260520184350.81934-1-soumyadeep.hore@intel.com>
On Wed, May 20, 2026 at 02:43:48PM -0400, Soumyadeep Hore wrote:
> PHC Polling from Rx Datapath is removed and existing alarm handlers are
> used to fix latency issues in IAVF PMD.
> ---
Series-acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to next-net-intel.
Thanks,
/Bruce
^ 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