* [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
* RE: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Morten Brørup @ 2026-05-20 13:50 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev
In-Reply-To: <ag1me_1XSByq3p9V@bricha3-mobl1.ger.corp.intel.com>
> 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.
^ permalink raw reply
* RE: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names
From: Morten Brørup @ 2026-05-20 13:29 UTC (permalink / raw)
To: Chengwen Feng, thomas, stephen; +Cc: dev, andrew.rybchenko, bruce.richardson
In-Reply-To: <20260520093804.29102-3-fengchengwen@huawei.com>
> 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
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"
]
}
Or a list of objects:
{
"/ethdev/list_names":
[
{
"port_id": 0,
"name": "0000:7d:00.0"
},
{
"port_id": 1,
"name": "0000:7d:00.1"
}
]
}
^ permalink raw reply
* [PATCH] net/mlx5: remove nonsensical flow action class_id checks
From: Adrian Schollmeyer @ 2026-05-20 13:25 UTC (permalink / raw)
To: Dariusz Sosnowski, Viacheslav Ovsiienko, Bing Zhao, Ori Kam,
Suanming Mou, Matan Azrad, Michael Baum
Cc: dev, Michael Pfeiffer, stable, Adrian Schollmeyer
From: Michael Pfeiffer <m.pfeiffer@syseleven.de>
For a MODIFY_FIELD action, flow_hw_validate_action_modify_field() is
invoked and enforces class_id == 0 in the action's source and
destination, if the modified field is none of
RTE_FLOW_FIELD_GENEVE_OPT_*, as the value is used solely for GENEVE
fields.
However, this check is flawed due to the way rte_flow_field_data is
initialized. As it consists of unions and anonymous structs as members,
empty initialization of this struct or initializing just the tag_index
only guarantees initialization of the first union member, while the
remaining member's default initialization behavior is unspecified.
Therefore, depending on the compiler type, version and configuration,
the remaining members may either be default-initialized as well or
contain bytes from uninitialized memory. This causes the check to fail
depending on how the struct is initialized wherever it is used.
For example, rte_flow_configure() sometimes fails on mlx5 under these
circumstances with an error "destination class id is not supported"
during creation of representor tagging rules, as these internally use
MODIFY_FIELD actions in the following call stack:
1. rte_flow_configure
2. mlx5_flow_port_configure
3. flow_hw_configure
4. __flow_hw_configure
5. flow_hw_setup_tx_repr_tagging
6. flow_hw_create_tx_repr_tag_jump_acts_tmpl
--> various rte_flow_action_modify_field are initialized here, but
class_id remains uninitialized
7. __flow_hw_actions_template_create
8. mlx5_flow_hw_actions_validate
9. flow_hw_validate_action_modify_field
--> invoked with class_id containing uninitialized bytes and
non-GENEVE field type
Remove the two checks for class_id in the non-GENEVE case, as this field
is unused for these actions and avoids additional implicit dependencies
on the correct ordering of union members.
Fixes: 1caa89ec1891 ("net/mlx5: support GENEVE options modification")
Cc: stable@dpdk.org
Signed-off-by: Michael Pfeiffer <m.pfeiffer@syseleven.de>
Signed-off-by: Adrian Schollmeyer <a.schollmeyer@syseleven.de>
---
drivers/net/mlx5/mlx5_flow_hw.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index bca5b2769e..add48d7c8f 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -6264,10 +6264,6 @@ flow_hw_validate_action_modify_field(struct rte_eth_dev *dev,
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, action,
"destination tag index is not supported");
- if (action_conf->dst.class_id)
- return rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ACTION, action,
- "destination class id is not supported");
}
if (mask_conf->dst.level != UINT8_MAX)
return rte_flow_error_set(error, EINVAL,
@@ -6290,10 +6286,6 @@ flow_hw_validate_action_modify_field(struct rte_eth_dev *dev,
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, action,
"source tag index is not supported");
- if (action_conf->src.class_id)
- return rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ACTION, action,
- "source class id is not supported");
}
if (mask_conf->src.level != UINT8_MAX)
return rte_flow_error_set(error, EINVAL,
--
2.34.1
^ permalink raw reply related
* [PATCH] linux/mem: atomically prefault hugepages in alloc_seg
From: Michal Sieron @ 2026-05-20 12:57 UTC (permalink / raw)
To: dev; +Cc: Michal Sieron
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) {
--
2.43.0
^ permalink raw reply related
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