* Deep Dive into DPDK NIC RX/TX Flow
From: 胡兴菊 @ 2026-06-16 6:44 UTC (permalink / raw)
To: dev
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
Hello DPDK team,
I'd like to submit the following technical content for consideration in the DPDK newsletter.
Title: DPDK网卡收发报文流程深度解析 (Deep Dive into DPDK NIC RX/TX Flow)
Link: https://github.com/huxingju/dpdk-source-analyzer/blob/main/NIC_RX_TX_FLOW.md
Type: Technical deep dive / Developer blog
Description:
This article provides a comprehensive analysis of DPDK's RX/TX data path, covering:
- Hardware architecture: RX/TX FIFO, DMA engine, descriptor ring
- Software layer: rte_mbuf structure, driver implementation (ixgbe as example)
- Relationship between hardware descriptor, SW ring, and mbuf
- Performance optimization techniques: batching, prefetching, NUMA awareness
**About the creation process:**
This article was human-directed and AI-assisted. As a developer with 8+ years of network development experience, I:
- Defined the scope, structure, and key technical points
- Guided the AI to generate specific sections
- Reviewed, corrected, and validated all technical content
The final result reflects my expertise and has been verified for technical accuracy.
Best regards,
Huxingju
GitHub: github.com/huxingju
[-- Attachment #2: Type: text/html, Size: 5689 bytes --]
^ permalink raw reply
* Re: [EXTERNAL] [PATCH 00/13] Bus cleanup infrastructure and fixes
From: David Marchand @ 2026-06-16 6:55 UTC (permalink / raw)
To: Long Li
Cc: dev@dpdk.org, thomas@monjalon.net, stephen@networkplumber.org,
bruce.richardson@intel.com, fengchengwen@huawei.com
In-Reply-To: <SA1PR21MB6683AEB004DF96D48ACDAD51CEE62@SA1PR21MB6683.namprd21.prod.outlook.com>
On Tue, 16 Jun 2026 at 01:55, Long Li <longli@microsoft.com> wrote:
>
> >
> > > This series refactors the bus cleanup infrastructure to reduce code
> > > duplication and fix resource leaks in several bus drivers.
> > > It should address the leak Thomas pointed at.
> > >
> > > The first part of the series (patches 1-8) addresses several bugs and
> > > inconsistencies:
> > > - Documentation and log message inconsistencies from earlier bus
> > > refactoring
> > > - Device list management issues in dma/idxd and bus/vdev
> > > - Resource leaks in PCI and VMBUS bus cleanup (mappings and
> > > interrupts)
> > > - Simplified device freeing in NXP buses (DPAA and FSLMC)
> > > - Deferred interrupt allocation to probe time (NXP buses, VMBUS)
> > >
> > > The core infrastructure changes (patches 9-10) introduce the generic
> > > cleanup
> > > framework:
> > > - Refactors unplug operations to be the counterpart of probe_device
> > > - Implements rte_bus_generic_cleanup() to centralize cleanup logic
> > > - Adds .free_device operation to struct rte_bus
> > > - Adds compile-time verification that rte_device is at offset 0
> > >
> > > The final patches (11-13) convert remaining buses to use the generic
> > > cleanup
> > > helper:
> > > - DPAA bus: add unplug support
> > > - VMBUS bus: switch to embedded device name and add unplug support
> >
> > There is a hung on vmbus during device shutdown after applying the series, I'm
> > looking into it.
>
> Turned out to be a test issue. Please see my comments on patch 08, the patch set tested well after that fix.
Thanks a lot for testing!
I'll fix this regression in the next revision.
--
David Marchand
^ permalink raw reply
* Re: [PATCH dpdk v2 2/2] graph: replace circular buffer with priority-based bitmap
From: Robin Jarry @ 2026-06-16 7:16 UTC (permalink / raw)
To: kirankumark
Cc: cfontain, david.marchand, dev, jerinj, konstantin.ananyev, maxime,
ndabilpuram, vladimir.medvedkin, yanzhirun_163
In-Reply-To: <20260616063026.2007191-1-kirankumark@marvell.com>
Hi,
, Jun 16, 2026 at 08:30:
> This will break the ABI. Please check and fix.
Yes it will break the ABI. There is no way around it. What did you mean
by "check and fix"?
^ permalink raw reply
* Re: [EXTERNAL] [PATCH 00/13] Bus cleanup infrastructure and fixes
From: David Marchand @ 2026-06-16 7:47 UTC (permalink / raw)
To: Hemant Agrawal
Cc: dev@dpdk.org, thomas@monjalon.net, stephen@networkplumber.org,
bruce.richardson@intel.com, fengchengwen@huawei.com, Long Li
In-Reply-To: <CAJFAV8wL8K=gD1f7CAAuY8_7tz4CdR_hPn4j4xP3Nb2sfnrjqA@mail.gmail.com>
On Tue, 16 Jun 2026 at 08:55, David Marchand <david.marchand@redhat.com> wrote:
>
> On Tue, 16 Jun 2026 at 01:55, Long Li <longli@microsoft.com> wrote:
> >
> > >
> > > > This series refactors the bus cleanup infrastructure to reduce code
> > > > duplication and fix resource leaks in several bus drivers.
> > > > It should address the leak Thomas pointed at.
> > > >
> > > > The first part of the series (patches 1-8) addresses several bugs and
> > > > inconsistencies:
> > > > - Documentation and log message inconsistencies from earlier bus
> > > > refactoring
> > > > - Device list management issues in dma/idxd and bus/vdev
> > > > - Resource leaks in PCI and VMBUS bus cleanup (mappings and
> > > > interrupts)
> > > > - Simplified device freeing in NXP buses (DPAA and FSLMC)
> > > > - Deferred interrupt allocation to probe time (NXP buses, VMBUS)
> > > >
> > > > The core infrastructure changes (patches 9-10) introduce the generic
> > > > cleanup
> > > > framework:
> > > > - Refactors unplug operations to be the counterpart of probe_device
> > > > - Implements rte_bus_generic_cleanup() to centralize cleanup logic
> > > > - Adds .free_device operation to struct rte_bus
> > > > - Adds compile-time verification that rte_device is at offset 0
> > > >
> > > > The final patches (11-13) convert remaining buses to use the generic
> > > > cleanup
> > > > helper:
> > > > - DPAA bus: add unplug support
> > > > - VMBUS bus: switch to embedded device name and add unplug support
> > >
> > > There is a hung on vmbus during device shutdown after applying the series, I'm
> > > looking into it.
> >
> > Turned out to be a test issue. Please see my comments on patch 08, the patch set tested well after that fix.
>
> Thanks a lot for testing!
>
> I'll fix this regression in the next revision.
Fyi Hemant, this series has a similar regression for dpaa/fslmc bus
(interrupt handle allocated too late in the device probing flow).
The implications seem greater than fixing vmbus though, as I am now
finding bugs on the cleanup side (interrupt eventfd are never closed,
for example).
I'll think about how to fix it in the next revision, one option may be
to leave dpaa/fslmc alone.. ?
But in the long run, all bus drivers should behave consistently.
I'll get back in this thread once I have a better view of the situation.
--
David Marchand
^ permalink raw reply
* Re: [PATCH dpdk v2 2/2] graph: replace circular buffer with priority-based bitmap
From: kirankumark @ 2026-06-16 7:57 UTC (permalink / raw)
To: rjarry
Cc: cfontain, david.marchand, dev, jerinj, kirankumark,
konstantin.ananyev, maxime, ndabilpuram, vladimir.medvedkin,
yanzhirun_163
In-Reply-To: <DJAAFGOSALXB.3BJ91NA2ES267@redhat.com>
^ permalink raw reply
* Re: [PATCH 2/9] eal/interrupts: keep real errno on epoll error
From: David Marchand @ 2026-06-16 8:02 UTC (permalink / raw)
To: Maxime Leroy
Cc: hemant.agrawal, sachin.saxena, dev, stable, Harman Kalra,
Cunming Liang
In-Reply-To: <20260611154926.392670-3-maxime@leroys.fr>
On Thu, 11 Jun 2026 at 17:50, Maxime Leroy <maxime@leroys.fr> wrote:
>
> Some interrupt users have several vectors backed by the same eventfd
> (e.g. several Rx queues behind one DPAA2 portal eventfd). Adding the
> second vector to the same epoll instance then fails with EEXIST.
>
> Upper layers such as ethdev and bbdev already treat -EEXIST as a
> non-fatal duplicate registration (if (ret && ret != -EEXIST)), but
> rte_intr_rx_ctl() lost that information: rte_epoll_ctl() returned -1 and
> rte_intr_rx_ctl() flattened every failure to -EPERM.
>
> Return the negative errno from rte_epoll_ctl() (its documented contract
> is already "a negative value") and stop rte_intr_rx_ctl() from
> flattening errors to -EPERM, so EEXIST reaches the upper layers that
> already handle it; other failures carry their real errno.
>
> Fixes: 9efe9c6cdcac ("eal/linux: add epoll wrappers")
> Fixes: c9f3ec1a0f3f ("eal/linux: add Rx interrupt control function")
> Cc: stable@dpdk.org
> Signed-off-by: Maxime Leroy <maxime@leroys.fr>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Nit: the eal/ prefix is only for OS specific / arch specific changes.
The title prefix should be interrupt:
--
David Marchand
^ permalink raw reply
* Re: [PATCH dpdk v2 2/2] graph: replace circular buffer with priority-based bitmap
From: kirankumark @ 2026-06-16 8:03 UTC (permalink / raw)
To: rjarry
Cc: cfontain, david.marchand, dev, jerinj, kirankumark,
konstantin.ananyev, maxime, ndabilpuram, vladimir.medvedkin,
yanzhirun_163
In-Reply-To: <DJAAFGOSALXB.3BJ91NA2ES267@redhat.com>
> Hi,
>
> , Jun 16, 2026 at 08:30:
> > This will break the ABI. Please check and fix.
>
> Yes it will break the ABI. There is no way around it. What did you mean
> by "check and fix"?
>
Looks like we canot avoid ABI break, Since Graph is not experimental library,
please send deprication notice and we need to wait for next ABI breaking release i.e 27.11
^ permalink raw reply
* Re: [PATCH 5/9] net/dpaa2: support Rx queue interrupts
From: David Marchand @ 2026-06-16 8:05 UTC (permalink / raw)
To: Maxime Leroy; +Cc: hemant.agrawal, sachin.saxena, dev
In-Reply-To: <20260611154926.392670-6-maxime@leroys.fr>
On Thu, 11 Jun 2026 at 17:51, Maxime Leroy <maxime@leroys.fr> wrote:
> diff --git a/drivers/bus/fslmc/qbman/qbman_portal.c b/drivers/bus/fslmc/qbman/qbman_portal.c
> index 84853924e7..947415363a 100644
> --- a/drivers/bus/fslmc/qbman/qbman_portal.c
> +++ b/drivers/bus/fslmc/qbman/qbman_portal.c
> @@ -448,6 +448,7 @@ int qbman_swp_interrupt_get_inhibit(struct qbman_swp *p)
> return qbman_cinh_read(&p->sys, QBMAN_CINH_SWP_IIR);
> }
>
> +RTE_EXPORT_INTERNAL_SYMBOL(qbman_swp_interrupt_set_inhibit)
> void qbman_swp_interrupt_set_inhibit(struct qbman_swp *p, int inhibit)
qbman_swp_interrupt_set_inhibit is not declared as __rte_internal.
> {
> qbman_cinh_write(&p->sys, QBMAN_CINH_SWP_IIR,
--
David Marchand
^ permalink raw reply
* Re: [PATCH] net/iavf: fix scalar Rx path zero-length segment
From: Bruce Richardson @ 2026-06-16 8:06 UTC (permalink / raw)
To: Loftus, Ciara; +Cc: dev@dpdk.org, stable@dpdk.org, Doherty, Declan
In-Reply-To: <ai_G2-sLspd2PdK8@bricha3-mobl1.ger.corp.intel.com>
On Mon, Jun 15, 2026 at 10:33:15AM +0100, Bruce Richardson wrote:
> On Mon, Jun 15, 2026 at 10:17:41AM +0100, Loftus, Ciara wrote:
> > > Subject: Re: [PATCH] net/iavf: fix scalar Rx path zero-length segment
> > >
> > > On Fri, Jun 12, 2026 at 02:35:31PM +0000, Ciara Loftus wrote:
> > > > When hardware CRC stripping is active, a frame whose on-wire size is an
> > > > exact multiple of the Rx buffer size can cause the NIC to fill the final
> > > > data descriptor and place the four CRC bytes into a separate trailing
> > > > descriptor. After hardware stripping, that descriptor carries zero bytes
> > > > of payload.
> > > >
> > > > The existing CRC cleanup code only handles a zero-length trailing segment
> > > > when software CRC stripping is enabled. When hardware stripping is
> > > > active, the zero-length mbuf is silently chained to the reassembled
> > > > packet. Forwarding such a packet causes a zero-length Tx descriptor,
> > > > triggering a Malicious Driver Detection event on the PF and resetting
> > > > the VF.
> > > >
> > > > Fix by adding logic to detect a zero-length final segment when hardware
> > > > CRC stripping is active, and freeing it.
> > > >
> > > > Fixes: a2b29a7733ef ("net/avf: enable basic Rx Tx")
> > > > Fixes: b8b4c54ef9b0 ("net/iavf: support flexible Rx descriptor in normal
> > > path")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> > > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > > > ---
> > > > drivers/net/intel/iavf/iavf_rxtx.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/net/intel/iavf/iavf_rxtx.c
> > > b/drivers/net/intel/iavf/iavf_rxtx.c
> > > > index a57af7faed..86ebb2618d 100644
> > > > --- a/drivers/net/intel/iavf/iavf_rxtx.c
> > > > +++ b/drivers/net/intel/iavf/iavf_rxtx.c
> > > > @@ -1716,6 +1716,14 @@ iavf_recv_scattered_pkts_flex_rxd(void
> > > *rx_queue, struct rte_mbuf **rx_pkts,
> > > > rxm->data_len = (uint16_t)(rx_packet_len -
> > > >
> > > RTE_ETHER_CRC_LEN);
> > > > }
> > > > + } else if (unlikely(rx_packet_len == 0)) {
> > > > + /*
> > > > + * NIC split CRC bytes into a trailing segment which is
> > > > + * now empty after hardware CRC stripping. Free it.
> > > > + */
> > > > + rte_pktmbuf_free_seg(rxm);
> > > > + first_seg->nb_segs--;
> > > > + last_seg->next = NULL;
> > > > }
> > > >
> > >
> > > The vector paths also handle scattered packets (via reassembly). Do they
> > > need a fix for this? What about the other drivers that work on the PF, such
> > > as ice/i40e?
> >
> > The vector paths use the common ci_rx_reassemble_packets which already
> > handles the zero-length trailing segment case correctly. When
> > crc_len == 0 and the last segment has data_len == 0, the empty segment
> > is freed.
> >
> > The ice scalar path had the same issue but it was patched in 2022:
> > https://git.dpdk.org/dpdk/commit/?id=90ba4442058a14763e57ca96d03ab1e6044e3e5c
> > I cannot reproduce the behaviour on i40e hardware (either PF or VF) so I
> > don't think it needs to be patched as the HW seems to behave
> > differently.
> >
>
> Thanks for clarifying.
>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
Applied to dpdk-next-net-intel.
thanks,
/Bruce
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH v9 0/1] net/mana: add device reset support
From: Wei Hu @ 2026-06-16 8:11 UTC (permalink / raw)
To: Stephen Hemminger, Wei Hu; +Cc: dev@dpdk.org, Long Li
In-Reply-To: <20260615115028.5fa705c3@phoenix.local>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, June 16, 2026 2:50 AM
> To: Wei Hu <weh@linux.microsoft.com>
> Cc: dev@dpdk.org; Long Li <longli@microsoft.com>; Wei Hu
> <weh@microsoft.com>
> Subject: [EXTERNAL] Re: [PATCH v9 0/1] net/mana: add device reset support
>
>
> One small thing in mp.c: in the RESET_EXIT secondary handler the received fd is
> only closed on the branch that maps it. If proc_priv->db_page is already non-
> NULL the fd from the message is leaked. Close it whenever num_fds >= 1,
> outside the if/else.
> ---
> I can merge it as is, or you can send a revision to close that minor leak.
I will send a revision to close this leak. Thanks Stephen!
Wei
^ permalink raw reply
* Re: [PATCH v1 1/1] net/i40e: allow discontiguous queue lists in hash
From: Bruce Richardson @ 2026-06-16 8:42 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev
In-Reply-To: <9999fab5d9491d15ff98ac5aafa248e11df558de.1781521311.git.anatoly.burakov@intel.com>
On Mon, Jun 15, 2026 at 12:01:58PM +0100, Anatoly Burakov wrote:
> Due to recent refactors and code unification, there are now the following
> properties of RSS queue list that can be checked by common infrastructure:
>
> - Monotony (i.e. queue indices always increase, never decrease)
> - No duplication (i.e. can't have the same index specified twice)
> - Contiguousness (i.e. can't have holes in the queue list)
>
> The latter is an optional feature that can be enabled with a flag. However,
> previous hash code only enforced contiguousness for queue *regions* but not
> queue *lists*, whereas after the refactor, all queue lists were required to
> be contiguous. This is an unnecessary restriction, and it breaks backwards
> compatibility.
>
> Fix it by only specifying contiguousness requirement for the VLAN branch
> where we are actually looking for a queue *region* not queue *list*.
>
> Fixes: 0185303c2e24 ("net/i40e: refactor RSS flow parameter checks")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to dpdk-next-net-intel (with corrected fixline commit id).
Thanks,
/Bruce
> drivers/net/intel/i40e/i40e_hash.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/intel/i40e/i40e_hash.c b/drivers/net/intel/i40e/i40e_hash.c
> index 3c1302469c..8b80d0a91c 100644
> --- a/drivers/net/intel/i40e/i40e_hash.c
> +++ b/drivers/net/intel/i40e/i40e_hash.c
> @@ -1238,7 +1238,6 @@ i40e_hash_parse(struct rte_eth_dev *dev,
> },
> .max_actions = 1,
> .driver_ctx = dev->data->dev_private,
> - .rss_queues_contig = true,
> /* each pattern type will add specific check function */
> };
> const struct rte_flow_action_rss *rss_act;
> @@ -1265,6 +1264,8 @@ i40e_hash_parse(struct rte_eth_dev *dev,
> /* VLAN path */
> if (is_vlan) {
> ac_param.check = i40e_hash_validate_queue_region;
> + /* queue regions must be contiguous */
> + ac_param.rss_queues_contig = true;
> ret = ci_flow_check_actions(actions, &ac_param, &parsed_actions, error);
> if (ret)
> return ret;
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH] net/crc: add 4x folding loop for aarch64 NEON implementation
From: Shreesh Adiga @ 2026-06-16 9:11 UTC (permalink / raw)
To: Wathsala Vithanage; +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 x86 SSE implementation. This technique is
described in the paper by Intel:
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
This results in roughly 2x performance improvement due to better ILP
for large input sizes like 1024 observed on Cortex-X925.
Signed-off-by: Shreesh Adiga <16567adigashreesh@gmail.com>
---
lib/net/net_crc_neon.c | 51 +++++++++++++++++++++++++++++++++++-------
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/lib/net/net_crc_neon.c b/lib/net/net_crc_neon.c
index cee75ddd31..fc817e54f5 100644
--- a/lib/net/net_crc_neon.c
+++ b/lib/net/net_crc_neon.c
@@ -16,6 +16,7 @@
/** PMULL CRC computation context structure */
struct crc_pmull_ctx {
uint64x2_t rk1_rk2;
+ uint64x2_t rk3_rk4;
uint64x2_t rk5_rk6;
uint64x2_t rk7_rk8;
};
@@ -136,9 +137,36 @@ crc32_eth_calc_pmull(
temp = vreinterpretq_u64_u32(vsetq_lane_u32(crc, vmovq_n_u32(0), 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)) {
+ uint64x2_t fold1, fold2, fold3, fold4;
+ uint64x2_t temp1, temp2, temp3, temp4;
+ fold1 = vld1q_u64((const uint64_t *)(data + 0));
+ fold2 = vld1q_u64((const uint64_t *)(data + 16));
+ fold3 = vld1q_u64((const uint64_t *)(data + 32));
+ fold4 = vld1q_u64((const uint64_t *)(data + 48));
+ fold1 = veorq_u64(fold1, temp);
+ k = params->rk1_rk2;
+
+ for (n = 64; (n + 64) <= data_len; n += 64) {
+ temp1 = vld1q_u64((const uint64_t *)&data[n + 0]);
+ temp2 = vld1q_u64((const uint64_t *)&data[n + 16]);
+ temp3 = vld1q_u64((const uint64_t *)&data[n + 32]);
+ temp4 = vld1q_u64((const uint64_t *)&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)) {
/* 16 bytes */
@@ -176,9 +204,12 @@ crc32_eth_calc_pmull(
fold = vld1q_u64((const uint64_t *)data);
fold = veorq_u64(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 = vld1q_u64((const uint64_t *)&data[n]);
fold = crcr32_folding_round(temp, k, fold);
}
@@ -194,7 +225,7 @@ crc32_eth_calc_pmull(
mask = vshift_bytes_left(vdupq_n_u64(-1), 16 - rem);
b = vorrq_u64(b, vandq_u64(mask, last16));
- /* k = rk1 & rk2 */
+ /* k = rk3 & rk4 */
temp = vreinterpretq_u64_p128(vmull_p64(
vgetq_lane_p64(vreinterpretq_p64_u64(a), 1),
vgetq_lane_p64(vreinterpretq_p64_u64(k), 0)));
@@ -221,22 +252,26 @@ void
rte_net_crc_neon_init(void)
{
/* Initialize CRC16 data */
- uint64_t ccitt_k1_k2[2] = {0x189aeLLU, 0x8e10LLU};
+ uint64_t ccitt_k1_k2[2] = {0x14ff2LLU, 0x19a3cLLU};
+ uint64_t ccitt_k3_k4[2] = {0x189aeLLU, 0x8e10LLU};
uint64_t ccitt_k5_k6[2] = {0x189aeLLU, 0x114aaLLU};
uint64_t ccitt_k7_k8[2] = {0x11c581910LLU, 0x10811LLU};
/* Initialize CRC32 data */
- uint64_t eth_k1_k2[2] = {0xccaa009eLLU, 0x1751997d0LLU};
+ uint64_t eth_k1_k2[2] = {0x1c6e41596LLU, 0x154442bd4LLU};
+ uint64_t eth_k3_k4[2] = {0xccaa009eLLU, 0x1751997d0LLU};
uint64_t eth_k5_k6[2] = {0xccaa009eLLU, 0x163cd6124LLU};
uint64_t eth_k7_k8[2] = {0x1f7011640LLU, 0x1db710641LLU};
/** Save the params in context structure */
crc16_ccitt_pmull.rk1_rk2 = vld1q_u64(ccitt_k1_k2);
+ crc16_ccitt_pmull.rk3_rk4 = vld1q_u64(ccitt_k3_k4);
crc16_ccitt_pmull.rk5_rk6 = vld1q_u64(ccitt_k5_k6);
crc16_ccitt_pmull.rk7_rk8 = vld1q_u64(ccitt_k7_k8);
/** Save the params in context structure */
crc32_eth_pmull.rk1_rk2 = vld1q_u64(eth_k1_k2);
+ crc32_eth_pmull.rk3_rk4 = vld1q_u64(eth_k3_k4);
crc32_eth_pmull.rk5_rk6 = vld1q_u64(eth_k5_k6);
crc32_eth_pmull.rk7_rk8 = vld1q_u64(eth_k7_k8);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] eal: fix off by one in in tailq name init
From: David Marchand @ 2026-06-16 9:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, stable, Bruce Richardson, fengchengwen
In-Reply-To: <cd21b6e3-1efe-4ad6-9110-13b8c88f3248@huawei.com>
On Wed, 10 Jun 2026 at 03:36, fengchengwen <fengchengwen@huawei.com> wrote:
>
> On 6/9/2026 11:53 PM, Stephen Hemminger wrote:
> > The tailq name is defined as 32 bytes, but name would be
> > silently truncated at 31 bytes. The function strlcpy() size
> > already accounts for the NUL character at the end.
> >
Bugzilla ID: 1954
> > Fixes: f9acaf84e923 ("replace snprintf with strlcpy without adding extra include")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Applied, thanks.
--
David Marchand
^ permalink raw reply
* Re: [PATCH 8/9] ethdev: keep fast-path ops valid after port stop
From: Maxime Leroy @ 2026-06-16 9:23 UTC (permalink / raw)
To: David Marchand
Cc: hemant.agrawal, sachin.saxena, dev, stable, Thomas Monjalon,
Andrew Rybchenko, Morten Brørup, Sunil Kumar Kori
In-Reply-To: <CAJFAV8xTgkgdSzX980qW3zT+gqcDkrQyDV48SMzGh5qSCkz=7Q@mail.gmail.com>
On Mon, Jun 15, 2026 at 11:26 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Thu, 11 Jun 2026 at 17:51, Maxime Leroy <maxime@leroys.fr> wrote:
> >
> > eth_dev_fp_ops_reset() restores a port's fast-path ops on stop/release
> > via a compound literal, so every field it omits is zeroed to NULL. It
> > sets only rx_pkt_burst/tx_pkt_burst (and the rxq/txq data), leaving
> > rx_queue_count, tx_queue_count, rx/tx_descriptor_status, tx_pkt_prepare
> > and the recycle callbacks NULL.
> >
> > In non-debug builds these ops are reached through an unguarded indirect
> > call (the NULL check exists only under RTE_ETHDEV_DEBUG_RX/TX). So a
> > thread calling e.g. rte_eth_rx_queue_count() on a port being stopped
> > dereferences NULL and crashes, while the same race on rte_eth_rx_burst()
> > is harmless because the burst ops are reset to dummies. A poll-mode
> > worker re-checking rx_queue_count before arming the Rx interrupt and
> > sleeping hits exactly this.
> >
> > Reset these ops to the same dummies eth_dev_set_dummy_fops() installs,
> > so a stopped port behaves like a freshly allocated one: every fast-path
> > op is a safe no-op, none is NULL.
> >
> > Fixes: 066f3d9cc21c ("ethdev: remove callback checks from fast path")
> > Cc: stable@dpdk.org
> > Signed-off-by: Maxime Leroy <maxime@leroys.fr>
> > ---
> > lib/ethdev/ethdev_private.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> > index 72a0723846..75ea3eedff 100644
> > --- a/lib/ethdev/ethdev_private.c
> > +++ b/lib/ethdev/ethdev_private.c
> > @@ -263,6 +263,13 @@ eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
> > *fpo = (struct rte_eth_fp_ops) {
> > .rx_pkt_burst = dummy_eth_rx_burst,
> > .tx_pkt_burst = dummy_eth_tx_burst,
> > + .tx_pkt_prepare = rte_eth_tx_pkt_prepare_dummy,
> > + .rx_queue_count = rte_eth_queue_count_dummy,
> > + .tx_queue_count = rte_eth_queue_count_dummy,
> > + .rx_descriptor_status = rte_eth_descriptor_status_dummy,
> > + .tx_descriptor_status = rte_eth_descriptor_status_dummy,
> > + .recycle_tx_mbufs_reuse = rte_eth_recycle_tx_mbufs_reuse_dummy,
> > + .recycle_rx_descriptors_refill = rte_eth_recycle_rx_descriptors_refill_dummy,
> > .rxq = {
> > .data = (void **)&dummy_queues_array[port_id],
> > .clbk = dummy_data,
>
> Could we replace eth_dev_set_dummy_fops() with a call to
> eth_dev_fp_ops_reset() in rte_eth_dev_allocate?
> I don't like keeping two separate helpers.
>
>
> --
> David Marchand
>
Hi David,
Thanks for the review.
Avoiding the duplication is a good idea, but I could not find a clean
way to do it: eth_dev_set_dummy_fops() and eth_dev_fp_ops_reset()
cannot be unified without making things worse.
- They write two different structures. eth_dev_set_dummy_fops() sets
struct rte_eth_dev (the source ops); rte_eth_dev_allocate() fills
eth_dev->*, and eth_dev_fp_ops_setup() then copies eth_dev->* into the
per-port struct rte_eth_fp_ops. eth_dev_fp_ops_reset() writes that
fast-path table entry directly. So calling fp_ops_reset() from
rte_eth_dev_allocate() would populate the wrong structure.
- The burst dummies are intentionally different. set_dummy_fops() uses
the silent rte_eth_pkt_burst_dummy (a freshly allocated,
not-yet-started port is benign), while fp_ops_reset() uses
dummy_eth_rx_burst/dummy_eth_tx_burst, which log an error and dump the
stack because hitting the data path on a stopped port is a misuse
worth flagging.
- fp_ops_reset() also wires fpo->rxq/txq to the
dummy_queues_array/dummy_data used by the fast-path table, with no
equivalent on rte_eth_dev.
The only shared part is the non-burst dummy assignments, but factoring
those across the two different struct types would require a token
macro, and I don't have a clean solution for it. So for now I have
kept the two helpers as they are. Suggestions welcome.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH 2/9] eal/interrupts: keep real errno on epoll error
From: David Marchand @ 2026-06-16 9:29 UTC (permalink / raw)
To: Maxime Leroy
Cc: hemant.agrawal, sachin.saxena, dev, stable, Harman Kalra,
Cunming Liang, Stephen Hemminger, Thomas Monjalon
In-Reply-To: <CAJFAV8xH9GOGF2aR7tp2uMsjhpJs-1gXW=xzG4Gak3T_n1KpNQ@mail.gmail.com>
On Tue, 16 Jun 2026 at 10:02, David Marchand <david.marchand@redhat.com> wrote:
>
> On Thu, 11 Jun 2026 at 17:50, Maxime Leroy <maxime@leroys.fr> wrote:
> >
> > Some interrupt users have several vectors backed by the same eventfd
> > (e.g. several Rx queues behind one DPAA2 portal eventfd). Adding the
> > second vector to the same epoll instance then fails with EEXIST.
> >
> > Upper layers such as ethdev and bbdev already treat -EEXIST as a
> > non-fatal duplicate registration (if (ret && ret != -EEXIST)), but
> > rte_intr_rx_ctl() lost that information: rte_epoll_ctl() returned -1 and
> > rte_intr_rx_ctl() flattened every failure to -EPERM.
> >
> > Return the negative errno from rte_epoll_ctl() (its documented contract
> > is already "a negative value") and stop rte_intr_rx_ctl() from
> > flattening errors to -EPERM, so EEXIST reaches the upper layers that
> > already handle it; other failures carry their real errno.
> >
> > Fixes: 9efe9c6cdcac ("eal/linux: add epoll wrappers")
> > Fixes: c9f3ec1a0f3f ("eal/linux: add Rx interrupt control function")
> > Cc: stable@dpdk.org
> > Signed-off-by: Maxime Leroy <maxime@leroys.fr>
>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
>
> Nit: the eal/ prefix is only for OS specific / arch specific changes.
> The title prefix should be interrupt:
I took this fix directly in main.
Applied, thanks.
--
David marchand
^ permalink raw reply
* Re: [PATCH 8/9] ethdev: keep fast-path ops valid after port stop
From: David Marchand @ 2026-06-16 9:33 UTC (permalink / raw)
To: Maxime Leroy
Cc: hemant.agrawal, sachin.saxena, dev, stable, Thomas Monjalon,
Andrew Rybchenko, Morten Brørup, Sunil Kumar Kori
In-Reply-To: <CAHHRULXCs5yrQn_rQt_iPY3gBgoEx7K+vvdVOT_4dGk6E9_2NQ@mail.gmail.com>
On Tue, 16 Jun 2026 at 11:23, Maxime Leroy <maxime@leroys.fr> wrote:
> On Mon, Jun 15, 2026 at 11:26 AM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Thu, 11 Jun 2026 at 17:51, Maxime Leroy <maxime@leroys.fr> wrote:
> > >
> > > eth_dev_fp_ops_reset() restores a port's fast-path ops on stop/release
> > > via a compound literal, so every field it omits is zeroed to NULL. It
> > > sets only rx_pkt_burst/tx_pkt_burst (and the rxq/txq data), leaving
> > > rx_queue_count, tx_queue_count, rx/tx_descriptor_status, tx_pkt_prepare
> > > and the recycle callbacks NULL.
> > >
> > > In non-debug builds these ops are reached through an unguarded indirect
> > > call (the NULL check exists only under RTE_ETHDEV_DEBUG_RX/TX). So a
> > > thread calling e.g. rte_eth_rx_queue_count() on a port being stopped
> > > dereferences NULL and crashes, while the same race on rte_eth_rx_burst()
> > > is harmless because the burst ops are reset to dummies. A poll-mode
> > > worker re-checking rx_queue_count before arming the Rx interrupt and
> > > sleeping hits exactly this.
> > >
> > > Reset these ops to the same dummies eth_dev_set_dummy_fops() installs,
> > > so a stopped port behaves like a freshly allocated one: every fast-path
> > > op is a safe no-op, none is NULL.
> > >
> > > Fixes: 066f3d9cc21c ("ethdev: remove callback checks from fast path")
> > > Cc: stable@dpdk.org
> > > Signed-off-by: Maxime Leroy <maxime@leroys.fr>
> > > ---
> > > lib/ethdev/ethdev_private.c | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> > > index 72a0723846..75ea3eedff 100644
> > > --- a/lib/ethdev/ethdev_private.c
> > > +++ b/lib/ethdev/ethdev_private.c
> > > @@ -263,6 +263,13 @@ eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
> > > *fpo = (struct rte_eth_fp_ops) {
> > > .rx_pkt_burst = dummy_eth_rx_burst,
> > > .tx_pkt_burst = dummy_eth_tx_burst,
> > > + .tx_pkt_prepare = rte_eth_tx_pkt_prepare_dummy,
> > > + .rx_queue_count = rte_eth_queue_count_dummy,
> > > + .tx_queue_count = rte_eth_queue_count_dummy,
> > > + .rx_descriptor_status = rte_eth_descriptor_status_dummy,
> > > + .tx_descriptor_status = rte_eth_descriptor_status_dummy,
> > > + .recycle_tx_mbufs_reuse = rte_eth_recycle_tx_mbufs_reuse_dummy,
> > > + .recycle_rx_descriptors_refill = rte_eth_recycle_rx_descriptors_refill_dummy,
> > > .rxq = {
> > > .data = (void **)&dummy_queues_array[port_id],
> > > .clbk = dummy_data,
> >
> > Could we replace eth_dev_set_dummy_fops() with a call to
> > eth_dev_fp_ops_reset() in rte_eth_dev_allocate?
> > I don't like keeping two separate helpers.
>
> Thanks for the review.
>
> Avoiding the duplication is a good idea, but I could not find a clean
> way to do it: eth_dev_set_dummy_fops() and eth_dev_fp_ops_reset()
> cannot be unified without making things worse.
>
> - They write two different structures. eth_dev_set_dummy_fops() sets
> struct rte_eth_dev (the source ops); rte_eth_dev_allocate() fills
> eth_dev->*, and eth_dev_fp_ops_setup() then copies eth_dev->* into the
> per-port struct rte_eth_fp_ops. eth_dev_fp_ops_reset() writes that
> fast-path table entry directly. So calling fp_ops_reset() from
> rte_eth_dev_allocate() would populate the wrong structure.
>
> - The burst dummies are intentionally different. set_dummy_fops() uses
> the silent rte_eth_pkt_burst_dummy (a freshly allocated,
> not-yet-started port is benign), while fp_ops_reset() uses
> dummy_eth_rx_burst/dummy_eth_tx_burst, which log an error and dump the
> stack because hitting the data path on a stopped port is a misuse
> worth flagging.
>
> - fp_ops_reset() also wires fpo->rxq/txq to the
> dummy_queues_array/dummy_data used by the fast-path table, with no
> equivalent on rte_eth_dev.
>
> The only shared part is the non-burst dummy assignments, but factoring
> those across the two different struct types would require a token
> macro, and I don't have a clean solution for it. So for now I have
> kept the two helpers as they are. Suggestions welcome.
Ok, I had missed the separate structs.
Let's keep it simple, and avoid adding macros.
Can you add a comment that those helpers should be kept in sync?
--
David Marchand
^ permalink raw reply
* [PATCH] app/testpmd: include IP fields in UDP RSS option
From: Maxime Leroy @ 2026-06-16 9:39 UTC (permalink / raw)
To: dev
Cc: Maxime Leroy, stable, Aman Singh, Heqing Zhu, Jijiang Liu,
Helin Zhang, Cunming Liang, Jing Chen
The --rss-udp option is documented as enabling IPv4/IPv6 + UDP RSS, but it
currently sets the RSS hash functions to RTE_ETH_RSS_UDP only.
On PMDs that translate this directly to L4 port extracts, this can build a
L4-only RSS key. Add RTE_ETH_RSS_IP when --rss-udp is selected so the
configured key matches the documented IPv4/IPv6 + UDP behavior.
Make --rss-ip additive as well, so combining --rss-ip and --rss-udp is
order-independent.
Fixes: 8a387fa85f02 ("ethdev: more RSS flags")
Cc: stable@dpdk.org
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
---
app/test-pmd/parameters.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 337d8fc8ac..0032ea4e25 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -1286,10 +1286,10 @@ launch_args_parse(int argc, char** argv)
set_pkt_forwarding_mode(optarg);
break;
case TESTPMD_OPT_RSS_IP_NUM:
- rss_hf = RTE_ETH_RSS_IP;
+ rss_hf |= RTE_ETH_RSS_IP;
break;
case TESTPMD_OPT_RSS_UDP_NUM:
- rss_hf = RTE_ETH_RSS_UDP;
+ rss_hf |= RTE_ETH_RSS_IP | RTE_ETH_RSS_UDP;
break;
case TESTPMD_OPT_RSS_LEVEL_INNER_NUM:
rss_hf |= RTE_ETH_RSS_LEVEL_INNERMOST;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] ethdev: fix fast-path ops on a stopped port
From: Maxime Leroy @ 2026-06-16 9:42 UTC (permalink / raw)
To: dev; +Cc: Maxime Leroy
Two small fixes for fast-path ops on a stopped port:
patch 1 stops rte_eth_rx_queue_count() from dereferencing NULL after a port
stop, patch 2 makes the dummy queue count return 0 (empty queue) instead of
-ENOTSUP.
Maxime Leroy (2):
ethdev: keep fast-path ops valid after port stop
ethdev: return 0 from dummy queue count
lib/ethdev/ethdev_driver.c | 2 +-
lib/ethdev/ethdev_private.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] ethdev: keep fast-path ops valid after port stop
From: Maxime Leroy @ 2026-06-16 9:42 UTC (permalink / raw)
To: dev
Cc: Maxime Leroy, stable, Morten Brørup, Thomas Monjalon,
Andrew Rybchenko, Sunil Kumar Kori
In-Reply-To: <20260616094259.686555-1-maxime@leroys.fr>
eth_dev_fp_ops_reset() restores a port's fast-path ops on stop/release
via a compound literal, so every field it omits is zeroed to NULL. It
sets only rx_pkt_burst/tx_pkt_burst (and the rxq/txq data), leaving
rx_queue_count, tx_queue_count, rx/tx_descriptor_status, tx_pkt_prepare
and the recycle callbacks NULL.
In non-debug builds these ops are reached through an unguarded indirect
call (the NULL check exists only under RTE_ETHDEV_DEBUG_RX/TX). So a
thread calling e.g. rte_eth_rx_queue_count() on a port being stopped
dereferences NULL and crashes, while the same race on rte_eth_rx_burst()
is harmless because the burst ops are reset to dummies. A poll-mode
worker re-checking rx_queue_count before arming the Rx interrupt and
sleeping hits exactly this.
Reset these non-burst ops to the same dummies eth_dev_set_dummy_fops()
installs, so a stopped port behaves like a freshly allocated one: every
fast-path op is a safe no-op, none is NULL.
Fixes: 066f3d9cc21c ("ethdev: remove callback checks from fast path")
Cc: stable@dpdk.org
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
lib/ethdev/ethdev_private.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
index 72a0723846..75ea3eedff 100644
--- a/lib/ethdev/ethdev_private.c
+++ b/lib/ethdev/ethdev_private.c
@@ -263,6 +263,13 @@ eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
*fpo = (struct rte_eth_fp_ops) {
.rx_pkt_burst = dummy_eth_rx_burst,
.tx_pkt_burst = dummy_eth_tx_burst,
+ .tx_pkt_prepare = rte_eth_tx_pkt_prepare_dummy,
+ .rx_queue_count = rte_eth_queue_count_dummy,
+ .tx_queue_count = rte_eth_queue_count_dummy,
+ .rx_descriptor_status = rte_eth_descriptor_status_dummy,
+ .tx_descriptor_status = rte_eth_descriptor_status_dummy,
+ .recycle_tx_mbufs_reuse = rte_eth_recycle_tx_mbufs_reuse_dummy,
+ .recycle_rx_descriptors_refill = rte_eth_recycle_rx_descriptors_refill_dummy,
.rxq = {
.data = (void **)&dummy_queues_array[port_id],
.clbk = dummy_data,
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] ethdev: return 0 from dummy queue count
From: Maxime Leroy @ 2026-06-16 9:42 UTC (permalink / raw)
To: dev
Cc: Maxime Leroy, stable, Stephen Hemminger, Thomas Monjalon,
Andrew Rybchenko, Sunil Kumar Kori, Morten Brørup
In-Reply-To: <20260616094259.686555-1-maxime@leroys.fr>
The dummy rx_queue_count/tx_queue_count callback returned -ENOTSUP. On a
port that is not started (freshly allocated, or stopped once the fast-path
ops are reset to dummies) there are no packets queued, so the truthful
answer is 0, not an error: querying the count is not an unsupported
operation. This also matches the dummy Rx/Tx burst, which reports 0
packets.
A poll-mode worker checking rte_eth_rx_queue_count() across a concurrent
port stop then sees an empty queue instead of a negative error.
Fixes: 066f3d9cc21c ("ethdev: remove callback checks from fast path")
Cc: stable@dpdk.org
Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
---
lib/ethdev/ethdev_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c
index 70ddce5bfc..eab5c15d12 100644
--- a/lib/ethdev/ethdev_driver.c
+++ b/lib/ethdev/ethdev_driver.c
@@ -875,7 +875,7 @@ RTE_EXPORT_INTERNAL_SYMBOL(rte_eth_queue_count_dummy)
int
rte_eth_queue_count_dummy(void *queue __rte_unused)
{
- return -ENOTSUP;
+ return 0;
}
RTE_EXPORT_INTERNAL_SYMBOL(rte_eth_descriptor_status_dummy)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dts: avoid Scapy MAC resolution in Rx split test
From: Thomas Monjalon @ 2026-06-16 9:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Luca Vizzarro, Patrick Robb
In-Reply-To: <20260611115421.12c4e6ee@phoenix.local>
11/06/2026 20:54, Stephen Hemminger:
> On Wed, 10 Jun 2026 20:32:18 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > The test gets the Ethernet header length from Scapy with len(Ether()).
> >
> > When building DTS API documentation, Sphinx imports the test module
> > and shows this warning:
> > WARNING: MAC address to reach destination not found. Using broadcast.
> >
> > Use a dummy MAC address so Scapy no longer performs
> > destination resolution during import.
> >
> > Fixes: 01c70544cffd ("dts: add selective Rx tests")
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>
> Thanks, I previously reported this as:
>
> https://bugs.dpdk.org/show_bug.cgi?id=1951
OK, added the tag in the commit log.
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Applied
^ permalink raw reply
* RE: [PATCH 2/2] ethdev: return 0 from dummy queue count
From: Morten Brørup @ 2026-06-16 9:54 UTC (permalink / raw)
To: Maxime Leroy, dev
Cc: stable, Stephen Hemminger, Thomas Monjalon, Andrew Rybchenko,
Sunil Kumar Kori
In-Reply-To: <20260616094259.686555-3-maxime@leroys.fr>
> From: Maxime Leroy [mailto:maxime.leroys@gmail.com] On Behalf Of Maxime
> Leroy
> Sent: Tuesday, 16 June 2026 11.43
>
> The dummy rx_queue_count/tx_queue_count callback returned -ENOTSUP. On
> a
> port that is not started (freshly allocated, or stopped once the fast-
> path
> ops are reset to dummies) there are no packets queued, so the truthful
> answer is 0, not an error: querying the count is not an unsupported
> operation. This also matches the dummy Rx/Tx burst, which reports 0
> packets.
>
> A poll-mode worker checking rte_eth_rx_queue_count() across a
> concurrent
> port stop then sees an empty queue instead of a negative error.
>
> Fixes: 066f3d9cc21c ("ethdev: remove callback checks from fast path")
> Cc: stable@dpdk.org
>
> Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Maxime Leroy <maxime@leroys.fr>
> ---
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* [PATCH v2 0/6] net/dpaa2: NAPI-style Rx queue interrupts
From: Maxime Leroy @ 2026-06-16 10:27 UTC (permalink / raw)
To: dev; +Cc: Maxime Leroy
In-Reply-To: <20260611154926.392670-1-maxime@leroys.fr>
This series lets a dpaa2 worker sleep on a queue's data-availability
notification instead of busy-polling, exposed through the generic
rte_eth_dev_rx_intr_* API (NAPI-style: poll while frames keep coming,
arm the interrupt and sleep when the queue runs dry).
Why it is not a trivial .rx_queue_intr_enable
----------------------------------------------
A worker wakes on its software portal's DQRI, which fires when the
portal's DQRR holds frames. The default dpaa2 Rx burst pulls frames
from the FQ with a volatile dequeue and cannot be interrupt-driven; to
wake on the DQRI the FQ must instead be pushed to the portal's DQRR.
The natural dpni_set_queue with a notification destination would have to
target the worker's portal, but that portal is only known once a worker
affines, after dev_start, and that MC command holds the global MC lock
long enough to wedge the firmware while traffic runs. So the bind cannot
be done late, against the polling lcore.
Design
------
Each Rx FQ is bound to its own DPCON channel, statically, at dev_start
while the dpni is still disabled (no knowledge of the polling lcore). A
worker later subscribes its own ethrx portal to the channel and arms the
DQRI in rx_queue_intr_enable, a one-shot per-portal op, never the wedging
set_queue. One portal serves every queue a worker owns, so the DQRR
burst demuxes frames to their FQ by fqd_ctx; foreign frames are parked in
the target queue's stash, so the application polls all its queues after a
wakeup, the same scheduling contract as plain DPDK polling. A queue can
be re-homed to another lcore at runtime with no set_queue and no port
stop.
This reuses the event PMD's pushed/DQRR model but with one DPCON per FQ
and static affinity (no QBMan scheduling), so the DPCON allocator is
moved from the event driver to the fslmc bus and shared.
Patches 1 and 2 move the DPCON allocator to the fslmc bus and make the
portal DQRI epoll optional; patch 3 adds the interrupt support proper and
patch 4 tunes the DQRI coalescing holdoff. Patch 5 (rx_queue_count NULL on
the primary process) is a real fix the path depends on and uncovered,
tagged for stable and backportable on its own. Patch 6 (drop the software
VLAN strip) is an independent net/dpaa2 change the interrupt path does not
require.
The path also depends on two fixes sent separately: an eal change so the
shared portal eventfd does not fail with -EEXIST (already applied to main)
and the ethdev fix for fast-path ops left NULL after port stop (see
Depends-on below).
Tested on LX2160A (lx2160acex7).
Depends-on: series-38450 ("ethdev: fix fast-path ops on a stopped port")
v2:
- Dropped the RSS RETA patch, an independent net/dpaa2 change the
interrupt path does not require; it will be sent as its own series.
- Dropped the ethdev fast-path ops fix; it is now a standalone series
(Depends-on above).
- Dropped the eal/interrupts -EEXIST fix, applied to main by David Marchand.
- Declared qbman_swp_interrupt_set_inhibit and qbman_swp_dqrr_size
__rte_internal (David Marchand).
- Minor formatting cleanup in the Rx interrupt setup.
Maxime Leroy (6):
bus/fslmc: move DPCON management from event driver to bus
bus/fslmc/dpio: make the portal DQRI epoll optional
net/dpaa2: support Rx queue interrupts
bus/fslmc/dpio: tune DQRI interrupt coalescing holdoff
net/dpaa2: fix Rx queue count for primary process
net/dpaa2: drop the fake software VLAN strip offload
doc/guides/nics/dpaa2.rst | 10 +
doc/guides/nics/features/dpaa2.ini | 1 +
doc/guides/rel_notes/release_26_07.rst | 7 +
drivers/bus/fslmc/meson.build | 1 +
.../fslmc/portal}/dpaa2_hw_dpcon.c | 16 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 113 ++++--
drivers/bus/fslmc/portal/dpaa2_hw_dpio.h | 12 +
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 35 +-
.../fslmc/qbman/include/fsl_qbman_portal.h | 11 +
drivers/bus/fslmc/qbman/qbman_portal.c | 7 +
drivers/event/dpaa2/dpaa2_eventdev.h | 5 +-
drivers/event/dpaa2/meson.build | 1 -
drivers/net/dpaa2/dpaa2_ethdev.c | 349 +++++++++++++++++-
drivers/net/dpaa2/dpaa2_ethdev.h | 10 +
drivers/net/dpaa2/dpaa2_rxtx.c | 123 +++++-
15 files changed, 647 insertions(+), 54 deletions(-)
rename drivers/{event/dpaa2 => bus/fslmc/portal}/dpaa2_hw_dpcon.c (90%)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/6] bus/fslmc: move DPCON management from event driver to bus
From: Maxime Leroy @ 2026-06-16 10:27 UTC (permalink / raw)
To: dev; +Cc: Maxime Leroy, Hemant Agrawal, Sachin Saxena
In-Reply-To: <20260616102727.708948-1-maxime@leroys.fr>
The DPCON allocation helpers (rte_dpaa2_alloc_dpcon_dev /
rte_dpaa2_free_dpcon_dev) lived in the event driver, but a notification
channel is a generic QBMan resource. Move dpaa2_hw_dpcon.c to the fslmc
bus and export the helpers as internal symbols so both the event PMD and
the net driver's rx-queue interrupt path can draw channels from the same
pool. No functional change.
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
---
drivers/bus/fslmc/meson.build | 1 +
.../dpaa2 => bus/fslmc/portal}/dpaa2_hw_dpcon.c | 16 +++++++---------
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 8 ++++++++
drivers/event/dpaa2/dpaa2_eventdev.h | 5 +++--
drivers/event/dpaa2/meson.build | 1 -
5 files changed, 19 insertions(+), 12 deletions(-)
rename drivers/{event/dpaa2 => bus/fslmc/portal}/dpaa2_hw_dpcon.c (90%)
diff --git a/drivers/bus/fslmc/meson.build b/drivers/bus/fslmc/meson.build
index ceae1c6c11..50d9e91a37 100644
--- a/drivers/bus/fslmc/meson.build
+++ b/drivers/bus/fslmc/meson.build
@@ -22,6 +22,7 @@ sources = files(
'mc/mc_sys.c',
'portal/dpaa2_hw_dpbp.c',
'portal/dpaa2_hw_dpci.c',
+ 'portal/dpaa2_hw_dpcon.c',
'portal/dpaa2_hw_dpio.c',
'portal/dpaa2_hw_dprc.c',
'qbman/qbman_portal.c',
diff --git a/drivers/event/dpaa2/dpaa2_hw_dpcon.c b/drivers/bus/fslmc/portal/dpaa2_hw_dpcon.c
similarity index 90%
rename from drivers/event/dpaa2/dpaa2_hw_dpcon.c
rename to drivers/bus/fslmc/portal/dpaa2_hw_dpcon.c
index ea5b0d4b85..6fd96ec0b9 100644
--- a/drivers/event/dpaa2/dpaa2_hw_dpcon.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpcon.c
@@ -18,13 +18,12 @@
#include <rte_cycles.h>
#include <rte_kvargs.h>
#include <dev_driver.h>
-#include <ethdev_driver.h>
+#include <eal_export.h>
#include <bus_fslmc_driver.h>
#include <mc/fsl_dpcon.h>
#include <portal/dpaa2_hw_pvt.h>
-#include "dpaa2_eventdev.h"
-#include "dpaa2_eventdev_logs.h"
+#include <fslmc_logs.h>
TAILQ_HEAD(dpcon_dev_list, dpaa2_dpcon_dev);
static struct dpcon_dev_list dpcon_dev_list
@@ -55,8 +54,7 @@ rte_dpaa2_create_dpcon_device(int dev_fd __rte_unused,
/* Allocate DPAA2 dpcon handle */
dpcon_node = rte_malloc(NULL, sizeof(struct dpaa2_dpcon_dev), 0);
if (!dpcon_node) {
- DPAA2_EVENTDEV_ERR(
- "Memory allocation failed for dpcon device");
+ DPAA2_BUS_ERR("Memory allocation failed for dpcon device");
return -1;
}
@@ -65,8 +63,7 @@ rte_dpaa2_create_dpcon_device(int dev_fd __rte_unused,
ret = dpcon_open(&dpcon_node->dpcon,
CMD_PRI_LOW, dpcon_id, &dpcon_node->token);
if (ret) {
- DPAA2_EVENTDEV_ERR("Unable to open dpcon device: err(%d)",
- ret);
+ DPAA2_BUS_ERR("Unable to open dpcon device: err(%d)", ret);
rte_free(dpcon_node);
return -1;
}
@@ -75,8 +72,7 @@ rte_dpaa2_create_dpcon_device(int dev_fd __rte_unused,
ret = dpcon_get_attributes(&dpcon_node->dpcon,
CMD_PRI_LOW, dpcon_node->token, &attr);
if (ret != 0) {
- DPAA2_EVENTDEV_ERR("dpcon attribute fetch failed: err(%d)",
- ret);
+ DPAA2_BUS_ERR("dpcon attribute fetch failed: err(%d)", ret);
rte_free(dpcon_node);
return -1;
}
@@ -92,6 +88,7 @@ rte_dpaa2_create_dpcon_device(int dev_fd __rte_unused,
return 0;
}
+RTE_EXPORT_INTERNAL_SYMBOL(rte_dpaa2_alloc_dpcon_dev)
struct dpaa2_dpcon_dev *rte_dpaa2_alloc_dpcon_dev(void)
{
struct dpaa2_dpcon_dev *dpcon_dev = NULL;
@@ -105,6 +102,7 @@ struct dpaa2_dpcon_dev *rte_dpaa2_alloc_dpcon_dev(void)
return dpcon_dev;
}
+RTE_EXPORT_INTERNAL_SYMBOL(rte_dpaa2_free_dpcon_dev)
void rte_dpaa2_free_dpcon_dev(struct dpaa2_dpcon_dev *dpcon)
{
struct dpaa2_dpcon_dev *dpcon_dev = NULL;
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
index e625a5c035..79a2ec41e3 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
@@ -274,6 +274,14 @@ struct dpaa2_dpcon_dev {
uint8_t channel_index;
};
+/* DPCON channel allocation -- managed by the fslmc bus so both the net
+ * NAPI/DQRR rx path and the event PMD can grab channels.
+ */
+__rte_internal
+struct dpaa2_dpcon_dev *rte_dpaa2_alloc_dpcon_dev(void);
+__rte_internal
+void rte_dpaa2_free_dpcon_dev(struct dpaa2_dpcon_dev *dpcon);
+
/* Refer to Table 7-3 in SEC BG */
#define QBMAN_FLE_WORD4_FMT_SBF 0x0 /* Single buffer frame */
#define QBMAN_FLE_WORD4_FMT_SGE 0x2 /* Scatter gather frame */
diff --git a/drivers/event/dpaa2/dpaa2_eventdev.h b/drivers/event/dpaa2/dpaa2_eventdev.h
index bb87bdbab2..f53efce61c 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev.h
+++ b/drivers/event/dpaa2/dpaa2_eventdev.h
@@ -85,8 +85,9 @@ struct dpaa2_eventdev {
uint32_t event_dev_cfg;
};
-struct dpaa2_dpcon_dev *rte_dpaa2_alloc_dpcon_dev(void);
-void rte_dpaa2_free_dpcon_dev(struct dpaa2_dpcon_dev *dpcon);
+/* rte_dpaa2_alloc_dpcon_dev()/rte_dpaa2_free_dpcon_dev() now live in the fslmc
+ * bus (portal/dpaa2_hw_pvt.h), which this header's includers already pull in.
+ */
int test_eventdev_dpaa2(void);
diff --git a/drivers/event/dpaa2/meson.build b/drivers/event/dpaa2/meson.build
index dd5063af43..62b8507652 100644
--- a/drivers/event/dpaa2/meson.build
+++ b/drivers/event/dpaa2/meson.build
@@ -7,7 +7,6 @@ if not is_linux
endif
deps += ['bus_vdev', 'net_dpaa2', 'crypto_dpaa2_sec']
sources = files(
- 'dpaa2_hw_dpcon.c',
'dpaa2_eventdev.c',
'dpaa2_eventdev_selftest.c',
)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/6] bus/fslmc/dpio: make the portal DQRI epoll optional
From: Maxime Leroy @ 2026-06-16 10:27 UTC (permalink / raw)
To: dev; +Cc: Maxime Leroy, Hemant Agrawal, Sachin Saxena
In-Reply-To: <20260616102727.708948-1-maxime@leroys.fr>
dpaa2_dpio_intr_init() builds a private epoll instance the event PMD
sleeps on. The upcoming net rx-queue-interrupt path waits on the
application's own epoll instead, so that instance would be built but
never used.
Add a build_epoll parameter: pass true to build it (event PMD), false
to skip the epoll_create/epoll_ctl. epoll_fd is set to -1 when none is
built and closed in intr_deinit only when valid. The sole caller passes
true: no functional change.
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
---
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 44 +++++++++++++++++-------
1 file changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
index 2a9e519668..3a5abb2e6d 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
@@ -205,13 +205,12 @@ dpaa2_affine_dpio_intr_to_respective_core(int32_t dpio_id, int cpu_id)
fclose(file);
}
-static int dpaa2_dpio_intr_init(struct dpaa2_dpio_dev *dpio_dev)
+static int dpaa2_dpio_intr_init(struct dpaa2_dpio_dev *dpio_dev, bool build_epoll)
{
struct epoll_event epoll_ev;
int eventfd, dpio_epoll_fd, ret;
int threshold = 0x3, timeout = 0xFF;
- dpio_epoll_fd = epoll_create(1);
ret = rte_dpaa2_intr_enable(dpio_dev->intr_handle, 0);
if (ret) {
DPAA2_BUS_ERR("Interrupt registration failed");
@@ -231,16 +230,34 @@ static int dpaa2_dpio_intr_init(struct dpaa2_dpio_dev *dpio_dev)
qbman_swp_dqrr_thrshld_write(dpio_dev->sw_portal, threshold);
qbman_swp_intr_timeout_write(dpio_dev->sw_portal, timeout);
- eventfd = rte_intr_fd_get(dpio_dev->intr_handle);
- epoll_ev.events = EPOLLIN | EPOLLPRI | EPOLLET;
- epoll_ev.data.fd = eventfd;
+ dpio_dev->epoll_fd = -1;
- ret = epoll_ctl(dpio_epoll_fd, EPOLL_CTL_ADD, eventfd, &epoll_ev);
- if (ret < 0) {
- DPAA2_BUS_ERR("epoll_ctl failed");
- return -1;
+ /* The event PMD dequeues by sleeping on a private epoll instance owned
+ * by the portal, so build it here. A caller that waits on another
+ * epoll (the net rx-queue-interrupt path uses the application's) skips
+ * this.
+ */
+ if (build_epoll) {
+ dpio_epoll_fd = epoll_create(1);
+ if (dpio_epoll_fd < 0) {
+ DPAA2_BUS_ERR("epoll_create failed");
+ rte_dpaa2_intr_disable(dpio_dev->intr_handle, 0);
+ return -1;
+ }
+
+ eventfd = rte_intr_fd_get(dpio_dev->intr_handle);
+ epoll_ev.events = EPOLLIN | EPOLLPRI | EPOLLET;
+ epoll_ev.data.fd = eventfd;
+
+ ret = epoll_ctl(dpio_epoll_fd, EPOLL_CTL_ADD, eventfd, &epoll_ev);
+ if (ret < 0) {
+ DPAA2_BUS_ERR("epoll_ctl failed");
+ rte_dpaa2_intr_disable(dpio_dev->intr_handle, 0);
+ close(dpio_epoll_fd);
+ return -1;
+ }
+ dpio_dev->epoll_fd = dpio_epoll_fd;
}
- dpio_dev->epoll_fd = dpio_epoll_fd;
return 0;
}
@@ -253,7 +270,10 @@ static void dpaa2_dpio_intr_deinit(struct dpaa2_dpio_dev *dpio_dev)
if (ret)
DPAA2_BUS_ERR("DPIO interrupt disable failed");
- close(dpio_dev->epoll_fd);
+ if (dpio_dev->epoll_fd >= 0) {
+ close(dpio_dev->epoll_fd);
+ dpio_dev->epoll_fd = -1;
+ }
}
#endif
@@ -277,7 +297,7 @@ dpaa2_configure_stashing(struct dpaa2_dpio_dev *dpio_dev, int cpu_id)
}
#ifdef RTE_EVENT_DPAA2
- if (dpaa2_dpio_intr_init(dpio_dev)) {
+ if (dpaa2_dpio_intr_init(dpio_dev, true)) {
DPAA2_BUS_ERR("Interrupt registration failed for dpio");
return -1;
}
--
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