* 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: [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: [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] 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: remove unreachable hash action case
From: Bruce Richardson @ 2026-06-09 10:12 UTC (permalink / raw)
To: Artem Novikov; +Cc: Vladimir Medvedkin, Qi Zhang, Jeff Guo, dev, stable
In-Reply-To: <20260604161354.95602-1-naa@amicon.ru>
On Thu, Jun 04, 2026 at 07:13:53PM +0300, Artem Novikov wrote:
> The hash action parser stops iterating when it reaches
> RTE_FLOW_ACTION_TYPE_END. The switch below uses action_type copied
> directly from action->type inside that loop, so the END case cannot be
> selected.
>
> Remove the unreachable case. No functional change.
>
> Fixes: 7be10c3004be ("net/iavf: add RSS configuration for VF")
> Cc: stable@dpdk.org
> Cc: jia.guo@intel.com
>
> Signed-off-by: Artem Novikov <naa@amicon.ru>
> ---
> drivers/net/intel/iavf/iavf_hash.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_hash.c b/drivers/net/intel/iavf/iavf_hash.c
> index 217f0500ab..7ce7b86d8e 100644
> --- a/drivers/net/intel/iavf/iavf_hash.c
> +++ b/drivers/net/intel/iavf/iavf_hash.c
> @@ -1490,8 +1490,6 @@ iavf_hash_parse_action(struct iavf_pattern_match_item *match_item,
> rss_type, pattern_hint);
> break;
>
> - case RTE_FLOW_ACTION_TYPE_END:
> - break;
>
> default:
> rte_flow_error_set(error, EINVAL,
This code is no longer present, following the recent rework of Intel driver
flow parsing, done by Anatoly. Therefore marking this as "not applicable"
in patchwork.
Thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: Thomas Monjalon @ 2026-06-09 10:19 UTC (permalink / raw)
To: liujie5@linkdatatechnology.com; +Cc: stephen, dev
In-Reply-To: <202606091748234877352@linkdatatechnology.com>
09/06/2026 11:48, liujie5@linkdatatechnology.com:
> 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.
OK thank you, it's clear.
^ permalink raw reply
* Re: [PATCH 1/2] net/ice: revert fix link up when starting device
From: Bruce Richardson @ 2026-06-09 10:20 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev
In-Reply-To: <20260603143407.1108527-2-ciara.loftus@intel.com>
On Wed, Jun 03, 2026 at 02:34:06PM +0000, Ciara Loftus wrote:
> This reverts commit 6c76b76dc64183eb2f24a52b90d4ff9feb4872f4.
>
> The reverted commit worked around a potential timing issue where the
> link could be reported down immediately after the link was enabled
> during device start. The commit introduced a blocking wait which gave
> the driver a better chance to read the correct link state before
> returning from device start. However, since the auto link update flag is
> set when setting the link up in device start, an adminq notification
> should arrive once the link is up, which will be handled and correctly
> set the link status. This means we can remove the delay from device
> start as it does not need to guarantee link up before returning.
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* 回复：[PATCH] gpu/metax: add new driver for Metax GPU
From: 许玲燕 @ 2026-06-09 10:22 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, eagostini
In-Reply-To: <CsAn75rzSb2jiQLRSeXkmQ@monjalon.net>
[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]
Hi,
Thank you for the detailed feedback and for reviewing the proposal for the Metax GPU driver.
Based on the questions raised and the analysis of the code implementation, here are the clarifications and my action plan:
1. Regarding GPU Access Method
The driver interfaces with the Metax GPU hardware through a combination of the vendor-provided MC Runtime (Metax Compute Runtime) library and GDRCopy (GPU Direct RDMA) technology.
*
User-space Library: As seen in the maca.c code, the driver dynamically loads (dlopen) the libmcruntime.so library. It uses mc_runtime_api.h to manage GPU contexts, memory allocation, and device attributes.
*
Kernel Module: The driver relies on the underlying Metax kernel driver (for PCI probing and basic device access) and the gdrapi (GDRCopy) kernel module to facilitate zero-copy data transfer between CPU and GPU memory.
*
Dependency: The build log confirms the detection of headers like mc_runtime_api.h and gdrapi.h, which are essential for this integration.
2. Clarification on "Rendering" Functionality
I apologize for the confusion caused by the term "Rendering" in the initial description. Upon reviewing the code and your feedback, I realize this was an inaccurate choice of words.
*
Correction: The intended functionality is purely "Compute/Data Processing" and "Memory Management".
*
Explanation: The driver's core logic (as shown in the patch) focuses on memory registration, allocation, and CPU/GPU data synchronization (via maca_mem_cpu_map and gdrcopy_pin), which are essential for network data processing acceleration rather than graphical rendering. I will correct this terminology in the documentation to avoid further confusion.
3. Action Plan: Following the Contribution Guide
I have reviewed the <"Adding a New Driver"> guide you linked.
*
Patch Splitting: I understand that the current monolithic patch is not suitable. I will rework the submission and split it into a logical patch series:
*
Patch 1: Add the basic infrastructure (Meson files, maintainers, configuration).
*
Patch 2: Implement core device functionality (PCI probing, initialization, context management).
*
Patch 3: Add memory management and data path features (allocation, registration, and CPU mapping).
Thank you again for your guidance. I will resubmit the revised patch series shortly.
Best regards,
Lingyan Xu
------------------------------------------------------------------
发件人：Thomas Monjalon <thomas@monjalon.net>
发送时间：2026年6月2日(周二) 18:01
收件人："许玲燕"<lingyan.xu@metax-tech.com>
抄 送：dev<dev@dpdk.org>; eagostini<eagostini@nvidia.com>
主 题：Re: [PATCH] gpu/metax: add new driver for Metax GPU
Hello,
01/06/2026 07:47, 许玲燕:
> I am writing to propose a new driver for the Metax GPU,
How do you access the GPU?
Are you using a specific library or kernel module?
> which I believe will significantly enhance our support
> and performance for this hardware.
> The patch attached includes the initial implementation of the driver,
> with key features such as:
>
> * Basic initialization and configuration
> * Memory management and allocation
> * Core functionality for rendering and compute tasks
I am familiar with connecting compute tasks of a GPU
with DPDK networking, but I'm surprised by the rendering functionality.
Do you mean graphical rendering of data coming from the network?
> Please review the code and let me know if you have any feedback or suggestions.
> I am more than happy to make any necessary adjustments and improvements.
Thank you for working on this.
I recommend following this guide to introduce a new driver:
https://doc.dpdk.org/guides/contributing/new_driver.html <https://doc.dpdk.org/guides/contributing/new_driver.html >
超大附件列表 dpdk-build-test-log.txt [48KB]
进入下载页面 https://qiye.aliyun.com/alimail/openLinks/downloadMimeMetaDiskBigAttach?id=netdiskid%3Av001%3Afile%3ADzzzzzzNqZx%3BJYiJwCficINAoHh55iyjKdydQzW5hDE%2FGjddF2Xp4ghl2ujmlGlWdfhgNCLOb5s3BZAHvDXTdZhtzGA3q8HJ%2Fv%2FPGnrPJfO1Xc%2BWnHr%2FKRwIkHzWFe5Iwm1IZrurr9hW
[-- Attachment #2: Type: text/html, Size: 132113 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net/i40e: fix blocking link wait on device start
From: Bruce Richardson @ 2026-06-09 10:22 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev, stable
In-Reply-To: <20260603143407.1108527-3-ciara.loftus@intel.com>
On Wed, Jun 03, 2026 at 02:34:07PM +0000, Ciara Loftus wrote:
> Currently, device start performs a synchronous link status update,
> blocking for up to one second if the link is not yet up. This causes
> unnecessary startup delay in scenarios where the link partner is slow to
> come up or unavailable.
>
> The wait was introduced alongside the maximum frame size MAC config
> command. Some devices require the link to be up before issuing that
> command, so the solution was to block at device start until link was
> established.
>
> To address the issue, remove the unconditional blocking wait. Take note
> if the link was down at the time of the MAC config command during device
> start and if it was, re-issue the command upon notification of the first
> link-up event.
>
> In the case where all interrupt vectors are consumed by Rx queues, no
> interrupt or alarm handler is available to process link-up events. The
> blocking wait is retained for this narrow case to preserve correctness.
>
> Fixes: 82fcf20d039c ("net/i40e: fix maximum frame size configuration")
> Cc: stable@dpdk.org
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [PATCH v8 0/4] IEEE 1588 PTP v2 protocol support in lib/net
From: Thomas Monjalon @ 2026-06-09 10:32 UTC (permalink / raw)
To: Rajesh Kumar; +Cc: dev, bruce.richardson, aman.deep.singh, stephen, mb
In-Reply-To: <20260509232551.2844201-1-rajesh3.kumar@intel.com>
> Rajesh Kumar (4):
> lib/net: add IEEE 1588 PTP v2 protocol header definitions
> examples/ptp_tap_relay_sw: add PTP software transparent clock relay
> doc: update release notes for PTP protocol library
> examples/ptpclient: use shared PTP library definitions
Squashed in 2 atomic commits (lib and new example), thanks.
^ permalink raw reply
* Re: 回复：[PATCH] gpu/metax: add new driver for Metax GPU
From: Thomas Monjalon @ 2026-06-09 10:43 UTC (permalink / raw)
To: 许玲燕; +Cc: dev, eagostini
In-Reply-To: <fbe7f8ce-f680-411a-a7a6-82eda60300de.lingyan.xu@metax-tech.com>
Thank you for the detailed answer and your understanding.
One more question: are the lib and module upstreamed already?
09/06/2026 12:22, 许玲燕:
> Hi,
> Thank you for the detailed feedback and for reviewing the proposal for the Metax GPU driver.
> Based on the questions raised and the analysis of the code implementation, here are the clarifications and my action plan:
> 1. Regarding GPU Access Method
> The driver interfaces with the Metax GPU hardware through a combination of the vendor-provided MC Runtime (Metax Compute Runtime) library and GDRCopy (GPU Direct RDMA) technology.
>
> *
> User-space Library: As seen in the maca.c code, the driver dynamically loads (dlopen) the libmcruntime.so library. It uses mc_runtime_api.h to manage GPU contexts, memory allocation, and device attributes.
>
> *
> Kernel Module: The driver relies on the underlying Metax kernel driver (for PCI probing and basic device access) and the gdrapi (GDRCopy) kernel module to facilitate zero-copy data transfer between CPU and GPU memory.
>
> *
> Dependency: The build log confirms the detection of headers like mc_runtime_api.h and gdrapi.h, which are essential for this integration.
> 2. Clarification on "Rendering" Functionality
> I apologize for the confusion caused by the term "Rendering" in the initial description. Upon reviewing the code and your feedback, I realize this was an inaccurate choice of words.
>
> *
> Correction: The intended functionality is purely "Compute/Data Processing" and "Memory Management".
>
> *
> Explanation: The driver's core logic (as shown in the patch) focuses on memory registration, allocation, and CPU/GPU data synchronization (via maca_mem_cpu_map and gdrcopy_pin), which are essential for network data processing acceleration rather than graphical rendering. I will correct this terminology in the documentation to avoid further confusion.
> 3. Action Plan: Following the Contribution Guide
> I have reviewed the <"Adding a New Driver"> guide you linked.
>
> *
> Patch Splitting: I understand that the current monolithic patch is not suitable. I will rework the submission and split it into a logical patch series:
> *
> Patch 1: Add the basic infrastructure (Meson files, maintainers, configuration).
>
> *
> Patch 2: Implement core device functionality (PCI probing, initialization, context management).
>
> *
> Patch 3: Add memory management and data path features (allocation, registration, and CPU mapping).
> Thank you again for your guidance. I will resubmit the revised patch series shortly.
> Best regards,
> Lingyan Xu
> ------------------------------------------------------------------
> 发件人：Thomas Monjalon <thomas@monjalon.net>
> 发送时间：2026年6月2日(周二) 18:01
> 收件人："许玲燕"<lingyan.xu@metax-tech.com>
> 抄 送：dev<dev@dpdk.org>; eagostini<eagostini@nvidia.com>
> 主 题：Re: [PATCH] gpu/metax: add new driver for Metax GPU
> Hello,
> 01/06/2026 07:47, 许玲燕:
> > I am writing to propose a new driver for the Metax GPU,
> How do you access the GPU?
> Are you using a specific library or kernel module?
> > which I believe will significantly enhance our support
> > and performance for this hardware.
> > The patch attached includes the initial implementation of the driver,
> > with key features such as:
> >
> > * Basic initialization and configuration
> > * Memory management and allocation
> > * Core functionality for rendering and compute tasks
> I am familiar with connecting compute tasks of a GPU
> with DPDK networking, but I'm surprised by the rendering functionality.
> Do you mean graphical rendering of data coming from the network?
> > Please review the code and let me know if you have any feedback or suggestions.
> > I am more than happy to make any necessary adjustments and improvements.
> Thank you for working on this.
> I recommend following this guide to introduce a new driver:
> https://doc.dpdk.org/guides/contributing/new_driver.html <https://doc.dpdk.org/guides/contributing/new_driver.html >
>
>
> 超大附件列表 dpdk-build-test-log.txt [48KB]
> 进入下载页面 https://qiye.aliyun.com/alimail/openLinks/downloadMimeMetaDiskBigAttach?id=netdiskid%3Av001%3Afile%3ADzzzzzzNqZx%3BJYiJwCficINAoHh55iyjKdydQzW5hDE%2FGjddF2Xp4ghl2ujmlGlWdfhgNCLOb5s3BZAHvDXTdZhtzGA3q8HJ%2Fv%2FPGnrPJfO1Xc%2BWnHr%2FKRwIkHzWFe5Iwm1IZrurr9hW
>
^ permalink raw reply
* RE: [PATCH v4] net/iavf: fix duplicate VF reset during PF reset recovery
From: Loftus, Ciara @ 2026-06-09 10:52 UTC (permalink / raw)
To: Mandal, Anurag, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <20260608162936.354248-1-anurag.mandal@intel.com>
> Subject: [PATCH v4] net/iavf: fix duplicate VF reset during PF reset recovery
>
> During PF initiated reset recovery, iavf_dev_close() sending
> an extra VIRTCHNL_OP_RESET_VF while recovery is already in progress.
> That second reset can leave PF/VF virtchnl state inconsistent and
> cause VIRTCHNL_OP_CONFIG_VSI_QUEUES to fail with ERR_PARAM after
> ToR link flap/power-cycle, leaving the VF unable to recover.
> This results in connection loss.
>
> This patch skipped close-time VF reset and related close-time
> virtchnl operations when PF triggered reset recovery is set.
> This is done to avoid a duplicate VF reset, and keep normal
> behavior for application-driven close.
>
> Fixes: 675a104e2e94 ("net/iavf: fix abnormal disable HW interrupt")
> Fixes: b34fe66ea893 ("net/iavf: delay VF reset command")
> Fixes: 5e03e316c753 ("net/iavf: handle virtchnl event message without
> interrupt")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> ---
> V4: Addressed Ciara Loftus comments
> - split VF reset from other code changes
> V3: Addressed latest ai-code-review comments
> V2: Addressed ai-code-review comments
>
> doc/guides/rel_notes/release_26_07.rst | 3 +++
> drivers/net/intel/iavf/iavf_ethdev.c | 37 +++++++++++++++-----------
> drivers/net/intel/iavf/iavf_vchnl.c | 18 ++++++++++---
> 3 files changed, 39 insertions(+), 19 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_26_07.rst
> b/doc/guides/rel_notes/release_26_07.rst
> index d2563ac503..f6899a78c3 100644
> --- a/doc/guides/rel_notes/release_26_07.rst
> +++ b/doc/guides/rel_notes/release_26_07.rst
> @@ -95,6 +95,9 @@ New Features
>
> * Added support for transmitting LLDP packets based on mbuf packet type.
> * Implemented AVX2 context descriptor transmit paths.
> + * Prevented duplicate 'VIRTCHNL_OP_RESET_VF' during a PF-initiated
> + reset recovery, which earlier caused virtchnl state corruption
> + and connection loss after a top-of-rack (ToR) link flap/power-cycle.
>
> * **Updated PCAP ethernet driver.**
>
> diff --git a/drivers/net/intel/iavf/iavf_ethdev.c
> b/drivers/net/intel/iavf/iavf_ethdev.c
> index a8031e23a5..99457ae510 100644
> --- a/drivers/net/intel/iavf/iavf_ethdev.c
> +++ b/drivers/net/intel/iavf/iavf_ethdev.c
> @@ -3166,24 +3166,27 @@ iavf_dev_close(struct rte_eth_dev *dev)
>
> ret = iavf_dev_stop(dev);
>
> - /*
> - * Release redundant queue resource when close the dev
> - * so that other vfs can re-use the queues.
> - */
> - if (vf->lv_enabled) {
> - ret = iavf_request_queues(dev,
> IAVF_MAX_NUM_QUEUES_DFLT);
> - if (ret)
> - PMD_DRV_LOG(ERR, "Reset the num of queues
> failed");
> + /* Skip RESET_VF on a PF-initiated reset */
> + if (!adapter->closed && !vf->in_reset_recovery) {
adapter->closed will always be false here so no need to check it.
vf->in_reset_recovery is set for a VF initiated reset as well which does
require sending VIRTCHNL_OP_RESET_VF because that kicks off the reset.
(rte_pmd_iavf_reinit -> handle_hw_reset is the vf initiated reset path.)
We need some way to know if we are currently handling a PF initiated
reset here. Another adapter flag, or else make in_reset_recovery
tri-state eg. 0 (no reset) 1 (pf initiated) 2 (vf initiated)
Then skip the OP_RESET_VF if pf initiated.
> + /*
> + * Release redundant queue resource when close the dev
> + * so that other vfs can re-use the queues.
> + */
> + if (vf->lv_enabled) {
> + ret = iavf_request_queues(dev,
> IAVF_MAX_NUM_QUEUES_DFLT);
> + if (ret)
> + PMD_DRV_LOG(ERR, "Reset the num of
> queues failed");
> + vf->max_rss_qregion =
> IAVF_MAX_NUM_QUEUES_DFLT;
> + }
>
> - vf->max_rss_qregion = IAVF_MAX_NUM_QUEUES_DFLT;
> + /*
> + * Disable promiscuous mode before resetting the VF. This is to
> avoid
> + * potential issues when the PF is bound to the kernel driver.
> + */
> + if (vf->promisc_unicast_enabled || vf-
> >promisc_multicast_enabled)
> + iavf_config_promisc(adapter, false, false);
> }
>
> - /* Disable promiscuous mode before resetting the VF. This is to avoid
> - * potential issues when the PF is bound to the kernel driver.
> - */
> - if (vf->promisc_unicast_enabled || vf->promisc_multicast_enabled)
> - iavf_config_promisc(adapter, false, false);
> -
> adapter->closed = true;
>
> /* free iAVF security device context all related resources */
> @@ -3195,7 +3198,9 @@ iavf_dev_close(struct rte_eth_dev *dev)
> iavf_flow_flush(dev, NULL);
> iavf_flow_uninit(adapter);
>
> - iavf_vf_reset(hw);
> + /* Skip RESET_VF on a PF-initiated reset */
> + if (!vf->in_reset_recovery)
> + iavf_vf_reset(hw);
> vf->aq_intr_enabled = false;
> iavf_shutdown_adminq(hw);
> if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_WB_ON_ITR)
> {
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> index 94ccfb5d6e..cf3513ef94 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -283,9 +283,21 @@ iavf_read_msg_from_pf(struct iavf_adapter
> *adapter, uint16_t buf_len,
> vf->link_up ? "up" : "down");
> break;
> case VIRTCHNL_EVENT_RESET_IMPENDING:
> - vf->vf_reset = true;
> - iavf_set_no_poll(adapter, false);
> - PMD_DRV_LOG(INFO, "VF is resetting");
> + /*
> + * Force link down on impending reset to drop
> + * the cached link-up state; a fresh LSC up
> + * event will be re-issued by the PF once the
> + * VF is reinitialised.
> + */
> + vf->link_up = false;
> + if (!vf->vf_reset) {
> + vf->vf_reset = true;
> + iavf_set_no_poll(adapter, false);
> + iavf_dev_event_post(vf->eth_dev,
> + RTE_ETH_EVENT_INTR_RESET,
> + NULL, 0);
> + }
> + PMD_DRV_LOG(DEBUG, "VF is resetting");
> break;
> case VIRTCHNL_EVENT_PF_DRIVER_CLOSE:
> vf->dev_closed = true;
> --
> 2.34.1
^ permalink raw reply
* RE: [PATCH] net/iavf: fix to consolidate link change event handling
From: Mandal, Anurag @ 2026-06-09 10:53 UTC (permalink / raw)
To: Loftus, Ciara, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <IA4PR11MB92782B6A7F4F58953DE954DE8E1D2@IA4PR11MB9278.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Loftus, Ciara <ciara.loftus@intel.com>
> Sent: 09 June 2026 15:32
> To: Mandal, Anurag <anurag.mandal@intel.com>; dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; Medvedkin, Vladimir
> <vladimir.medvedkin@intel.com>; stable@dpdk.org
> Subject: RE: [PATCH] net/iavf: fix to consolidate link change event handling
>
> > 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.
Hi Ciara,
Thanks for the review. Initially I also did not add. Then I added it as per suggestions from ai-code-review run by DPDK. Funny thing is now, it is saying " overly defensive checks". So not sure, which suggestion of ai-cdoe-review to follow.
Please guide. Will act accordingly.
Thanks,
Anuarg
>
> > +
> > + 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: Re: [PATCH v14 00/20] net/sxe2: added Linkdata sxe2 ethernet driver
From: liujie5 @ 2026-06-09 11:10 UTC (permalink / raw)
To: 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: [PATCH 1/2] net/ice: revert fix link up when starting device
From: Bruce Richardson @ 2026-06-09 11:55 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev
In-Reply-To: <20260603143407.1108527-2-ciara.loftus@intel.com>
On Wed, Jun 03, 2026 at 02:34:06PM +0000, Ciara Loftus wrote:
> This reverts commit 6c76b76dc64183eb2f24a52b90d4ff9feb4872f4.
>
> The reverted commit worked around a potential timing issue where the
> link could be reported down immediately after the link was enabled
> during device start. The commit introduced a blocking wait which gave
> the driver a better chance to read the correct link state before
> returning from device start. However, since the auto link update flag is
> set when setting the link up in device start, an adminq notification
> should arrive once the link is up, which will be handled and correctly
> set the link status. This means we can remove the delay from device
> start as it does not need to guarantee link up before returning.
>
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
> drivers/net/intel/ice/ice_ethdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Should this revert be marked for backport, or is it safer to keep the LTS's
as they are?
^ permalink raw reply
* [PATCH v2] net/iavf: fix misleading AQ failure logging
From: Anurag Mandal @ 2026-06-09 12:00 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, vladimir.medvedkin, ciara.loftus, Anurag Mandal,
stable
In-Reply-To: <20260608171559.355521-1-anurag.mandal@intel.com>
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>
---
V2: Addressed Ciara Loftus's comment
- kept 'break" for ret == IAVF_ERR_ADMIN_QUEUE_NO_WORK case
drivers/net/intel/iavf/iavf_vchnl.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
index 94ccfb5d6e..39ebddff31 100644
--- a/drivers/net/intel/iavf/iavf_vchnl.c
+++ b/drivers/net/intel/iavf/iavf_vchnl.c
@@ -571,8 +571,16 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev)
ret = iavf_clean_arq_element(hw, &info, &pending);
if (ret != IAVF_SUCCESS) {
- PMD_DRV_LOG(INFO, "Failed to read msg from AdminQ,"
- "ret: %d", ret);
+ /*
+ * 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_ERR_ADMIN_QUEUE_NO_WORK)
+ PMD_DRV_LOG(INFO, "Failed to read msg from AdminQ,"
+ "ret: %d", ret);
break;
}
aq_opc = rte_le_to_cpu_16(info.desc.opcode);
--
2.34.1
^ permalink raw reply related
* RE: [PATCH] net/iavf: fix misleading AQ failure logging
From: Mandal, Anurag @ 2026-06-09 12:04 UTC (permalink / raw)
To: Loftus, Ciara, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <IA4PR11MB9278A4729FF823D93BE849988E1D2@IA4PR11MB9278.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Loftus, Ciara <ciara.loftus@intel.com>
> Sent: 09 June 2026 13:44
> To: Mandal, Anurag <anurag.mandal@intel.com>; dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; Medvedkin, Vladimir
> <vladimir.medvedkin@intel.com>; stable@dpdk.org
> Subject: RE: [PATCH] net/iavf: fix misleading AQ failure logging
>
> > 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.
Hi Ciara,
Thanks for the review. I checked. You are correct.
Sent v2 with proper fix.
Please review. Thanks!
Thanks,
Anurag
^ permalink raw reply
* RE: [PATCH v2] net/iavf: fix misleading AQ failure logging
From: Loftus, Ciara @ 2026-06-09 12:30 UTC (permalink / raw)
To: Mandal, Anurag, dev@dpdk.org
Cc: Richardson, Bruce, Medvedkin, Vladimir, stable@dpdk.org
In-Reply-To: <20260609120050.360907-1-anurag.mandal@intel.com>
> Subject: [PATCH v2] 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>
Thanks Anurag.
Acked-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
> V2: Addressed Ciara Loftus's comment
> - kept 'break" for ret == IAVF_ERR_ADMIN_QUEUE_NO_WORK case
>
> drivers/net/intel/iavf/iavf_vchnl.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
> b/drivers/net/intel/iavf/iavf_vchnl.c
> index 94ccfb5d6e..39ebddff31 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -571,8 +571,16 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev)
> ret = iavf_clean_arq_element(hw, &info, &pending);
>
> if (ret != IAVF_SUCCESS) {
> - PMD_DRV_LOG(INFO, "Failed to read msg from
> AdminQ,"
> - "ret: %d", ret);
> + /*
> + * 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_ERR_ADMIN_QUEUE_NO_WORK)
> + PMD_DRV_LOG(INFO, "Failed to read msg
> from AdminQ,"
> + "ret: %d", ret);
> break;
> }
> aq_opc = rte_le_to_cpu_16(info.desc.opcode);
> --
> 2.34.1
^ permalink raw reply
* [PATCH v3] dts: add retry loop to trex traffic generation
From: Andrew Bailey @ 2026-06-09 12:41 UTC (permalink / raw)
To: luca.vizzarro, patrickrobb1997
Cc: dev, ahassick, knimoji, lylavoie, Andrew Bailey
In-Reply-To: <20260518175424.253600-1-abailey@iol.unh.edu>
There was an issue where the single core forward test would report zero
MPPS intermittently. This was due to TREX reporting that the link was
down when the client was called to start generating traffic. The links
were being reported down by TREX on the tg even when testpmd was
reporting them up on the SUT. Adding a retry loop to the generate
traffic method of TREX gives the tg enough time to set up and send
traffic.
Bugzilla ID: 1946
Fixes: d77d7f04f24c ("dts: add single-core performance test suite")
Signed-off-by: Andrew Bailey <abailey@iol.unh.edu>
---
.../testbed_model/traffic_generator/trex.py | 36 ++++++++++++++-----
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/dts/framework/testbed_model/traffic_generator/trex.py b/dts/framework/testbed_model/traffic_generator/trex.py
index 22cd20dea9..b1a3a6ceac 100644
--- a/dts/framework/testbed_model/traffic_generator/trex.py
+++ b/dts/framework/testbed_model/traffic_generator/trex.py
@@ -13,6 +13,7 @@
from framework.config.node import OS, NodeConfiguration
from framework.config.test_run import TrexTrafficGeneratorConfig
+from framework.exception import SSHTimeoutError
from framework.parser import TextParser
from framework.remote_session.blocking_app import BlockingApp
from framework.remote_session.python_shell import PythonShell
@@ -220,7 +221,9 @@ def _create_packet_stream(self, packet: Packet) -> None:
]
self._shell.send_command("\n".join(packet_stream))
- def _send_traffic_and_get_stats(self, duration: float, send_mpps: float | None = None) -> str:
+ def _send_traffic_and_get_stats(
+ self, duration: float, send_mpps: float | None = None, retry_attempts: int = 5
+ ) -> str:
"""Send traffic and get TG Rx stats.
Sends traffic from the TRex client's ports for the given duration.
@@ -230,15 +233,30 @@ def _send_traffic_and_get_stats(self, duration: float, send_mpps: float | None =
Args:
duration: The traffic generation duration.
send_mpps: The millions of packets per second for TRex to send from each port.
+ retry_attempts: The number of times to retry this command on failure.
+
+ Raises:
+ SSHTimeoutError: If TRex fails to send traffic in the allotted attempts.
"""
- if send_mpps:
- self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
- mult = '{send_mpps}mpps',
- duration = {duration})""")
- else:
- self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
- mult = '100%',
- duration = {duration})""")
+ link_up = False
+ attempt = 0
+
+ while not link_up and attempt < retry_attempts:
+ if send_mpps:
+ result = self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
+ mult = '{send_mpps}mpps',
+ duration = {duration})""")
+ else:
+ result = self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
+ mult = '100%',
+ duration = {duration})""")
+ link_up = "link is DOWN" not in result
+ if not link_up:
+ self._logger.info(
+ f"Generate traffic command failed (attempt {attempt + 1} of {retry_attempts})"
+ )
+ time.sleep(0.25)
+ attempt += 1
time.sleep(duration)
--
2.54.0
^ permalink raw reply related
* RE: [PATCH 1/2] net/ice: revert fix link up when starting device
From: Loftus, Ciara @ 2026-06-09 12:53 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev@dpdk.org
In-Reply-To: <aif_MR9pNjdT9S21@bricha3-mobl1.ger.corp.intel.com>
> Subject: Re: [PATCH 1/2] net/ice: revert fix link up when starting device
>
> On Wed, Jun 03, 2026 at 02:34:06PM +0000, Ciara Loftus wrote:
> > This reverts commit 6c76b76dc64183eb2f24a52b90d4ff9feb4872f4.
> >
> > The reverted commit worked around a potential timing issue where the
> > link could be reported down immediately after the link was enabled
> > during device start. The commit introduced a blocking wait which gave
> > the driver a better chance to read the correct link state before
> > returning from device start. However, since the auto link update flag is
> > set when setting the link up in device start, an adminq notification
> > should arrive once the link is up, which will be handled and correctly
> > set the link status. This means we can remove the delay from device
> > start as it does not need to guarantee link up before returning.
> >
> > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > ---
> > drivers/net/intel/ice/ice_ethdev.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> Should this revert be marked for backport, or is it safer to keep the LTS's
> as they are?
I think it shouldn't be marked for backport.
With this patch we now rely on the adminq link status notification to
correct an incorrect link status read at dev_start. That requires commit
e01265e4a9bf ("net/ice: get link status updates via adminq message")
which was only introduced this year and not present in any LTS.
^ permalink raw reply
* [PATCH v3] dts: add support for no link topology
From: Andrew Bailey @ 2026-06-09 13:11 UTC (permalink / raw)
To: luca.vizzarro
Cc: patrickrobb1997, dev, ahassick, knimoji, lylavoie, Andrew Bailey
In-Reply-To: <20260220192510.37163-1-abailey@iol.unh.edu>
Add support for running DTS with no traffic generator node and no ethdev
interfaces. Some applications, like dpdk-test-crypto-perf run without
ethdev interfaces and no traffic generator. In these cases, it is
beneficial to remove the overhead of creating a node and ports that are
not used. The specified build option for ice devices is removed since
the query to sut port ingress causes python to crash when there are no
ports. Notably, since this is only the case in which there are no ports,
traffic will not be sent and therefore the build argument is not
required. For these reasons it is skipped when running a no-link
topology.
Signed-off-by: Andrew Bailey <abailey@iol.unh.edu>
---
dts/api/test.py | 8 +++++---
dts/configurations/test_run.example.yaml | 2 +-
dts/framework/config/__init__.py | 16 ++++++++-------
dts/framework/config/test_run.py | 4 ++--
dts/framework/context.py | 2 +-
dts/framework/remote_session/dpdk.py | 4 +++-
dts/framework/test_run.py | 25 ++++++++++++++----------
dts/framework/testbed_model/topology.py | 17 +++++++++++-----
8 files changed, 48 insertions(+), 30 deletions(-)
diff --git a/dts/api/test.py b/dts/api/test.py
index e17babe0ca..046f1778a5 100644
--- a/dts/api/test.py
+++ b/dts/api/test.py
@@ -109,12 +109,14 @@ def fail(failure_description: str) -> None:
Raises:
TestCaseVerifyError: Always raised to indicate the test case failed.
"""
+ ctx = get_ctx()
get_logger().debug("A test case failed, showing the last 10 commands executed on SUT:")
- for command_res in get_ctx().sut_node.main_session.remote_session.history[-10:]:
+ for command_res in ctx.sut_node.main_session.remote_session.history[-10:]:
get_logger().debug(command_res.command)
get_logger().debug("A test case failed, showing the last 10 commands executed on TG:")
- for command_res in get_ctx().tg_node.main_session.remote_session.history[-10:]:
- get_logger().debug(command_res.command)
+ if ctx.tg_node:
+ for command_res in ctx.tg_node.main_session.remote_session.history[-10:]:
+ get_logger().debug(command_res.command)
raise TestCaseVerifyError(failure_description)
diff --git a/dts/configurations/test_run.example.yaml b/dts/configurations/test_run.example.yaml
index ee641f5dce..af5f72d305 100644
--- a/dts/configurations/test_run.example.yaml
+++ b/dts/configurations/test_run.example.yaml
@@ -59,7 +59,7 @@ test_suites: # see `Optional Fields`; the following test suites will be run in t
system_under_test_node: "SUT 1"
# Traffic generator node to use for this execution environment
traffic_generator_node: "TG 1"
-port_topology:
+port_topology: # provide empty list for no-link environment
- sut.port-0 <-> tg.port-0 # explicit link. `sut` and `tg` are special identifiers that refer
# to the respective test run's configured nodes.
- port-1 <-> port-1 # implicit link, left side is always SUT, right side is always TG.
diff --git a/dts/framework/config/__init__.py b/dts/framework/config/__init__.py
index d2f0138e4a..59d566aa0b 100644
--- a/dts/framework/config/__init__.py
+++ b/dts/framework/config/__init__.py
@@ -94,9 +94,10 @@ def validate_port_links(self) -> Self:
f"already linked to port {sut_node_port_peer[0]}.{sut_node_port_peer[1]}."
)
- tg_node_port_peer = existing_port_links.get(
- (self.test_run.traffic_generator_node, link.tg_port), None
- )
+ if self.test_run.traffic_generator_node:
+ tg_node_port_peer = existing_port_links.get(
+ (self.test_run.traffic_generator_node, link.tg_port), None
+ )
assert (
tg_node_port_peer is not None
), f"Invalid TG node port specified for link port_topology.{link_idx}."
@@ -122,11 +123,12 @@ def validate_test_run_against_nodes(self) -> Self:
), f"The system_under_test_node {sut_node_name} is not a valid node name."
tg_node_name = self.test_run.traffic_generator_node
- tg_node = next((n for n in self.nodes if n.name == tg_node_name), None)
+ if self.test_run.port_topology:
+ tg_node = next((n for n in self.nodes if n.name == tg_node_name), None)
- assert (
- tg_node is not None
- ), f"The traffic_generator_name {tg_node_name} is not a valid node name."
+ assert (
+ tg_node is not None
+ ), f"The traffic_generator_name {tg_node_name} is not a valid node name."
return self
diff --git a/dts/framework/config/test_run.py b/dts/framework/config/test_run.py
index 76e24d1785..f9143dfc4e 100644
--- a/dts/framework/config/test_run.py
+++ b/dts/framework/config/test_run.py
@@ -492,11 +492,11 @@ class TestRunConfiguration(FrozenModel):
#: The SUT node name to use in this test run.
system_under_test_node: str
#: The TG node name to use in this test run.
- traffic_generator_node: str
+ traffic_generator_node: str | None = Field(default=None)
#: The seed to use for pseudo-random generation.
random_seed: int | None = None
#: The port links between the specified nodes to use.
- port_topology: list[PortLinkConfig] = Field(max_length=2)
+ port_topology: list[PortLinkConfig] = Field(default=[], max_length=2)
fields_from_settings = model_validator(mode="before")(
load_fields_from_settings("test_suites", "random_seed")
diff --git a/dts/framework/context.py b/dts/framework/context.py
index 8f1021dc96..371473f61c 100644
--- a/dts/framework/context.py
+++ b/dts/framework/context.py
@@ -72,7 +72,7 @@ class Context:
"""Runtime context."""
sut_node: Node
- tg_node: Node
+ tg_node: Node | None
topology: Topology
dpdk_build: "DPDKBuildEnvironment"
dpdk: "DPDKRuntimeEnvironment"
diff --git a/dts/framework/remote_session/dpdk.py b/dts/framework/remote_session/dpdk.py
index c3575cfcaf..e43e1f2123 100644
--- a/dts/framework/remote_session/dpdk.py
+++ b/dts/framework/remote_session/dpdk.py
@@ -13,6 +13,7 @@
from pathlib import Path, PurePath
from typing import ClassVar, Final
+from api.capabilities import LinkTopology
from framework.config.test_run import (
DPDKBuildConfiguration,
DPDKBuildOptionsConfiguration,
@@ -263,7 +264,8 @@ def _build_dpdk(self) -> None:
ctx = get_ctx()
# If the SUT is an ice driver device, make sure to build with 16B descriptors.
if (
- ctx.topology.sut_port_ingress
+ ctx.topology.type is not LinkTopology.NO_LINK
+ and ctx.topology.sut_port_ingress
and ctx.topology.sut_port_ingress.config.os_driver == "ice"
):
meson_args = MesonArgs(
diff --git a/dts/framework/test_run.py b/dts/framework/test_run.py
index 94dc6023a7..93fc5ee93f 100644
--- a/dts/framework/test_run.py
+++ b/dts/framework/test_run.py
@@ -189,25 +189,28 @@ def __init__(
self.config = config
self.logger = get_dts_logger()
+ tg_node = None
sut_node = next(n for n in nodes if n.name == config.system_under_test_node)
- tg_node = next(n for n in nodes if n.name == config.traffic_generator_node)
-
- topology = Topology.from_port_links(
- PortLink(sut_node.ports_by_name[link.sut_port], tg_node.ports_by_name[link.tg_port])
- for link in self.config.port_topology
- )
+ if config.traffic_generator_node:
+ tg_node = next(n for n in nodes if n.name == config.traffic_generator_node)
+ topology = Topology.from_port_links(
+ PortLink(sut_node.ports_by_name[link.sut_port], tg_node.ports_by_name[link.tg_port])
+ for link in self.config.port_topology
+ )
+ else:
+ topology = Topology.from_port_links(iter([]))
dpdk_build_env = DPDKBuildEnvironment(config.dpdk.build, sut_node)
dpdk_runtime_env = DPDKRuntimeEnvironment(config.dpdk, sut_node, dpdk_build_env)
func_traffic_generator = (
create_traffic_generator(config.func_traffic_generator, tg_node)
- if config.func and config.func_traffic_generator
+ if config.func and config.func_traffic_generator and tg_node
else None
)
perf_traffic_generator = (
create_traffic_generator(config.perf_traffic_generator, tg_node)
- if config.perf and config.perf_traffic_generator
+ if config.perf and config.perf_traffic_generator and tg_node
else None
)
@@ -343,7 +346,8 @@ def next(self) -> State | None:
test_run.remaining_tests = deque(test_run.selected_tests)
test_run.ctx.sut_node.setup()
- test_run.ctx.tg_node.setup()
+ if test_run.ctx.tg_node:
+ test_run.ctx.tg_node.setup()
test_run.ctx.dpdk.setup()
test_run.ctx.topology.setup()
@@ -455,7 +459,8 @@ def next(self) -> State | None:
self.test_run.ctx.perf_tg.teardown()
self.test_run.ctx.topology.teardown()
self.test_run.ctx.dpdk.teardown()
- self.test_run.ctx.tg_node.teardown()
+ if self.test_run.ctx.tg_node:
+ self.test_run.ctx.tg_node.teardown()
self.test_run.ctx.sut_node.teardown()
return None
diff --git a/dts/framework/testbed_model/topology.py b/dts/framework/testbed_model/topology.py
index 34862c4d2e..01333da716 100644
--- a/dts/framework/testbed_model/topology.py
+++ b/dts/framework/testbed_model/topology.py
@@ -73,6 +73,8 @@ def from_port_links(cls, port_links: Iterator[PortLink]) -> Self:
ConfigurationError: If an unsupported link topology is supplied.
"""
type = LinkTopology.NO_LINK
+ sut_ports = []
+ tg_ports = []
if port_link := next(port_links, None):
type = LinkTopology.ONE_LINK
@@ -103,10 +105,10 @@ def node_and_ports_from_id(self, node_identifier: NodeIdentifier) -> tuple[Node,
case "sut":
return ctx.sut_node, self.sut_ports
case "tg":
- return ctx.tg_node, self.tg_ports
- case _:
- msg = f"Invalid node `{node_identifier}` given."
- raise InternalError(msg)
+ if ctx.tg_node:
+ return ctx.tg_node, self.tg_ports
+ msg = f"Invalid node `{node_identifier}` given."
+ raise InternalError(msg)
def get_crypto_vfs(self, num_vfs: int) -> list[Port]:
"""Retrieve virtual functions from active crypto vfs.
@@ -139,6 +141,8 @@ def setup(self) -> None:
Binds all the ports to the right kernel driver to retrieve MAC addresses and logical names.
"""
+ if self.type is LinkTopology.NO_LINK:
+ return
self._prepare_devbind_script()
self._setup_ports("sut")
self._setup_ports("tg")
@@ -148,6 +152,8 @@ def teardown(self) -> None:
Restores all the ports to their original drivers before the test run.
"""
+ if self.type is LinkTopology.NO_LINK:
+ return
self._restore_ports_original_drivers("sut")
self._restore_ports_original_drivers("tg")
@@ -338,7 +344,8 @@ def prepare_node(node: Node) -> None:
node.main_session.devbind_script_path = devbind_script_path
ctx = get_ctx()
- prepare_node(ctx.tg_node)
+ if ctx.tg_node:
+ prepare_node(ctx.tg_node)
prepare_node(ctx.sut_node)
@property
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 0/2] net/intel: fix blocking link wait on device start
From: Bruce Richardson @ 2026-06-09 13:13 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev
In-Reply-To: <20260603143407.1108527-1-ciara.loftus@intel.com>
On Wed, Jun 03, 2026 at 02:34:05PM +0000, Ciara Loftus wrote:
> Device start in both ice and i40e has historically blocked for up to
> two seconds waiting for link to come up before returning. This causes
> noticeable startup delay when a link partner is slow to come up or
> absent entirely. This series reverts the wait in ice, and removes the
> wait in i40e while ensuring that the MAC config is applied when the
> link is up which is a requirement for some devices.
>
> Ciara Loftus (2):
> net/ice: revert fix link up when starting device
> net/i40e: fix blocking link wait on device start
>
> drivers/net/intel/i40e/i40e_ethdev.c | 25 +++++++++++++++++++++----
> drivers/net/intel/i40e/i40e_ethdev.h | 2 ++
> drivers/net/intel/ice/ice_ethdev.c | 2 +-
> 3 files changed, 24 insertions(+), 5 deletions(-)
>
> --
Series applied to dpdk-next-net-intel.
Thanks,
/Bruce
^ permalink raw reply
* [PATCH v4] dts: add retry loop to trex traffic generation
From: Andrew Bailey @ 2026-06-09 13:33 UTC (permalink / raw)
To: patrickrobb1997, luca.vizzarro
Cc: dev, knimoji, ahassick, lylavoie, Andrew Bailey
In-Reply-To: <20260518175424.253600-1-abailey@iol.unh.edu>
There was an issue where the single core forward test would report zero
MPPS intermittently. This was due to TREX reporting that the link was
down when the client was called to start generating traffic. The links
were being reported down by TREX on the tg even when testpmd was
reporting them up on the SUT. Adding a retry loop to the generate
traffic method of TREX gives the tg enough time to set up and send
traffic.
Bugzilla ID: 1946
Fixes: d77d7f04f24c ("dts: add single-core performance test suite")
Signed-off-by: Andrew Bailey <abailey@iol.unh.edu>
---
.../testbed_model/traffic_generator/trex.py | 35 ++++++++++++++-----
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/dts/framework/testbed_model/traffic_generator/trex.py b/dts/framework/testbed_model/traffic_generator/trex.py
index 22cd20dea9..f21892e396 100644
--- a/dts/framework/testbed_model/traffic_generator/trex.py
+++ b/dts/framework/testbed_model/traffic_generator/trex.py
@@ -220,7 +220,9 @@ def _create_packet_stream(self, packet: Packet) -> None:
]
self._shell.send_command("\n".join(packet_stream))
- def _send_traffic_and_get_stats(self, duration: float, send_mpps: float | None = None) -> str:
+ def _send_traffic_and_get_stats(
+ self, duration: float, send_mpps: float | None = None, retry_attempts: int = 5
+ ) -> str:
"""Send traffic and get TG Rx stats.
Sends traffic from the TRex client's ports for the given duration.
@@ -230,15 +232,30 @@ def _send_traffic_and_get_stats(self, duration: float, send_mpps: float | None =
Args:
duration: The traffic generation duration.
send_mpps: The millions of packets per second for TRex to send from each port.
+ retry_attempts: The number of times to retry this command on failure.
+
+ Raises:
+ SSHTimeoutError: If TRex fails to send traffic in the allotted attempts.
"""
- if send_mpps:
- self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
- mult = '{send_mpps}mpps',
- duration = {duration})""")
- else:
- self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
- mult = '100%',
- duration = {duration})""")
+ link_up = False
+ attempt = 0
+
+ while not link_up and attempt < retry_attempts:
+ if send_mpps:
+ result = self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
+ mult = '{send_mpps}mpps',
+ duration = {duration})""")
+ else:
+ result = self._shell.send_command(f"""{self.stl_client_name}.start(ports=[0, 1],
+ mult = '100%',
+ duration = {duration})""")
+ link_up = "link is DOWN" not in result
+ if not link_up:
+ self._logger.info(
+ f"Generate traffic command failed (attempt {attempt + 1} of {retry_attempts})"
+ )
+ time.sleep(0.25)
+ attempt += 1
time.sleep(duration)
--
2.54.0
^ permalink raw reply related
* [PATCH v2] eal: fix function versioning with LTO
From: Stephen Hemminger @ 2026-06-09 13:54 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
In-Reply-To: <20260602225722.950617-1-stephen@networkplumber.org>
When using function versioning and building with LTO,
GCC gets confused by the symbol versioning using __asm__.
There are no uses of function versioning in upstream repo.
This was found when adding additional parameter to
rte_eth_dev_get_name_by_port.
Assembler messages:
Error: invalid attempt to declare external version name as default in symbol `rte_eth_dev_get_name_by_port@@DPDK_27'
The workaround GCC 10 introduced was an additional function attribute;
clang doesn't have or need this attribute. No need to backport this to
LTS since there is no function versioning in those releases.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
v2 - reword commit message
lib/eal/common/eal_export.h | 46 +++++++++++++++++++++++++++----------
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/lib/eal/common/eal_export.h b/lib/eal/common/eal_export.h
index 7e47d34064..1318e6278d 100644
--- a/lib/eal/common/eal_export.h
+++ b/lib/eal/common/eal_export.h
@@ -30,39 +30,61 @@
* new functionality, behavior, etc. When that occurs, it is desirable to
* allow for backwards compatibility for a time with older binaries that are
* dynamically linked to the dpdk.
+ *
+ * RTE_VERSION_SYMBOL
+ * Create a symbol version table entry binding symbol <name>@DPDK_<ver> to the internal
+ * function name <name>_v<ver>.
+ *
+ * RTE_VERSION_EXPERIMENTAL_SYMBOL similar to RTE_VERSION_SYMBOL but for experimental API symbols.
+ * This is mainly used for keeping compatibility for symbols that get promoted to stable ABI.
+ *
+ * RTE_DEFAULT_SYMBOL
+ * Create a symbol version entry instructing the linker to bind references to
+ * symbol <name> to the internal symbol <name>_v<ver>.
*/
#ifdef RTE_BUILD_SHARED_LIB
-/*
- * Create a symbol version table entry binding symbol <name>@DPDK_<ver> to the internal
- * function name <name>_v<ver>.
- */
+/* Prefer the compiler method of versioning which uses attributes */
+#if __has_attribute(symver)
+
+#define RTE_VERSION_SYMBOL(ver, type, name, args) VERSIONING_WARN \
+ __attribute__((__symver__(RTE_STR(name) "@DPDK_" RTE_STR(ver)))) \
+ type name ## _v ## ver args; \
+ type name ## _v ## ver args
+
+#define RTE_VERSION_EXPERIMENTAL_SYMBOL(type, name, args) VERSIONING_WARN \
+ __attribute__((__symver__(RTE_STR(name) "@EXPERIMENTAL"))) \
+ type name ## _exp args; \
+ type name ## _exp args
+
+#define RTE_DEFAULT_SYMBOL(ver, type, name, args) VERSIONING_WARN \
+ __attribute__((__symver__(RTE_STR(name) "@@DPDK_" RTE_STR(ver)))) \
+ type name ## _v ## ver args; \
+ type name ## _v ## ver args
+#else /* !__has_attribute(symver) */
+
+/* Use asm tag to create symbol table entry */
#define RTE_VERSION_SYMBOL(ver, type, name, args) VERSIONING_WARN \
__asm__(".symver " RTE_STR(name) "_v" RTE_STR(ver) ", " RTE_STR(name) "@DPDK_" RTE_STR(ver)); \
__rte_used type name ## _v ## ver args; \
type name ## _v ## ver args
-/*
- * Similar to RTE_VERSION_SYMBOL but for experimental API symbols.
- * This is mainly used for keeping compatibility for symbols that get promoted to stable ABI.
- */
#define RTE_VERSION_EXPERIMENTAL_SYMBOL(type, name, args) VERSIONING_WARN \
__asm__(".symver " RTE_STR(name) "_exp, " RTE_STR(name) "@EXPERIMENTAL") \
__rte_used type name ## _exp args; \
type name ## _exp args
-/*
- * Create a symbol version entry instructing the linker to bind references to
- * symbol <name> to the internal symbol <name>_v<ver>.
- */
#define RTE_DEFAULT_SYMBOL(ver, type, name, args) VERSIONING_WARN \
__asm__(".symver " RTE_STR(name) "_v" RTE_STR(ver) ", " RTE_STR(name) "@@DPDK_" RTE_STR(ver)); \
__rte_used type name ## _v ## ver args; \
type name ## _v ## ver args
+#endif /* __has_attribute(symver) */
+
#else /* !RTE_BUILD_SHARED_LIB */
+/* static library does not have versioned symbols */
#define RTE_VERSION_SYMBOL(ver, type, name, args) VERSIONING_WARN \
type name ## _v ## ver args; \
type name ## _v ## ver args
--
2.53.0
^ permalink raw reply related
* [PATCH] net/iavf: reject oversized frames in prep callback
From: Ciara Loftus @ 2026-06-09 14:03 UTC (permalink / raw)
To: dev; +Cc: Ciara Loftus, stable
Currently, only the segment count is checked for non-TSO packets. There
is no upper bound placed on the packet length, so packets larger than
`IAVF_FRAME_SIZE_MAX` pass the prepare callback unchallenged and are
submitted to the hardware. Sending such frames can trigger Malicious
Driver Detection (MDD) on the PF. Fix this by adding a packet length
size check on the non-TSO path.
Fixes: 19ee91c6bd9a ("net/iavf: check illegal packet sizes")
Cc: stable@dpdk.org
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
drivers/net/intel/iavf/iavf_rxtx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/intel/iavf/iavf_rxtx.c b/drivers/net/intel/iavf/iavf_rxtx.c
index decbc75142..a57af7faed 100644
--- a/drivers/net/intel/iavf/iavf_rxtx.c
+++ b/drivers/net/intel/iavf/iavf_rxtx.c
@@ -3227,9 +3227,9 @@ iavf_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
m = tx_pkts[i];
ol_flags = m->ol_flags;
- /* Check condition for nb_segs > IAVF_TX_MAX_MTU_SEG. */
+ /* Validate segment count and packet length. */
if (!(ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG))) {
- if (m->nb_segs > IAVF_TX_MAX_MTU_SEG) {
+ if (m->nb_segs > IAVF_TX_MAX_MTU_SEG || m->pkt_len > IAVF_FRAME_SIZE_MAX) {
rte_errno = EINVAL;
return i;
}
--
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