* Re: [PATCH] net/ice: use configured outer TPID for VLAN filter in DVM
From: Bruce Richardson @ 2026-06-09 10:03 UTC (permalink / raw)
To: KAVYA AV; +Cc: dev, aman.deep.singh, shaiq.wani, stable
In-Reply-To: <20260527161442.394593-1-kavyax.a.v@intel.com>
On Wed, May 27, 2026 at 04:14:42PM +0000, KAVYA AV wrote:
> In Double VLAN Mode (DVM), the hardware switch recipe
> ICE_SW_LKUP_VLAN matches on both the VLAN ID and the TPID.
> Previously, ice_vlan_filter_set() always initialized the VLAN
> filter with the hardcoded RTE_ETHER_TYPE_VLAN (0x8100), regardless
> of the outer TPID configured by the user via vlan_tpid_set().
>
> This caused a mismatch when a non-standard outer TPID such as
> 0x88a8 (IEEE 802.1ad) was configured: the hardware filter was
> programmed with TPID 0x8100 while incoming packets carried TPID
> 0x88a8, resulting in all such packets being dropped by the VLAN
> pruning logic.
>
> Fix this by replacing the hardcoded RTE_ETHER_TYPE_VLAN with
> pf->outer_ethertype in the ICE_VLAN() macro call. This field is
> already updated by ice_vlan_tpid_set() when the user configures
> the outer TPID, and defaults to RTE_ETHER_TYPE_VLAN at
> initialization, so the change is safe for standard 802.1q traffic.
>
> In SVM, the TPID is not part of the hardware lookup key, so this
> change has no functional impact in that mode.
>
> Fixes: 295b34f55b00 ("net/ice: fix VLAN 0 adding based on VLAN mode")
> Cc: stable@dpdk.org
>
> Signed-off-by: KAVYA AV <kavyax.a.v@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to dpdk-next-net-intel.
Thanks,
/Bruce
^ permalink raw reply
* RE: [PATCH] net/iavf: fix to consolidate link change event handling
From: Loftus, Ciara @ 2026-06-09 10:02 UTC (permalink / raw)
To: Mandal, Anurag, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <20260609001022.357509-1-anurag.mandal@intel.com>
> Subject: [PATCH] net/iavf: fix to consolidate link change event handling
>
> Handled link-change events through a common static function that
> reads the correct advanced & legacy link fields properly and
> updates no-poll/watchdog/LSC state consistently.
>
> Fixes: 5e03e316c753 ("net/iavf: handle virtchnl event message without
> interrupt")
> Fixes: 48de41ca11f0 ("net/avf: enable link status update")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> ---
> drivers/net/intel/iavf/iavf_vchnl.c | 133 +++++++++++++++++-----------
> 1 file changed, 81 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> index 94ccfb5d6e..6454632541 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -216,6 +216,75 @@ iavf_convert_link_speed(enum virtchnl_link_speed
> virt_link_speed)
> return speed;
> }
>
> +/*
> + * iavf_handle_link_change_event: common handler for VIRTCHNL link
> change events
> + *
> + * @dev: pointer to rte_eth_dev for this VF
> + * @vpe: pointer to the virtchnl_pf_event payload received from the PF
> + *
> + * Handle PF link-change event: decode adv/legacy link info, update VF
> + * link state, sync no-poll/watchdog behavior & notify app via LSC event.
> + */
> +static void
> +iavf_handle_link_change_event(struct rte_eth_dev *dev,
> + struct virtchnl_pf_event *vpe)
> +{
> + struct iavf_adapter *adapter;
> + struct iavf_info *vf;
> + bool adv_link_speed;
> +
> + if (dev == NULL || dev->data == NULL ||
> + dev->data->dev_private == NULL || vpe == NULL) {
> + PMD_DRV_LOG(ERR, "Invalid device pointer in link change
> handler");
> + return;
> + }
Thanks for splitting this out into a standalone patch.
I'm not sure if all of the above NULL checking is necessary. Especially
vpe == NULL considering you've checked that for NULL in both
iavf_read_msg_from_pf and iavf_handle_pf_event_msg before entering this
function. It's recommended to avoid overly defensive checks that can
never trigger so I suggest taking a look at this again. Other than that
the changes looks good to me.
> +
> + adapter = IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data-
> >dev_private);
> + vf = &adapter->vf;
> +
> + adv_link_speed = (vf->vf_res != NULL) &&
> + ((vf->vf_res->vf_cap_flags &
> VIRTCHNL_VF_CAP_ADV_LINK_SPEED) != 0);
> +
^ permalink raw reply
* Re: [PATCH v5] doc: improve e1000 driver documentation
From: Bruce Richardson @ 2026-06-09 9:50 UTC (permalink / raw)
To: Talluri Chaitanyababu; +Cc: dev, stephen, aman.deep.singh, shaiq.wani
In-Reply-To: <20260324230343.1050223-1-chaitanyababux.talluri@intel.com>
On Tue, Mar 24, 2026 at 11:03:37PM +0000, Talluri Chaitanyababu wrote:
> Add an overview of the e1000 driver for Intel 1G devices.
>
> Signed-off-by: Talluri Chaitanyababu <chaitanyababux.talluri@intel.com>
> ---
>
> v5:
> * Aligned PMD names with code.
> * Fixed wording for clarity.
>
> v4:
> * Fixed RST structure, single top-level title.
> * Used ASCII "PCIe".
> * Adjusted commit message to match content.
>
> v3: Resolved apply patch failure.
>
> v2: Addressed review comments.
> ---
This doc still needs a lot of rework, and possibly merging with the igb and
igc driver docs.
However, this small patch is an improvement, so I think I'll take it into
next-net-intel for this release. One small change I'd suggest below, let me
know if I'm ok to take this on apply.
/Bruce
> doc/guides/nics/e1000em.rst | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/nics/e1000em.rst b/doc/guides/nics/e1000em.rst
> index ed4f57e9c6..a101b54020 100644
> --- a/doc/guides/nics/e1000em.rst
> +++ b/doc/guides/nics/e1000em.rst
> @@ -4,7 +4,20 @@
> Driver for VM Emulated Devices
> ==============================
>
> -The DPDK EM poll mode driver supports the following emulated devices:
> +E1000 Poll Mode Driver
> +----------------------
> +
> +DPDK provides several poll mode drivers (PMDs) supporting Intel 1 Gigabit ethernet controller families.
> +These include:
> +
> +* e1000_em – Intel 8254x family devices, including QEMU ``e1000`` emulation.
> +* e1000_igb – Intel PRO/1000 PCIe family.
> +
> +.. note::
> +
> + The ``igb`` and ``igc`` PMDs are built from the same driver binary but are documented in separate sections for clarity.
The reference to igc here is strange when it is not mentioned above
alongside igc. Would it be better to put it in brackets with a mention that
it's 2.5G (no not part of the 1G driver list). If you want I can rephrase
this on apply as:
"The ``igb`` (and ``igc`` for 2.5G) PMDs are built from the same e1000 driver binary but are
documented in separate sections for clarity"
> +
> +The e1000_em poll mode driver supports the following emulated devices:
>
> * qemu-kvm emulated Intel® 82540EM Gigabit Ethernet Controller (qemu e1000 device)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: liujie5 @ 2026-06-09 9:48 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: stephen, dev
In-Reply-To: <T4eYjXumTvWFDg9HUrMwEA@monjalon.net>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
Hi Thomas Monjalon,
Thank you for your review and for guiding me on the mailing list workflow.
> Please could you send your new series as a reply of the v1 cover letter?
> It would avoid having a large indent in mail clients.
Got it. I will configure git send-email with "--in-reply-to" bound to the
v1 cover letter Message-ID for the next version of this patch set.
Apologies for the inconvenience caused by the deep threading.
> Also I'm still waiting for a reply to my question about the need
> for drivers/common/sxe2/.
> I'm not going to pull any sxe2 patch into main until you explain.
Regarding the necessity of the "drivers/common/sxe2/" directory, the sxe2
hardware architecture is designed to support both standard NIC and vDPA
(vHost Data Path Acceleration) functionalities.
The code currently placed in "drivers/common/sxe2/" contains the foundational
Hardware Abstraction Layer (HAL), firmware interfaces (AdminQ), and common
register definitions.
Apart from the "net/sxe2" PMD in this series, we are actively implementing the
"vdpa/sxe2" driver, which will be submitted in a subsequent patch set. Both the
"net/sxe2" and "vdpa/sxe2" drivers strictly depend on this shared common HAL
layer to manage the same hardware core. Separating this code into "drivers/common/"
is essential to prevent massive code duplication between the net and vdpa
subsystems in the near future.
Please let me know if this clarifies your concern. Once confirmed, I will
send out the updated v15 series as a reply to the v1 cover letter immediately.
Best regards,
Jie Liu (liujie5@linkdatatechnology.com)
liujie5@linkdatatechnology.com
From: Thomas Monjalon
Date: 2026-06-09 16:42
To: Jie Liu
CC: stephen; dev
Subject: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
09/06/2026 03:39, liujie5@linkdatatechnology.com:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V14:
> - Addressed AI comments
Please could you send your new series as a reply of the v1 cover letter?
It would avoid having a large indent in mail clients.
Also I'm still waiting for a reply to my question about the need
for drivers/common/sxe2/.
I'm not going to pull any sxe2 patch into main until you explain.
[-- Attachment #2: Type: text/html, Size: 4440 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: liujie5 @ 2026-06-09 9:36 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: stephen, dev
In-Reply-To: <20260609013951.3359199-1-liujie5@linkdatatechnology.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
09/06/2026 03:39, liujie5@linkdatatechnology.com:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V14:
> - Addressed AI comments
Please could you send your new series as a reply of the v1 cover letter?
It would avoid having a large indent in mail clients.
Also I'm still waiting for a reply to my question about the need
for drivers/common/sxe2/.
I'm not going to pull any sxe2 patch into main until you explain.
[-- Attachment #2: Type: text/html, Size: 4094 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] eal: return error on devargs truncation in hotplug MP messages
From: David Marchand @ 2026-06-09 9:30 UTC (permalink / raw)
To: Long Li; +Cc: dev, bruce.richardson, stephen, Burakov, Anatoly
In-Reply-To: <20260325014506.1866374-1-longli@microsoft.com>
On Wed, 25 Mar 2026 at 02:45, Long Li <longli@microsoft.com> wrote:
>
> The EAL hotplug multi-process messaging uses a fixed-size buffer
> (EAL_DEV_MP_DEV_ARGS_MAX_LEN, 128 bytes) for device arguments.
> When devargs exceeds this limit, strlcpy silently truncates the
> string. This causes secondary processes to receive incomplete
> devargs during hotplug re-add, leading to failed port
> re-initialization.
>
> For example, a MANA PCI device with 6 mac= arguments:
>
> mac=AA:BB:CC:DD:EE:01,mac=AA:BB:CC:DD:EE:02,
> mac=AA:BB:CC:DD:EE:03,mac=AA:BB:CC:DD:EE:04,
> mac=AA:BB:CC:DD:EE:05,mac=AA:BB:CC:DD:EE:06
>
> produces a 131-byte devargs string that gets silently truncated
> to 127 bytes, losing the last MAC address.
>
> Return -E2BIG from rte_dev_probe() and rte_dev_remove() when
> devargs would be truncated, instead of silently corrupting data.
>
> Signed-off-by: Long Li <longli@microsoft.com>
Worth a Fixes: tag and Cc: stable.
> ---
> lib/eal/common/eal_common_dev.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/eal/common/eal_common_dev.c b/lib/eal/common/eal_common_dev.c
> index 7185de0cb9..de24d14d28 100644
> --- a/lib/eal/common/eal_common_dev.c
> +++ b/lib/eal/common/eal_common_dev.c
> @@ -250,6 +250,11 @@ rte_dev_probe(const char *devargs)
>
> memset(&req, 0, sizeof(req));
> req.t = EAL_DEV_REQ_TYPE_ATTACH;
> + if (strlen(devargs) >= EAL_DEV_MP_DEV_ARGS_MAX_LEN) {
> + EAL_LOG(ERR, "devargs truncated (len %zu, max %d)",
> + strlen(devargs), EAL_DEV_MP_DEV_ARGS_MAX_LEN);
> + return -E2BIG;
> + }
> strlcpy(req.devargs, devargs, EAL_DEV_MP_DEV_ARGS_MAX_LEN);
Please move the check before the memset().
>
> if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> @@ -397,6 +402,12 @@ rte_dev_remove(struct rte_device *dev)
>
> memset(&req, 0, sizeof(req));
> req.t = EAL_DEV_REQ_TYPE_DETACH;
> + if (strlen(devargs) >= EAL_DEV_MP_DEV_ARGS_MAX_LEN) {
> + EAL_LOG(ERR, "devargs truncated (len %zu, max %d)",
> + strlen(devargs), EAL_DEV_MP_DEV_ARGS_MAX_LEN);
> + free(devargs);
> + return -E2BIG;
> + }
> strlcpy(req.devargs, devargs, EAL_DEV_MP_DEV_ARGS_MAX_LEN);
> free(devargs);
>
Why do we need to validate devargs on cleanup?
Its length should have been validated during probe.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] eal: fix function versioning with LTO
From: David Marchand @ 2026-06-09 9:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Thomas Monjalon
In-Reply-To: <20260605111233.725bb792@phoenix.local>
On Fri, 5 Jun 2026 at 20:12, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> >
> > Looking at bugzilla, we had various fixes for LTO over the years.
> > We still have one open bz btw: https://bugs.dpdk.org/show_bug.cgi?id=1709
>
> That bug was fixed a while back. It required addition of hints (__rte_assume)
I have trouble identifying the changes.
Please close the 1709 bugzilla with a mention of those changes.
> > > > LTO is kind of experimental, so it seems good enough to reply "not
> > > > expected to work in older LTS" if someone reported an issue.
> > > >
> > > > And in practice, no LTS release call the versioning macros, since a
> > > > LTS drops all compatibility.
> >
> > Just to be clear, we don't need fixing the macros in LTS: every time
> > we prepare a LTS rc0, we drop any kind of symbol compat.
>
> Agree, this is not LTS related
>
> > > >
> > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > >
> > > > I would like to reproduce, but I can't build main with LTO.
> > > > What patches did you apply locally to avoid warnings on the hash library?
> > > I use Debian testing and GCC 15 but shows up on older versions as well
> > > I get no warnings building main
> >
> > Building from scratch, I do avoid the warnings I hit yesterday.
> >
> > The fix looks correct, my problem is with the form.
> > Fixes: tags accuracy is important.
> > And I prefer we stick to "It is not broken, don't fix it".
>
> Could argue it is a GCC bug, and applying their desired workaround :-)
Indeed, but the end results is the same for me :-)
Can you send a v2?
Thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: fix counter TAILQ race between free and query callback
From: Dariusz Sosnowski @ 2026-06-09 9:22 UTC (permalink / raw)
To: Linhu Li; +Cc: dev, stable, rasland
In-Reply-To: <20260608132555.31439-1-lilinhu618@gmail.com>
On Mon, Jun 08, 2026 at 09:25:55PM +0800, Linhu Li wrote:
> flow_dv_counter_free() inserts counters into
> pool->counters[pool->query_gen] under pool->csl. Meanwhile,
> mlx5_flow_async_pool_query_handle() moves counters from
> pool->counters[query_gen ^ 1] to the global free list via
> TAILQ_CONCAT while holding only cmng->csl, not pool->csl.
>
> The comment in flow_dv_counter_free() claims the lock is not needed
> because the query callback and the release function operate on
> different lists. That holds only if the free path always observes
> the up-to-date query_gen. It can be violated:
>
> 1. A counter free thread (non-PMD, e.g. OVS offload thread) reads
> pool->query_gen == 0 and is about to insert into counters[0].
> 2. The free thread is preempted by the OS scheduler; it is a regular
> pthread, not pinned to a core.
> 3. The eal-intr-thread alarm fires: query_gen++ (now 1) and the async
> query is sent.
> 4. Hardware completes the query and the callback runs TAILQ_CONCAT on
> counters[0] (= query_gen ^ 1).
> 5. The free thread resumes and runs TAILQ_INSERT_TAIL on counters[0]
> concurrently with step 4 on another core.
>
> Because the two paths take different locks, TAILQ_INSERT_TAIL and
> TAILQ_CONCAT run concurrently on the same list with no
> synchronization and corrupt it: the pool-local list ends up with a
> NULL head but a dangling tqh_last, and the global free list tail no
> longer points to the real tail. The just-freed counter and every
> counter inserted afterwards become unreachable and are leaked.
>
> Non-PMD threads can be preempted for hundreds of microseconds under
> CPU pressure, which is well within the async query round-trip time,
> so the window is reachable in practice.
>
> Fix it by taking pool->csl in the query completion callback before
> operating on pool->counters[query_gen], serializing the CONCAT with
> any concurrent INSERT. The lock is taken once per pool per query
> completion in the eal-intr-thread context, not on the datapath, so
> the cost is negligible. Lock order is pool->csl then cmng->csl,
> matching all other sites.
>
> Also handle the error path: previously the counters accumulated in
> pool->counters[query_gen] were abandoned when a query failed. Move
> them back to the global free list to avoid a leak on persistent
> query failures.
>
> Fixes: ac79183dc6f7 ("net/mlx5: optimize free counter lookup")
> Cc: stable@dpdk.org
>
> Signed-off-by: Linhu Li <lilinhu618@gmail.com>
Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
^ permalink raw reply
* Re: [PATCH] eal: add destructor to unregister tailq on unload
From: David Marchand @ 2026-06-09 9:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Neil Horman
In-Reply-To: <20260607150418.30885-1-stephen@networkplumber.org>
On Sun, 7 Jun 2026 at 17:04, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> Libraries that use EAL_REGISTER_TAILQ insert a pointer to a static
> struct rte_tailq_elem into the process-local tailq list via a
> constructor, but have no matching destructor. When such a library
> is loaded as a dependency of a plugin via dlopen() and later
> unloaded via dlclose(), the list retains a dangling pointer to the
> now-unmapped static. Reloading the plugin crashes in
> rte_eal_tailq_local_register() when it traverses the stale entry.
>
> Add rte_eal_tailq_unregister() and extend the EAL_REGISTER_TAILQ
> macro to emit an RTE_FINI destructor alongside the existing
> RTE_INIT constructor. Every library that uses the macro
> automatically gets both sides; no per-library changes are needed.
>
> Bugzilla ID: 1081
> Fixes: 873a61c7526b ("tailq: introduce dynamic register system")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/eal/common/eal_common_tailqs.c | 8 ++++++++
> lib/eal/include/rte_tailq.h | 17 +++++++++++++++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/lib/eal/common/eal_common_tailqs.c b/lib/eal/common/eal_common_tailqs.c
> index c581f43b6f..714f91d0ec 100644
> --- a/lib/eal/common/eal_common_tailqs.c
> +++ b/lib/eal/common/eal_common_tailqs.c
> @@ -148,6 +148,14 @@ rte_eal_tailq_register(struct rte_tailq_elem *t)
> return -1;
> }
>
> +RTE_EXPORT_SYMBOL(rte_eal_tailq_unregister)
> +void
> +rte_eal_tailq_unregister(struct rte_tailq_elem *t)
> +{
> + TAILQ_REMOVE(&rte_tailq_elem_head, t, next);
> + t->head = NULL;
> +}
This cleans up the local storage which is good, but it leaves an entry
reserved in the mcfg->tailq_head[] array.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v8 2/4] examples/ptp_tap_relay_sw: add PTP software transparent clock relay
From: Thomas Monjalon @ 2026-06-09 9:15 UTC (permalink / raw)
To: Rajesh Kumar; +Cc: dev, bruce.richardson, aman.deep.singh, stephen, mb
In-Reply-To: <FtOw8lUNTi2iReVfgCFy-Q@monjalon.net>
09/06/2026 10:52, Thomas Monjalon:
> 10/05/2026 01:25, Rajesh Kumar:
> > Add a new example application demonstrating a software PTP Transparent
> > Clock relay between a DPDK-bound physical NIC and a Linux kernel TAP
> > virtual interface.
> [...]
> > doc/guides/sample_app_ug/index.rst | 1 +
> > doc/guides/sample_app_ug/ptp_tap_relay_sw.rst | 212 +++++++++
> > examples/ptp_tap_relay_sw/Makefile | 41 ++
> > examples/ptp_tap_relay_sw/meson.build | 13 +
> > examples/ptp_tap_relay_sw/ptp_parse.h | 211 +++++++++
> > examples/ptp_tap_relay_sw/ptp_tap_relay_sw.c | 432 ++++++++++++++++++
> > 6 files changed, 910 insertions(+)
>
> You didn't update the file MAINTAINERS.
> I assume you will be the maintainer for this new example?
> I will update when merging.
Sorry I see you did the update in the lib patch.
^ permalink raw reply
* Re: [PATCH v3] raw/ifpga: replace printf calls with logging
From: David Marchand @ 2026-06-09 9:05 UTC (permalink / raw)
To: Weijun Pan; +Cc: Rosen Xu, dev, Weijun Pan, Bruce Richardson
In-Reply-To: <20260410162826.15485-1-wpan36@wisc.edu>
On Sat, 11 Apr 2026 at 15:58, Weijun Pan <wpan3636@gmail.com> wrote:
>
> The ifpga rawdev driver uses printf() directly for runtime messages.
> DPDK drivers should use the logging framework instead of printing
> to standard output.
>
> Replace the remaining direct printf() calls in ifpga_rawdev.c with
> the driver logging macros.
>
> Signed-off-by: Weijun Pan <wpan36@wisc.edu>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] eal: update comment for eal_get_virtual_area()
From: David Marchand @ 2026-06-09 9:02 UTC (permalink / raw)
To: Marcel Telka; +Cc: dev, Anatoly Burakov
In-Reply-To: <20251219191554.939982-1-marcel@telka.sk>
On Fri, 19 Dec 2025 at 20:16, Marcel Telka <marcel@telka.sk> wrote:
>
> Bugzilla ID: 1853
>
> Signed-off-by: Marcel Telka <marcel@telka.sk>
I added some commitlog based on your description in the bugzilla.
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] Remove redundant simpler equivalent section
From: David Marchand @ 2026-06-09 8:53 UTC (permalink / raw)
To: Arin Kharkar; +Cc: dev
In-Reply-To: <20260512191651.126274-1-arinkharkar@gmail.com>
On Wed, 13 May 2026 at 14:35, Arin Kharkar <arinkharkar@gmail.com> wrote:
>
> Fixed outdated documentation on the hello world doc, which incorrectly stated an easier way to launch the lcore_hello function. The example program uses the simpler version and the documentation stating it as an "equivalent and simpler" alternative is moot. It is now the default.
>
> Signed-off-by: Arin Kharkar <arinkharkar@gmail.com>
> ---
> doc/guides/sample_app_ug/hello_world.rst | 8 --------
> examples/helloworld/main.c | 4 +---
> 2 files changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/doc/guides/sample_app_ug/hello_world.rst b/doc/guides/sample_app_ug/hello_world.rst
> index 5bfd4b3fda..b7167aa345 100644
> --- a/doc/guides/sample_app_ug/hello_world.rst
> +++ b/doc/guides/sample_app_ug/hello_world.rst
> @@ -70,12 +70,4 @@ The code that launches the function on each lcore is as follows:
> :end-before: >8 End of launching the function on each lcore.
> :dedent: 1
>
> -The following code is equivalent and simpler:
> -
> -.. literalinclude:: ../../../examples/helloworld/main.c
> - :language: c
> - :start-after: Simpler equivalent. 8<
> - :end-before: >8 End of simpler equivalent.
> - :dedent: 2
> -
> Refer to the *DPDK API Reference* for detailed information on the rte_eal_mp_remote_launch() function.
> diff --git a/examples/helloworld/main.c b/examples/helloworld/main.c
> index af509138da..8d1a959c58 100644
> --- a/examples/helloworld/main.c
> +++ b/examples/helloworld/main.c
> @@ -40,13 +40,11 @@ main(int argc, char **argv)
>
> /* Launches the function on each lcore. 8< */
> RTE_LCORE_FOREACH_WORKER(lcore_id) {
> - /* Simpler equivalent. 8< */
> rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
> - /* >8 End of simpler equivalent. */
> }
>
> /* call it on main lcore too */
> - lcore_hello(NULL);
> + lcore_hello(NULL);
Unneeded change, which I dropped when applying.
> /* >8 End of launching the function on each lcore. */
>
> rte_eal_mp_wait_lcore();
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH] Windows: fix core count on NUMA with more than 64 cores per node
From: David Marchand @ 2026-06-09 8:52 UTC (permalink / raw)
To: Andre Muezerie; +Cc: Dmitry Kozlyuk, dev, Gena Tertychnyi
In-Reply-To: <20260513235518.408895-1-andremue@linux.microsoft.com>
On Thu, 14 May 2026 at 01:56, Andre Muezerie
<andremue@linux.microsoft.com> wrote:
>
> From: Gena Tertychnyi <genter@microsoft.com>
>
> Fix specific to Windows NUMA machines with more than 64 cores per node
> (e.g. 2 NUMAs with 128 cores each):
>
> - NumaNode.GroupMasks[] array is used instead of NumaNode.GroupMask.
> - RelationAll is used instead of RelationNumaNode when calling
> GetLogicalProcessorInformationEx because RelationAll returns the full
> multi-group NUMA affinity as RelationNumaNode returns only the NUMA
> node's primary group.
>
> Signed-off-by: Gena Tertychnyi <genter@microsoft.com>
> Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
Applied with Dmitry suggestion on the Fixes: tag.
Thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH v8 2/4] examples/ptp_tap_relay_sw: add PTP software transparent clock relay
From: Thomas Monjalon @ 2026-06-09 8:52 UTC (permalink / raw)
To: Rajesh Kumar; +Cc: dev, bruce.richardson, aman.deep.singh, stephen, mb
In-Reply-To: <20260509232551.2844201-3-rajesh3.kumar@intel.com>
10/05/2026 01:25, Rajesh Kumar:
> Add a new example application demonstrating a software PTP Transparent
> Clock relay between a DPDK-bound physical NIC and a Linux kernel TAP
> virtual interface.
[...]
> doc/guides/sample_app_ug/index.rst | 1 +
> doc/guides/sample_app_ug/ptp_tap_relay_sw.rst | 212 +++++++++
> examples/ptp_tap_relay_sw/Makefile | 41 ++
> examples/ptp_tap_relay_sw/meson.build | 13 +
> examples/ptp_tap_relay_sw/ptp_parse.h | 211 +++++++++
> examples/ptp_tap_relay_sw/ptp_tap_relay_sw.c | 432 ++++++++++++++++++
> 6 files changed, 910 insertions(+)
You didn't update the file MAINTAINERS.
I assume you will be the maintainer for this new example?
I will update when merging.
^ permalink raw reply
* Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: Thomas Monjalon @ 2026-06-09 8:42 UTC (permalink / raw)
To: Jie Liu; +Cc: stephen, dev
In-Reply-To: <20260609013951.3359199-1-liujie5@linkdatatechnology.com>
09/06/2026 03:39, liujie5@linkdatatechnology.com:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V14:
> - Addressed AI comments
Please could you send your new series as a reply of the v1 cover letter?
It would avoid having a large indent in mail clients.
Also I'm still waiting for a reply to my question about the need
for drivers/common/sxe2/.
I'm not going to pull any sxe2 patch into main until you explain.
^ permalink raw reply
* RE: [PATCH] net/iavf: fix misleading AQ failure logging
From: Loftus, Ciara @ 2026-06-09 8:13 UTC (permalink / raw)
To: Mandal, Anurag, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <20260608171559.355521-1-anurag.mandal@intel.com>
> Subject: [PATCH] net/iavf: fix misleading AQ failure logging
>
> iavf_handle_virtchnl_msg() drains the admin receive queue in a loop
> until iavf_clean_arq_element() reports that no descriptors are
> pending. When the queue becomes empty, the base driver returns
> IAVF_ERR_ADMIN_QUEUE_NO_WORK (-57), which is the documented
> terminator for the drain loop, and is not an error.
>
> The current loop treats every non-IAVF_SUCCESS return as a failure
> and logs it as follows:
>
> "Failed to read msg from AdminQ, ret: -57"
>
> This message floods the logs on every interrupt cycle and misleads
> the triage during VF reset by chasing a real virtchnl problem
> seeing these spurious -57 AQ failure lines in logs and assumes
> the admin queue is broken, when in fact it has just been drained.
>
> This patch fixes the aforesaid issue by treating
> IAVF_ERR_ADMIN_QUEUE_NO_WORK in virtchnl message drain as a normal
> loop exit empty-queue condition and avoid logging it as an misleading
> AQ failure.
>
> Fixes: 02d212ca3125 ("net/iavf: rename remaining avf strings")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> ---
> drivers/net/intel/iavf/iavf_vchnl.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> index 94ccfb5d6e..870d5c1820 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -570,7 +570,15 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev)
> while (pending) {
> ret = iavf_clean_arq_element(hw, &info, &pending);
>
> - if (ret != IAVF_SUCCESS) {
> + /*
> + * IAVF_ERR_ADMIN_QUEUE_NO_WORK (-57) means AQ is
> empty
> + * and is a normal way to terminate the drain loop.
> + * Log error only for genuine other failure codes.
> + * Incorrect logging like this during VF resets might
> + * mislead into chasing a non-existent AQ failure.
> + */
> + if (ret != IAVF_SUCCESS &&
> + ret != IAVF_ERR_ADMIN_QUEUE_NO_WORK) {
> PMD_DRV_LOG(INFO, "Failed to read msg from
> AdminQ,"
> "ret: %d", ret);
> break;
> --
I agree we should suppress the log on ret=NO_WORK but I
think we should still break instead of proceeding with the
message handling code. With your changes, in place of the
log:
IAVF_DRIVER: iavf_handle_virtchnl_msg(): Failed to read msg from AdminQ,ret: -57
I now see:
IAVF_DRIVER: iavf_handle_virtchnl_msg(): Request 0 is not supported yet
I think that's because we enter the message handling code
and arrive at the default case in the switch statement.
^ permalink raw reply
* Re: [PATCH 1/1] buildtools: remove absolute paths from pc file
From: Bruce Richardson @ 2026-06-09 8:09 UTC (permalink / raw)
To: Srikanth Yalavarthi; +Cc: dev
In-Reply-To: <aifFFS9gvRn9JYKg@bricha3-mobl1.ger.corp.intel.com>
On Tue, Jun 09, 2026 at 08:47:33AM +0100, Bruce Richardson wrote:
> On Tue, Jun 09, 2026 at 10:02:20AM +0530, Srikanth Yalavarthi wrote:
> > When linking with non-versioned libraries, absolute paths
> > of the libraries are added to libdpdk.pc. This patch replaces
> > the absolute path with correct linker flags, -l<libname>.
> >
>
> Do we need to check if we need a "-L" flag for some of these paths that are
> stripped?
>
> > https://github.com/mesonbuild/meson/issues/7766
> >
The bug report indicates that this issue only occurs for some libs which
are missing an SONAME. Checking the .pc files generated on my own system, I
don't see any libs listed with full paths. Out of interest, what libraries
are causing problems? (Alternative question - how can we reproduce this
issue to check the fix :-) )
Thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH v4 5/5] eal: avoid deadlock in async IPC alarm callback
From: Burakov, Anatoly @ 2026-06-09 8:04 UTC (permalink / raw)
To: dev, Jianfeng Tan
In-Reply-To: <c5284e2f5e9fb7d664ab65115cac2634c93aa510.1780669755.git.anatoly.burakov@intel.com>
On 6/5/2026 4:29 PM, Anatoly Burakov wrote:
> async_reply_handle_thread_unsafe() can run while holding
> pending_requests.lock and currently calls rte_eal_alarm_cancel().
>
> rte_eal_alarm_cancel() may spin-wait for an executing callback, which can
> deadlock if that callback is blocked on the same lock.
>
> Remove callback-side alarm cancellation. It is safe to do so, because any
> callback triggered without a pending request becomes a noop.
>
> Fixes: daf9bfca717e ("ipc: remove thread for async requests")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
Okay, the AI review seems to keep flagging issues that are technically
true in the patches, but are intentional and do get better once the
complete patchset is applied.
Looks like I need to merge some of the patches or rethink the order in
which the fixes are applied to avoid these issues.
--
Thanks,
Anatoly
^ permalink raw reply
* Re: [PATCH v16 0/5] Support add/remove memory region and get-max-slots
From: Maxime Coquelin @ 2026-06-09 7:58 UTC (permalink / raw)
To: pravin.bathija; +Cc: dev, stephen, fengchengwen, thomas
In-Reply-To: <20260606025211.1082615-1-pravin.bathija@dell.com>
On Sat, Jun 6, 2026 at 4:52 AM <pravin.bathija@dell.com> wrote:
>
> From: Pravin M Bathija <pravin.bathija@dell.com>
>
> This is version v16 of the patchset and it incorporates the
> recommendations made by Stephen Hemminger.
>
> Patch 4/5
> - Fixed use-after-free in vhost_user_add_mem_reg(): reg pointed into
> dev->mem->regions[] but dev_invalidate_vrings() ->
> translate_ring_addresses() -> numa_realloc() can relocate dev->mem ;
> re-drive the region pointer from the refreshed dev before reading
> host_user_addr for the reply.
> - Gated the ADD_MEM_REG mapping-address reply on dev->postcopy_listening
> per the vhost-user spec (reply is postcopy-only); return
> RTE_VHOST_MSG_RESULT_OK in non-postcopy mode, matching SET_MEM_TABLE,
> to avoid desyncing the channel.
>
> This implementation has been extensively tested by doing Read/Write I/O
> from multiple instances of fio + libblkio (front-end) talking to
> spdk/dpdk (back-end) based drives. Tested with qemu front-end talking to
> dpdk testpmd (back-end) performing add/removal of memory regions. Also
> tested post-copy live migration after doing add_memory_region.
>
> Version Log:
> Version v16 (Current version): Incorporate code review suggestions from
> Stephen Hemminger.
>
> Version v15: Incorporate review suggestions from Maxime Coquelin.
> Patch 4/5
> - Changed VHOST_USER_REM_MEM_REG handler declaration from
> accepts_fd=true to accepts_fd=false, as the remove request does not
> expect FDs in ancillary data.
> - Removed all close_msg_fds(ctx) calls from vhost_user_rem_mem_reg(), no
> longer needed since the handler is declared as not accepting FDs.
> - Removed validate_msg_fds(dev, ctx, 0) check from
> vhost_user_rem_mem_reg(), as FD validation is now handled generically
> by the framework.
> - Added targeted IOTLB cache invalidation in vhost_user_rem_mem_reg()
> using vhost_user_iotlb_cache_remove() for the removed region's GPA
> range, instead of the nuclear iotlb_flush_all() used by set_mem_table.
>
> Version v14: Incorporate code review suggestions from Stephen Hemminger
> and Fengcheng Wen.
> Changes from Fengcheng Wen review:
> Patch 3/5
> - Moved free_all_mem_regions() call sites in vhost_user_set_mem_table()
> from patch 4/5 to patch 3/5 so each commit compiles independently
> Patch 4/5
> - Renamed _dev_invalidate_vrings() to vhost_user_invalidate_vrings() to
> follow vhost naming convention
> - Added comment explaining *pdev propagation through
> translate_ring_addresses / numa_realloc()
> - Reordered local variables in vhost_user_add_mem_reg() and
> vhost_user_rem_mem_reg() by descending line length
> - Shortened overlap check variable names (current_region_guest_start/end
> --> cur_start/end, proposed_region_guest_start/end -> new_start/end)
> - Fixed DMA error path in vhost_user_add_mem_reg(): added
> free_new_region_no_dma label so async_dma_map_region(false) is not
> called when the map itself failed.
> Changes from Stephen Hemminger review:
> Patch 4/5
> - vhost_user_add_mem_reg() now constructs a reply with the back-end's
> host mapping address in userspace_addr and returns
> RTE_VHOST_MSG_RESULT_REPLY per the vhost-user spec
> - Added validate_msg_fds(dev, ctx, 0) in vhost_user_rem_mem_reg() to
> reject malformed messages with unexpected file descriptors
> - Dropped unnecessary (uint64_t) cast in vhost_user_get_max_mem_slots()
>
> Version v13: Incorporate code review suggestions from Fengcheng Wen
> Patch 2/5
> Renamed VhostUserSingleMemReg to VhostUserMemRegMsg and memory_single
> to memreg
> Patches 3/5 and 4/5
> Relocated function remove_guest_pages from patch 3/5 to 4/5
>
> Version v12: Incorporate code review suggestions from Maxime Coquelin
> and ai-code-review.
> Patch 3/5
> Refactored async_dma_map() to delegate to async_dma_map_region(),
> eliminating code duplication between the two functions.
> Restored original comments in async_dma_map_region() explaining why
> ENODEV and EINVAL errors are ignored (these were stripped in v10)
> Reverted unnecessary changes to vhost_user_postcopy_register() --
> removed the host_user_addr == 0 checks and reg_msg_index indirection
> that were added in v10, since this function is only called from
> vhost_user_set_mem_table() where regions are always contiguous.
>
> Version v11: Incorporate code review suggestions from Stephen Hemminger.
> Patch 4/5
> Fix incomplete cleanup in vhost_user_add_mem_reg() when
> vhost_user_mmap_region() fails after the mmap succeeds (e.g.
> add_guest_pages() realloc failure) realloc failure). The error path now
> calls remove_guest_pages() and free_mem_region() to undo the mapping
> and stale guest-page entries, preventing a leaked mmap and slot reuse
> corruption. The plain close(fd) path is kept for pre-mmap failures.
>
> Version v10: Incorporate code review suggestions from Stephen Hemminger.
> Patch 4/5
> Moved dev_invalidate_vrings after free_mem_region, array compaction, and
> nregions decrement. This ensures translate_ring_addresses only sees
> surviving memory regions, preventing vring pointers from resolving into
> a region that is about to be unmapped.
>
> Version v9: Incorporate code review suggestions from Stephen Hemminger.
> Patch 3/5
> Restored max_guest_pages initial value to hardcoded 8 instead of
> VHOST_MEMORY_MAX_NREGIONS, matching upstream semantics.
> Patch 4/5
> Added close(reg->fd) and reg->fd = -1 before goto close_msg_fds in the
> mmap failure path to fix fd leak after fd was moved from ctx->fds[0].
> Converted dev_invalidate_vrings from a plain function to a macro +
> implementation function pair, accepting message ID as a parameter so
> the static_assert reports the correct handler at each call site.
> Updated dev_invalidate_vrings call in add_mem_reg to pass
> VHOST_USER_ADD_MEM_REG as message ID.
> Updated dev_invalidate_vrings call in rem_mem_reg to pass
> VHOST_USER_REM_MEM_REG as message ID.
>
> Version v8: Incorporate code review suggestions from Stephen Hemminger.
> rewrite async_dma_map_region function to iterate guest pages by host
> address range matching
> change function dev_invalidate_vrings to accept a double pointer to
> propagate pointer updates
> new function remove_guest_pages was added
> add_mem_reg error path was narrowed to only clean up the single failed
> region instead of destroting all existing regions
>
> Version v7: Incorporate code review suggestions from Maxime Coquelin.
> Add debug messages to vhost_postcopy_register function.
>
> Version v6: Added the enablement of this feature as a final patch in
> this patch-set and other code optimizations as suggested by Maxime
> Coquelin.
>
> Version v5: removed the patch that increased the number of memory regions
> from 8 to 128. This will be submitted as a separate feature at a later
> point after incorporating additional optimizations. Also includes code
> optimizations as suggested by Feng Cheng Wen.
>
> Version v4: code optimizations as suggested by Feng Cheng Wen.
>
> Version v3: code optimizations as suggested by Maxime Coquelin
> and Thomas Monjalon.
>
> Version v2: code optimizations as suggested by Maxime Coquelin.
>
> Version v1: Initial patch set.
>
> Pravin M Bathija (5):
> vhost: add user to mailmap and define to vhost hdr
> vhost: header defines for add/rem mem region
> vhost: refactor memory helper functions
> vhost: add mem region add/remove handlers
> vhost: enable configure memory slots
>
> .mailmap | 1 +
> lib/vhost/rte_vhost.h | 4 +
> lib/vhost/vhost_user.c | 438 +++++++++++++++++++++++++++++++++++------
> lib/vhost/vhost_user.h | 10 +
> 4 files changed, 391 insertions(+), 62 deletions(-)
>
> --
> 2.43.0
>
Applied to next-virtio/for-next-net.
Thanks,
Maxime
^ permalink raw reply
* [PATCH] net/crc: add 4x folding loop for x86 SSE implementation
From: Shreesh Adiga @ 2026-06-09 7:57 UTC (permalink / raw)
To: Jasvinder Singh, Bruce Richardson, Konstantin Ananyev; +Cc: dev
Add a 64-byte loop that maintains 4 fold registers and processes
64 bytes at a time. The 4x fold registers is then reduced to 16 byte
single fold, similar to AVX512 implementation. This technique is
described in the paper by Intel:
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
This results in roughly 50% performance improvement due to better ILP
for large input sizes like 1024.
Signed-off-by: Shreesh Adiga <16567adigashreesh@gmail.com>
---
lib/net/net_crc_sse.c | 59 +++++++++++++++++++++++++++++++++++--------
1 file changed, 48 insertions(+), 11 deletions(-)
diff --git a/lib/net/net_crc_sse.c b/lib/net/net_crc_sse.c
index 3b6fbfecac..dfef8ecc59 100644
--- a/lib/net/net_crc_sse.c
+++ b/lib/net/net_crc_sse.c
@@ -14,6 +14,7 @@
/** PCLMULQDQ CRC computation context structure */
struct crc_pclmulqdq_ctx {
__m128i rk1_rk2;
+ __m128i rk3_rk4;
__m128i rk5_rk6;
__m128i rk7_rk8;
};
@@ -150,9 +151,36 @@ crc32_eth_calc_pclmulqdq(
temp = _mm_insert_epi32(_mm_setzero_si128(), crc, 0);
/**
- * Folding all data into single 16 byte data block
- * Assumes: fold holds first 16 bytes of data
+ * Folding all data into 4 parallel 16 byte data block
+ * Later folds 4 parallel blocks into single fold block
*/
+ if (likely(data_len >= 64)) {
+ __m128i fold1, fold2, fold3, fold4;
+ __m128i temp1, temp2, temp3, temp4;
+ fold1 = _mm_loadu_si128((const __m128i *)(data + 0));
+ fold2 = _mm_loadu_si128((const __m128i *)(data + 16));
+ fold3 = _mm_loadu_si128((const __m128i *)(data + 32));
+ fold4 = _mm_loadu_si128((const __m128i *)(data + 48));
+ fold1 = _mm_xor_si128(fold1, temp);
+ k = params->rk1_rk2;
+
+ for (n = 64; (n + 64) <= data_len; n += 64) {
+ temp1 = _mm_loadu_si128((const __m128i *)&data[n]);
+ temp2 = _mm_loadu_si128((const __m128i *)&data[n + 16]);
+ temp3 = _mm_loadu_si128((const __m128i *)&data[n + 32]);
+ temp4 = _mm_loadu_si128((const __m128i *)&data[n + 48]);
+ fold1 = crcr32_folding_round(temp1, k, fold1);
+ fold2 = crcr32_folding_round(temp2, k, fold2);
+ fold3 = crcr32_folding_round(temp3, k, fold3);
+ fold4 = crcr32_folding_round(temp4, k, fold4);
+ }
+
+ k = params->rk3_rk4;
+ fold1 = crcr32_folding_round(fold2, k, fold1);
+ fold1 = crcr32_folding_round(fold3, k, fold1);
+ fold = crcr32_folding_round(fold4, k, fold1);
+ goto single_fold_loop;
+ }
if (unlikely(data_len < 32)) {
if (unlikely(data_len == 16)) {
@@ -182,7 +210,7 @@ crc32_eth_calc_pclmulqdq(
fold = _mm_loadu_si128((const __m128i *)data);
fold = _mm_xor_si128(fold, temp);
n = 16;
- k = params->rk1_rk2;
+ k = params->rk3_rk4;
goto partial_bytes;
}
@@ -191,9 +219,12 @@ crc32_eth_calc_pclmulqdq(
fold = _mm_loadu_si128((const __m128i *)data);
fold = _mm_xor_si128(fold, temp);
- /** Main folding loop - the last 16 bytes is processed separately */
- k = params->rk1_rk2;
- for (n = 16; (n + 16) <= data_len; n += 16) {
+ /** Single folding loop - the last 16 bytes is processed separately */
+ k = params->rk3_rk4;
+ n = 16;
+
+single_fold_loop:
+ for (; (n + 16) <= data_len; n += 16) {
temp = _mm_loadu_si128((const __m128i *)&data[n]);
fold = crcr32_folding_round(temp, k, fold);
}
@@ -236,12 +267,14 @@ crc32_eth_calc_pclmulqdq(
void
rte_net_crc_sse42_init(void)
{
- uint64_t k1, k2, k5, k6;
+ uint64_t k1, k2, k3, k4, k5, k6;
uint64_t p = 0, q = 0;
/** Initialize CRC16 data */
- k1 = 0x189aeLLU;
- k2 = 0x8e10LLU;
+ k1 = 0x14ff2LLU;
+ k2 = 0x19a3cLLU;
+ k3 = 0x189aeLLU;
+ k4 = 0x8e10LLU;
k5 = 0x189aeLLU;
k6 = 0x114aaLLU;
q = 0x11c581910LLU;
@@ -249,12 +282,15 @@ rte_net_crc_sse42_init(void)
/** Save the params in context structure */
crc16_ccitt_pclmulqdq.rk1_rk2 = _mm_set_epi64x(k2, k1);
+ crc16_ccitt_pclmulqdq.rk3_rk4 = _mm_set_epi64x(k4, k3);
crc16_ccitt_pclmulqdq.rk5_rk6 = _mm_set_epi64x(k6, k5);
crc16_ccitt_pclmulqdq.rk7_rk8 = _mm_set_epi64x(p, q);
/** Initialize CRC32 data */
- k1 = 0xccaa009eLLU;
- k2 = 0x1751997d0LLU;
+ k1 = 0x1c6e41596LLU;
+ k2 = 0x154442bd4LLU;
+ k3 = 0xccaa009eLLU;
+ k4 = 0x1751997d0LLU;
k5 = 0xccaa009eLLU;
k6 = 0x163cd6124LLU;
q = 0x1f7011640LLU;
@@ -262,6 +298,7 @@ rte_net_crc_sse42_init(void)
/** Save the params in context structure */
crc32_eth_pclmulqdq.rk1_rk2 = _mm_set_epi64x(k2, k1);
+ crc32_eth_pclmulqdq.rk3_rk4 = _mm_set_epi64x(k4, k3);
crc32_eth_pclmulqdq.rk5_rk6 = _mm_set_epi64x(k6, k5);
crc32_eth_pclmulqdq.rk7_rk8 = _mm_set_epi64x(p, q);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v1 1/1] net/nbl: fix multicast reception in promiscuous mode
From: Dimon Zhao @ 2026-06-09 7:51 UTC (permalink / raw)
To: dev; +Cc: Dimon Zhao, stable, Leon Yu, Sam Chen
In-Reply-To: <20260609075143.32695-1-dimon.zhao@nebula-matrix.com>
When promiscuous mode is enabled on NBL PMD,
the hardware does not forward multicast frames to the host,
causing the driver to fail receiving multicast packets.
This patch fixes the issue.
Fixes: 80bd3cad22c8 ("net/nbl: support promiscuous mode")
Cc: stable@dpdk.org
Signed-off-by: Dimon Zhao <dimon.zhao@nebula-matrix.com>
---
drivers/net/nbl/nbl_dev/nbl_dev.c | 5 +++
drivers/net/nbl/nbl_dispatch.c | 45 +++++++++++++++++++
drivers/net/nbl/nbl_include/nbl_def_channel.h | 5 +++
.../net/nbl/nbl_include/nbl_def_resource.h | 2 +
4 files changed, 57 insertions(+)
diff --git a/drivers/net/nbl/nbl_dev/nbl_dev.c b/drivers/net/nbl/nbl_dev/nbl_dev.c
index 35485ea691..3c0e98d687 100644
--- a/drivers/net/nbl/nbl_dev/nbl_dev.c
+++ b/drivers/net/nbl/nbl_dev/nbl_dev.c
@@ -784,6 +784,8 @@ int nbl_promiscuous_enable(struct rte_eth_dev *eth_dev)
struct nbl_common_info *common = &adapter->common;
if (!common->is_vf) {
+ disp_ops->cfg_multi_mcast(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt),
+ dev_mgt->net_dev->vsi_id, 1);
disp_ops->set_promisc_mode(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt),
dev_mgt->net_dev->vsi_id, 1);
dev_mgt->net_dev->promisc = 1;
@@ -802,6 +804,8 @@ int nbl_promiscuous_disable(struct rte_eth_dev *eth_dev)
struct nbl_common_info *common = &adapter->common;
if (!common->is_vf) {
+ disp_ops->cfg_multi_mcast(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt),
+ dev_mgt->net_dev->vsi_id, 0);
disp_ops->set_promisc_mode(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt),
dev_mgt->net_dev->vsi_id, 0);
dev_mgt->net_dev->promisc = 0;
@@ -1012,6 +1016,7 @@ static void nbl_dev_leonis_stop(void *p)
disp_ops->del_multi_rule(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt), net_dev->vsi_id);
disp_ops->del_macvlan(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt), mac, 0, net_dev->vsi_id);
}
+ disp_ops->cfg_multi_mcast(NBL_DEV_MGT_TO_DISP_PRIV(dev_mgt), net_dev->vsi_id, 0);
}
static void nbl_dev_remove_ops(struct nbl_dev_ops_tbl **dev_ops_tbl)
diff --git a/drivers/net/nbl/nbl_dispatch.c b/drivers/net/nbl/nbl_dispatch.c
index 52d37ba7fe..f4f1ee4842 100644
--- a/drivers/net/nbl/nbl_dispatch.c
+++ b/drivers/net/nbl/nbl_dispatch.c
@@ -698,6 +698,47 @@ static void nbl_disp_chan_del_multi_rule_req(void *priv, u16 vsi)
chan_ops->send_msg(NBL_DISP_MGT_TO_CHAN_PRIV(disp_mgt), &chan_send);
}
+static int nbl_disp_cfg_multi_mcast(void *priv, u16 vsi, u16 enable)
+{
+ struct nbl_dispatch_mgt *disp_mgt = (struct nbl_dispatch_mgt *)priv;
+ struct nbl_resource_ops *res_ops = NBL_DISP_MGT_TO_RES_OPS(disp_mgt);
+ int ret = 0;
+
+ if (enable)
+ ret = NBL_OPS_CALL(res_ops->add_multi_mcast,
+ (NBL_DISP_MGT_TO_RES_PRIV(disp_mgt), vsi));
+ else
+ NBL_OPS_CALL(res_ops->del_multi_mcast, (NBL_DISP_MGT_TO_RES_PRIV(disp_mgt), vsi));
+
+ return ret;
+}
+
+static int nbl_disp_chan_cfg_multi_mcast_req(void *priv, u16 vsi, u16 enable)
+{
+ struct nbl_dispatch_mgt *disp_mgt = (struct nbl_dispatch_mgt *)priv;
+ const struct nbl_channel_ops *chan_ops = NBL_DISP_MGT_TO_CHAN_OPS(disp_mgt);
+ struct nbl_common_info *common = NBL_DISP_MGT_TO_COMMON(disp_mgt);
+ struct nbl_chan_param_cfg_multi_mcast param = {0};
+ struct nbl_chan_send_info chan_send;
+ int ret = 0;
+
+ if (NBL_IS_COEXISTENCE(common)) {
+ ret = ioctl(common->devfd, NBL_DEV_USER_SET_MCAST_MODE, &enable);
+ if (ret) {
+ NBL_LOG(ERR, "userspace send cfg_multi_mcast ioctl msg failed ret %d",
+ ret);
+ return ret;
+ }
+ return 0;
+ }
+
+ param.vsi = vsi;
+ param.enable = enable;
+ NBL_CHAN_SEND(chan_send, 0, NBL_CHAN_MSG_CFG_MULTI_MCAST_RULE,
+ ¶m, sizeof(param), NULL, 0, 1);
+ return chan_ops->send_msg(NBL_DISP_MGT_TO_CHAN_PRIV(disp_mgt), &chan_send);
+}
+
static int nbl_disp_cfg_dsch(void *priv, u16 vsi_id, bool vld)
{
struct nbl_dispatch_mgt *disp_mgt = (struct nbl_dispatch_mgt *)priv;
@@ -1145,6 +1186,10 @@ do { \
NBL_DISP_CTRL_LVL_MGT, \
NBL_CHAN_MSG_DEL_MULTI_RULE, \
nbl_disp_chan_del_multi_rule_req, NULL); \
+ NBL_DISP_SET_OPS(cfg_multi_mcast, nbl_disp_cfg_multi_mcast, \
+ NBL_DISP_CTRL_LVL_MGT, \
+ NBL_CHAN_MSG_CFG_MULTI_MCAST_RULE, \
+ nbl_disp_chan_cfg_multi_mcast_req, NULL); \
NBL_DISP_SET_OPS(cfg_dsch, nbl_disp_cfg_dsch, \
NBL_DISP_CTRL_LVL_MGT, NBL_CHAN_MSG_CFG_DSCH, \
nbl_disp_chan_cfg_dsch_req, NULL); \
diff --git a/drivers/net/nbl/nbl_include/nbl_def_channel.h b/drivers/net/nbl/nbl_include/nbl_def_channel.h
index 55880737f1..257c81e01e 100644
--- a/drivers/net/nbl/nbl_include/nbl_def_channel.h
+++ b/drivers/net/nbl/nbl_include/nbl_def_channel.h
@@ -371,6 +371,11 @@ struct nbl_chan_param_del_multi_rule {
u16 vsi;
};
+struct nbl_chan_param_cfg_multi_mcast {
+ u16 vsi;
+ u16 enable;
+};
+
struct nbl_chan_param_cfg_dsch {
u16 vsi_id;
bool vld;
diff --git a/drivers/net/nbl/nbl_include/nbl_def_resource.h b/drivers/net/nbl/nbl_include/nbl_def_resource.h
index 6935598789..a803c59dc0 100644
--- a/drivers/net/nbl/nbl_include/nbl_def_resource.h
+++ b/drivers/net/nbl/nbl_include/nbl_def_resource.h
@@ -77,6 +77,8 @@ struct nbl_resource_ops {
int (*add_multi_rule)(void *priv, u16 vsi_id);
void (*del_multi_rule)(void *priv, u16 vsi_id);
int (*cfg_multi_mcast)(void *priv, u16 vsi_id, u16 enable);
+ int (*add_multi_mcast)(void *priv, u16 vsi);
+ void (*del_multi_mcast)(void *priv, u16 vsi);
void (*clear_flow)(void *priv, u16 vsi_id);
int (*cfg_dsch)(void *priv, u16 vsi_id, bool vld);
int (*setup_cqs)(void *priv, u16 vsi_id, u16 real_qps, bool rss_indir_set);
--
2.34.1
^ permalink raw reply related
* [PATCH v1 0/1] fix NBL PMD multicast reception in promiscuous mode
From: Dimon Zhao @ 2026-06-09 7:51 UTC (permalink / raw)
To: dev; +Cc: Dimon Zhao
When promiscuous mode is enabled on NBL PMD,
the hardware does not forward multicast frames to the host,
causing the driver to fail receiving multicast packets.
This patch fixes the issue.
Dimon Zhao (1):
net/nbl: fix multicast reception in promiscuous mode
drivers/net/nbl/nbl_dev/nbl_dev.c | 5 +++
drivers/net/nbl/nbl_dispatch.c | 45 +++++++++++++++++++
drivers/net/nbl/nbl_include/nbl_def_channel.h | 5 +++
.../net/nbl/nbl_include/nbl_def_resource.h | 2 +
4 files changed, 57 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH 1/1] buildtools: remove absolute paths from pc file
From: Bruce Richardson @ 2026-06-09 7:47 UTC (permalink / raw)
To: Srikanth Yalavarthi; +Cc: dev
In-Reply-To: <20260609043220.930405-1-syalavarthi@marvell.com>
On Tue, Jun 09, 2026 at 10:02:20AM +0530, Srikanth Yalavarthi wrote:
> When linking with non-versioned libraries, absolute paths
> of the libraries are added to libdpdk.pc. This patch replaces
> the absolute path with correct linker flags, -l<libname>.
>
Do we need to check if we need a "-L" flag for some of these paths that are
stripped?
> https://github.com/mesonbuild/meson/issues/7766
>
> Signed-off-by: Srikanth Yalavarthi <syalavarthi@marvell.com>
> ---
> buildtools/pkg-config/set-static-linker-flags.py | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/buildtools/pkg-config/set-static-linker-flags.py b/buildtools/pkg-config/set-static-linker-flags.py
> index 2745db34c29..bd217b07fc8 100644
> --- a/buildtools/pkg-config/set-static-linker-flags.py
> +++ b/buildtools/pkg-config/set-static-linker-flags.py
> @@ -6,9 +6,16 @@
> # Should be called from meson build itself
> import os
> import sys
> +import re
>
>
> def fix_ldflag(f):
> + if f.startswith('/'):
> + libfile = os.path.basename(f)
> + m = re.match(r'^lib(.+?)\.(a|so(?:\..*)?)$', libfile)
> + if m:
> + return '-l' + m.group(1)
> +
> if not f.startswith('-lrte_'):
> return f
> return '-l:lib' + f[2:] + '.a'
> --
> 2.34.1
>
^ permalink raw reply
* [DPDK/ethdev Bug 1953] net/iavf: TX VLAN insertion offload has no effect on E810 in Double-VLAN-Mode (kernel iavf inserts fine on same PF)
From: bugzilla @ 2026-06-09 7:49 UTC (permalink / raw)
To: dev
http://bugs.dpdk.org/show_bug.cgi?id=1953
Bug ID: 1953
Summary: net/iavf: TX VLAN insertion offload has no effect on
E810 in Double-VLAN-Mode (kernel iavf inserts fine on
same PF)
Product: DPDK
Version: 26.03
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: g.navinsrinivas@gmail.com
Target Milestone: ---
Created attachment 354
--> http://bugs.dpdk.org/attachment.cgi?id=354&action=edit
The logs, pcap for both DPDK 25.11 and 26.03 and behaviour difference with
Kernel vlan tagging
On an Intel E810 with the PF in Double‑VLAN‑Mode (DVM), an iavf VF bound to
vfio-pci does not insert a TX VLAN tag — frames egress untagged despite
tx_offload vlan_insert on + tx_vlan set (and with
insertion enabled / insertion_cap: L2TAG2). The in-tree kernel iavf on the same
PF / adjacent VF inserts the single C‑VLAN correctly (802.1Q on the wire).
Forcing inner/L2TAG1 in the PMD doesn't help
either. Reproduced with vanilla dpdk-testpmd on both DPDK 25.11 and 26.03.
Env: E810 fw 7.9.1 / nvm 4.90 / DDP "ICE OS Default Package 1.3.49.0"; host ice
on kernel 6.8.12‑pve; guest iavf 6.17. VF VLAN_V2 caps: ins_outer=0xc0000207
(TOGGLE|XOR|L2TAG2|{8100,88A8,9100}),
ins_inner=0x80000101 (TOGGLE|L2TAG1|8100), VF_OFFLOAD_VLAN(v1)=0. Logs/pcaps
attached (per-version + kernel contrast).
On an Intel E810 with the PF in Double-VLAN-Mode (DVM), an iavf VF bound to
vfio-pci does not insert a TX VLAN tag — frames egress untagged despite
tx_offload vlan_insert on + tx_vlan set (and with insertion enabled /
insertion_cap: L2TAG2). The in-tree kernel iavf on the same PF / adjacent VF
inserts the single C-VLAN correctly (802.1Q on the wire). Forcing inner/L2TAG1
in the PMD doesn't help either. Reproduced with vanilla dpdk-testpmd on both
DPDK 25.11 and 26.03.
Reproduction (testpmd):
dpdk-testpmd -a <vf_pci> --file-prefix=tp -l <cores> -- -i
--eth-peer=0,<peer_mac>
port stop 0
port config 0 tx_offload vlan_insert on
tx_vlan set 0 20
port start 0
set fwd txonly
start
- tcpdump on the peer: frames arrive as plain ethertype IPv4 — no 802.1Q / vlan
20.
- show port xstats: tx_good counts up (frames do leave the VF; no Tx error).
Expected: egress frames carry 802.1Q vlan 20.
Actual: egress frames are untagged; tx_good increments, no Tx error reported.
Ruled out: VF was trust on, spoofchk off, and the VLAN filter added via
rte_eth_dev_vlan_filter() (vlan offload: filter on) — no change. Same result on
25.11 and 26.03, and with the PMD forced to inner/L2TAG1. The kernel iavf on
the same PF (adjacent VF) inserts the tag correctly, so the PF/HW and VF config
are fine — only the DPDK iavf PMD insertion path produces no tag.
Environment: E810 fw 7.9.1 / nvm 4.90 / DDP "ICE OS Default Package 1.3.49.0";
host ice on kernel 6.8.12-pve; guest iavf 6.17. VF VLAN_V2 caps:
ins_outer=0xc0000207 (TOGGLE|XOR|L2TAG2|{8100,88A8,9100}), ins_inner=0x80000101
(TOGGLE|L2TAG1|8100), VF_OFFLOAD_VLAN(v1)=0. Logs/pcaps attached (per-version +
kernel contrast).
--
You are receiving this mail because:
You are the assignee for the bug.
^ 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