* Re: [PATCH 5/6] net/idpf: fix split queue AVX2 Tx buffer size shift
From: Bruce Richardson @ 2026-05-20 12:23 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-6-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:34PM +0530, Shaiq Wani wrote:
> The flex scheduled Tx descriptor (DTYPE 0x0C) used in split queue mode
> places the buffer size at bits 48-63 of QW1, requiring a left-shift
> of 48. The code incorrectly used IDPF_TXD_QW1_TX_BUF_SZ_S (34),
> which is the shift for base Tx descriptors (DTYPE 0x0) used in single
> queue mode.
>
> This caused the data_len to be placed in the wrong bit position,
> resulting in hardware reading an incorrect buffer size of zero.
>
> Define IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S (48) for the flex descriptor
> layout and use it in both vtx1 and vtx_avx2, consistent with the
> AVX512 split queue Tx path.
>
> Fixes: 57560a92167a ("net/idpf: add AVX2 Tx path for split queue config")
> Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> index e66dcc7a14..7c547b5f09 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> @@ -819,6 +819,8 @@ idpf_splitq_scan_cq_ring(struct ci_tx_queue *cq)
> cq->tx_tail = cq_qid;
> }
>
> +#define IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S 48
> +
> static __rte_always_inline void
> idpf_splitq_vtx1_avx2(struct idpf_flex_tx_sched_desc *txdp,
> struct rte_mbuf *pkt, uint64_t flags)
> @@ -826,7 +828,7 @@ idpf_splitq_vtx1_avx2(struct idpf_flex_tx_sched_desc *txdp,
> uint64_t high_qw =
> IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE |
> ((uint64_t)flags) |
> - ((uint64_t)pkt->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
> + ((uint64_t)pkt->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
>
> __m128i descriptor = _mm_set_epi64x(high_qw,
> pkt->buf_iova + pkt->data_off);
> @@ -848,13 +850,13 @@ idpf_splitq_vtx_avx2(struct idpf_flex_tx_sched_desc *txdp,
> for (; nb_pkts >= IDPF_VPMD_DESCS_PER_LOOP; txdp += IDPF_VPMD_DESCS_PER_LOOP,
> pkt += IDPF_VPMD_DESCS_PER_LOOP, nb_pkts -= IDPF_VPMD_DESCS_PER_LOOP) {
> uint64_t hi_qw0 = hi_qw_tmpl |
> - ((uint64_t)pkt[0]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
> + ((uint64_t)pkt[0]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
> uint64_t hi_qw1 = hi_qw_tmpl |
> - ((uint64_t)pkt[1]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
> + ((uint64_t)pkt[1]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
> uint64_t hi_qw2 = hi_qw_tmpl |
> - ((uint64_t)pkt[2]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
> + ((uint64_t)pkt[2]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
> uint64_t hi_qw3 = hi_qw_tmpl |
> - ((uint64_t)pkt[3]->data_len << IDPF_TXD_QW1_TX_BUF_SZ_S);
> + ((uint64_t)pkt[3]->data_len << IDPF_TXD_FLEX_QW1_TX_BUF_SZ_S);
>
> __m256i desc0_1 = _mm256_set_epi64x(hi_qw1,
> pkt[1]->buf_iova + pkt[1]->data_off,
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 4/6] net/idpf: fix ptype insert position in split queue AVX2 Rx
From: Bruce Richardson @ 2026-05-20 12:22 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-5-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:33PM +0530, Shaiq Wani wrote:
> The __m256i register mb10 holds rearm data for two mbufs: mbuf 0 in
> the low 128-bit lane (dwords 0-3) and mbuf 1 in the high 128-bit
> lane (dwords 4-7). The packet_type field sits at dword 0 within
> each mbuf's rearm_data layout.
>
> For mbuf 1 (high lane), the packet_type must be inserted at
> _mm256_insert_epi32 index 4 (first dword of the high 128-bit lane).
> Index 2 is the third dword of the low lane, which overwrites the
> wrong mbuf's data. The same applies to mb32 for mbuf 3.
>
> Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
> Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> index d3a8e17778..e66dcc7a14 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> @@ -570,9 +570,9 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
> ptype2 = (uint16_t)_mm256_extract_epi16(pt32, 1);
> ptype3 = (uint16_t)_mm256_extract_epi16(pt32, 9);
>
> - mb10 = _mm256_insert_epi32(mb10, (int)ptype_tbl[ptype1], 2);
> + mb10 = _mm256_insert_epi32(mb10, (int)ptype_tbl[ptype1], 4);
> mb10 = _mm256_insert_epi32(mb10, (int)ptype_tbl[ptype0], 0);
> - mb32 = _mm256_insert_epi32(mb32, (int)ptype_tbl[ptype3], 2);
> + mb32 = _mm256_insert_epi32(mb32, (int)ptype_tbl[ptype3], 4);
> mb32 = _mm256_insert_epi32(mb32, (int)ptype_tbl[ptype2], 0);
>
> /* Build rearm data for each mbuf */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 3/6] net/idpf: fix mbuf initializer source in split queue AVX2 Rx
From: Bruce Richardson @ 2026-05-20 12:21 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-4-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:32PM +0530, Shaiq Wani wrote:
> In split queue mode the completion queue (rxq) does not own the mbuf
> pool — the buffer queue (bufq2) does. The mbuf initializer encodes
> the mempool pointer, refcount and other per-pool mbuf metadata that
> is stamped into every received mbuf during rearm.
>
> Using queue->mbuf initializer reads an uninitialised or zero value
> from the completion queue, corrupting every mbuf rearm. Use
> queue->bufq2->mbuf initializer to get the correct value from the
> buffer queue that actually owns the mbufs.
>
> Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
> Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> index 28d4246134..d3a8e17778 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> @@ -491,7 +491,7 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
> struct rte_mbuf **sw_ring = &queue->bufq2->sw_ring[queue->rx_tail];
> volatile union virtchnl2_rx_desc *rxdp =
> (volatile union virtchnl2_rx_desc *)queue->rx_ring + queue->rx_tail;
> - const __m256i mbuf_init = _mm256_set_epi64x(0, 0, 0, queue->mbuf_initializer);
> + const __m256i mbuf_init = _mm256_set_epi64x(0, 0, 0, queue->bufq2->mbuf_initializer);
> uint64_t head_gen;
> uint16_t received = 0;
> int i;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 2/6] net/idpf: fix DD bit byte offset in split queue AVX2 Rx
From: Bruce Richardson @ 2026-05-20 12:21 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-3-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:31PM +0530, Shaiq Wani wrote:
> The split queue completion descriptor (virtchnl2_rx_flex_desc_adv_nic_3)
> has two distinct status fields: status_err0_qw0 at byte offset 1 and
> status_err0_qw1 at byte offset 8. The DD (descriptor done) bit lives
> in status_err0_qw1 (byte 8), not status_err0_qw0 (byte 1).
>
> Byte 1 (status_err0_qw0) bit 0 is the LPBK (loopback) indicator, so
> reading DD from byte 1 checks the wrong field entirely.
>
> Fix the _mm_extract_epi8 index from 1 to 8 so the code reads the DD
> bit from its correct location in the writeback descriptor.
>
> Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
> Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> drivers/net/intel/idpf/idpf_common_rxtx_avx2.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> index cd10c27a30..28d4246134 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> @@ -587,11 +587,11 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
> _mm256_storeu_si256((__m256i *)&rx_pkts[i + 2]->rearm_data, rearm2);
> _mm256_storeu_si256((__m256i *)&rx_pkts[i + 3]->rearm_data, rearm3);
>
> - /* Extract DD and generation bits from the already-loaded descriptor data (d0-d3) */
> - stat0 = (uint8_t)_mm_extract_epi8(d0, 1);
> - stat1 = (uint8_t)_mm_extract_epi8(d1, 1);
> - stat2 = (uint8_t)_mm_extract_epi8(d2, 1);
> - stat3 = (uint8_t)_mm_extract_epi8(d3, 1);
> + /* Extract DD bit from status_err0_qw1 (byte 8 of descriptor) */
> + stat0 = (uint8_t)_mm_extract_epi8(d0, 8);
> + stat1 = (uint8_t)_mm_extract_epi8(d1, 8);
> + stat2 = (uint8_t)_mm_extract_epi8(d2, 8);
> + stat3 = (uint8_t)_mm_extract_epi8(d3, 8);
>
> pktlen_gen0 = (uint16_t)_mm_extract_epi16(d0, 2);
> pktlen_gen1 = (uint16_t)_mm_extract_epi16(d1, 2);
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 1/6] net/idpf: fix gen bit extraction in split queue AVX2 Rx
From: Bruce Richardson @ 2026-05-20 12:20 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-2-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:30PM +0530, Shaiq Wani wrote:
> The generation bit in the pktlen_gen_bufq_id field of the split queue
> completion descriptor (virtchnl2_rx_flex_desc_adv_nic_3) must be
> extracted by masking first and then shifting, not the other way around.
>
> With shift-then-mask, the mask is applied to already-shifted bits,
> which can produce incorrect results when upper bits (packet length,
> buffer queue ID) leak into the extracted value.
>
> Change to mask-then-shift to correctly isolate the generation bit
> before comparing it with the expected generation ID.
>
> Fixes: 1f065f9d75ff ("net/idpf: add AVX2 Rx path for split queue config")
> Signed-off-by: Shaiq Wani <shaiq.wani@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> .../net/intel/idpf/idpf_common_rxtx_avx2.c | 20 +++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> index db7728afad..cd10c27a30 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> @@ -524,8 +524,8 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
>
> /* check if there is at least one packet available */
> head_gen = rxdp->flex_adv_nic_3_wb.pktlen_gen_bufq_id;
> - if (((head_gen >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
> - VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) != queue->expected_gen_id)
> + if (((head_gen & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
> + VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) != queue->expected_gen_id)
> return 0;
>
> for (i = 0; i < nb_pkts;
> @@ -599,17 +599,17 @@ idpf_dp_splitq_recv_pkts_avx2(void *rxq, struct rte_mbuf **rx_pkts, uint16_t nb_
> pktlen_gen3 = (uint16_t)_mm_extract_epi16(d3, 2);
>
> valid0 = (stat0 & 1) &&
> - (((pktlen_gen0 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
> - VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
> + (((pktlen_gen0 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
> + VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
> valid1 = (stat1 & 1) &&
> - (((pktlen_gen1 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
> - VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
> + (((pktlen_gen1 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
> + VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
> valid2 = (stat2 & 1) &&
> - (((pktlen_gen2 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
> - VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
> + (((pktlen_gen2 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
> + VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
> valid3 = (stat3 & 1) &&
> - (((pktlen_gen3 >> VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) &
> - VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) == queue->expected_gen_id);
> + (((pktlen_gen3 & VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M) >>
> + VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_S) == queue->expected_gen_id);
>
> /* count valid descriptors (holes are impossible because
> * descriptors are read in reverse order while the NIC
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags
From: Robin Jarry @ 2026-05-20 11:09 UTC (permalink / raw)
To: David Marchand; +Cc: dev
In-Reply-To: <CAJFAV8xdkhcmY53VRJf3qbsVsYB-hM3DaxMxr=GS5MNvb1MPGA@mail.gmail.com>
David Marchand, May 20, 2026 at 11:56:
> On Mon, 18 May 2026 at 15:27, Robin Jarry <rjarry@redhat.com> wrote:
>>
>> The VLAN and QinQ code paths in rte_net_get_ptype handle at most two
>> tags with duplicated logic. Replace them with a single loop that
>> consumes all consecutive VLAN/QinQ headers regardless of depth.
>>
>> Bugzilla ID: 1941
>> Suggested-by: David Marchand <david.marchand@redhat.com>
>> Signed-off-by: Robin Jarry <rjarry@redhat.com>
>
> For the record, I am still skeptical about the usecase behind this change.
>
>
>> ---
>> lib/net/rte_net.c | 35 ++++++++++++++++-------------------
>> 1 file changed, 16 insertions(+), 19 deletions(-)
>>
>> diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c
>> index c70b57fdc0f8..d3cded961fb5 100644
>> --- a/lib/net/rte_net.c
>> +++ b/lib/net/rte_net.c
>> @@ -349,29 +349,26 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
>> if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4))
>> goto l3; /* fast path if packet is IPv4 */
>>
>> - if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
>> + if ((proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) ||
>> + (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_QINQ))) {
>> const struct rte_vlan_hdr *vh;
>> struct rte_vlan_hdr vh_copy;
>>
>> - pkt_type = RTE_PTYPE_L2_ETHER_VLAN;
>> - vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
>> - if (unlikely(vh == NULL))
>> - return pkt_type;
>> - off += sizeof(*vh);
>> - hdr_lens->l2_len += sizeof(*vh);
>> - proto = vh->eth_proto;
>> - } else if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_QINQ)) {
>> - const struct rte_vlan_hdr *vh;
>> - struct rte_vlan_hdr vh_copy;
>> + if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN))
>> + pkt_type = RTE_PTYPE_L2_ETHER_VLAN;
>> + else
>> + pkt_type = RTE_PTYPE_L2_ETHER_QINQ;
>> +
>> + do {
>> + vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
>> + if (unlikely(vh == NULL))
>> + return pkt_type;
>
> Kevin noted that it is weird to report back some packet type when the
> packet is malformed.
> Maybe return RTE_PTYPE_UNKNOWN here so that the application is forced
> to validate the packet? (it should already be doing it, in any
> case..).
If we do this, we need to fix it in the entire function. There are
several other places where the "current" value of pkt_type is returned
on error.
>
>
>> + off += sizeof(*vh);
>> + hdr_lens->l2_len += sizeof(*vh);
>> + proto = vh->eth_proto;
>> + } while (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN) ||
>> + proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_QINQ));
>>
>> - pkt_type = RTE_PTYPE_L2_ETHER_QINQ;
>> - vh = rte_pktmbuf_read(m, off + sizeof(*vh), sizeof(*vh),
>> - &vh_copy);
>> - if (unlikely(vh == NULL))
>> - return pkt_type;
>> - off += 2 * sizeof(*vh);
>> - hdr_lens->l2_len += 2 * sizeof(*vh);
>> - proto = vh->eth_proto;
>> } else if ((proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_MPLS)) ||
>> (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_MPLSM))) {
>> unsigned int i;
--
Robin
> Avoid contact with skin.
^ permalink raw reply
* Re: [PATCH dpdk v5 1/5] Revert "net: fix packet type for stacked VLAN"
From: Kevin Traynor @ 2026-05-20 10:24 UTC (permalink / raw)
To: Robin Jarry, dev, Gregory Etelson; +Cc: stable
In-Reply-To: <20260518132712.70913-9-rjarry@redhat.com>
On 5/18/26 2:27 PM, Robin Jarry wrote:
> This reverts commit 1f250674085aeb4ffd15ac2519a68efc04faf7ac.
>
> rte_net_get_ptype() now uses |= to set the L2 ptype inside the VLAN
> parsing loop. Since pkt_type is already initialized with
> RTE_PTYPE_L2_ETHER (0x1), or-ing it with RTE_PTYPE_L2_ETHER_VLAN (0x6)
> results in RTE_PTYPE_L2_ETHER_QINQ (0x7). This causes single VLAN frames
> to be misidentified as QinQ.
>
> This was detected while testing DPDK 25.11.1 in grout. The net/tap
> driver calls rte_net_get_ptype() in tap_verify_csum() to determine the
> L2 header length. With the wrong ptype, l2_len is set to 22 (ether
> + QinQ = 14 + 8) instead of 18 (ether + VLAN = 14 + 4), shifting the IP
> header pointer by 4 bytes. The checksum is then computed on garbage
> data, causing valid packets to be dropped.
>
> Bugzilla ID: 1941
> Fixes: 1f250674085a ("net: fix packet type for stacked VLAN")
> Cc: stable@dpdk.org
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> ---
> lib/net/rte_net.c | 29 +++++++++++++++--------------
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
^ permalink raw reply
* Re: [PATCH 0/3] i40e base code update
From: Bruce Richardson @ 2026-05-20 10:17 UTC (permalink / raw)
To: Ciara Loftus; +Cc: dev
In-Reply-To: <20260519145227.308814-1-ciara.loftus@intel.com>
On Tue, May 19, 2026 at 02:52:20PM +0000, Ciara Loftus wrote:
> Update the i40e base code. Both patches address integer type width issues
> that can cause incorrect behaviour and are candidates for stable backport.
>
> Chinh Cao (1):
> net/i40e/base: fix integer overflow in NVM timing logic
>
> Ciara Loftus (1):
> net/i40e/base: update version info
>
> Deepthi Kavalur (1):
> net/i40e/base: fix loop counter width in DCB parsing
>
Series-Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to dpdk-next-net-intel.
Thanks,
/Bruce
> .mailmap | 1 +
> drivers/net/intel/i40e/base/README | 4 +-
> drivers/net/intel/i40e/base/i40e_dcb.c | 6 +-
> drivers/net/intel/i40e/base/i40e_nvm.c | 67 +++++++++++++-------
> drivers/net/intel/i40e/base/i40e_prototype.h | 2 +-
> drivers/net/intel/i40e/base/i40e_type.h | 2 +-
> drivers/net/intel/i40e/i40e_ethdev.c | 3 +-
> 7 files changed, 55 insertions(+), 30 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags
From: David Marchand @ 2026-05-20 9:56 UTC (permalink / raw)
To: Robin Jarry; +Cc: dev
In-Reply-To: <20260518132712.70913-10-rjarry@redhat.com>
On Mon, 18 May 2026 at 15:27, Robin Jarry <rjarry@redhat.com> wrote:
>
> The VLAN and QinQ code paths in rte_net_get_ptype handle at most two
> tags with duplicated logic. Replace them with a single loop that
> consumes all consecutive VLAN/QinQ headers regardless of depth.
>
> Bugzilla ID: 1941
> Suggested-by: David Marchand <david.marchand@redhat.com>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
For the record, I am still skeptical about the usecase behind this change.
> ---
> lib/net/rte_net.c | 35 ++++++++++++++++-------------------
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c
> index c70b57fdc0f8..d3cded961fb5 100644
> --- a/lib/net/rte_net.c
> +++ b/lib/net/rte_net.c
> @@ -349,29 +349,26 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
> if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4))
> goto l3; /* fast path if packet is IPv4 */
>
> - if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
> + if ((proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) ||
> + (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_QINQ))) {
> const struct rte_vlan_hdr *vh;
> struct rte_vlan_hdr vh_copy;
>
> - pkt_type = RTE_PTYPE_L2_ETHER_VLAN;
> - vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
> - if (unlikely(vh == NULL))
> - return pkt_type;
> - off += sizeof(*vh);
> - hdr_lens->l2_len += sizeof(*vh);
> - proto = vh->eth_proto;
> - } else if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_QINQ)) {
> - const struct rte_vlan_hdr *vh;
> - struct rte_vlan_hdr vh_copy;
> + if (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN))
> + pkt_type = RTE_PTYPE_L2_ETHER_VLAN;
> + else
> + pkt_type = RTE_PTYPE_L2_ETHER_QINQ;
> +
> + do {
> + vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
> + if (unlikely(vh == NULL))
> + return pkt_type;
Kevin noted that it is weird to report back some packet type when the
packet is malformed.
Maybe return RTE_PTYPE_UNKNOWN here so that the application is forced
to validate the packet? (it should already be doing it, in any
case..).
> + off += sizeof(*vh);
> + hdr_lens->l2_len += sizeof(*vh);
> + proto = vh->eth_proto;
> + } while (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN) ||
> + proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_QINQ));
>
> - pkt_type = RTE_PTYPE_L2_ETHER_QINQ;
> - vh = rte_pktmbuf_read(m, off + sizeof(*vh), sizeof(*vh),
> - &vh_copy);
> - if (unlikely(vh == NULL))
> - return pkt_type;
> - off += 2 * sizeof(*vh);
> - hdr_lens->l2_len += 2 * sizeof(*vh);
> - proto = vh->eth_proto;
> } else if ((proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_MPLS)) ||
> (proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_MPLSM))) {
> unsigned int i;
--
David Marchand
^ permalink raw reply
* Re: [PATCH dpdk v5 1/5] Revert "net: fix packet type for stacked VLAN"
From: David Marchand @ 2026-05-20 9:47 UTC (permalink / raw)
To: Robin Jarry; +Cc: dev, Gregory Etelson, stable
In-Reply-To: <20260518132712.70913-9-rjarry@redhat.com>
On Mon, 18 May 2026 at 15:28, Robin Jarry <rjarry@redhat.com> wrote:
>
> This reverts commit 1f250674085aeb4ffd15ac2519a68efc04faf7ac.
>
> rte_net_get_ptype() now uses |= to set the L2 ptype inside the VLAN
> parsing loop. Since pkt_type is already initialized with
> RTE_PTYPE_L2_ETHER (0x1), or-ing it with RTE_PTYPE_L2_ETHER_VLAN (0x6)
> results in RTE_PTYPE_L2_ETHER_QINQ (0x7). This causes single VLAN frames
> to be misidentified as QinQ.
>
> This was detected while testing DPDK 25.11.1 in grout. The net/tap
> driver calls rte_net_get_ptype() in tap_verify_csum() to determine the
> L2 header length. With the wrong ptype, l2_len is set to 22 (ether
> + QinQ = 14 + 8) instead of 18 (ether + VLAN = 14 + 4), shifting the IP
> header pointer by 4 bytes. The checksum is then computed on garbage
> data, causing valid packets to be dropped.
>
> Bugzilla ID: 1941
> Fixes: 1f250674085a ("net: fix packet type for stacked VLAN")
> Cc: stable@dpdk.org
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
Acked-by: David Marchand <david.marchand@redhat.com>
Just a note that this commit is already present in all latest LTS releases.
--
David Marchand
^ permalink raw reply
* [PATCH v2 2/2] ethdev: add telemetry endpoint for list names
From: Chengwen Feng @ 2026-05-20 9:38 UTC (permalink / raw)
To: thomas, stephen; +Cc: dev, andrew.rybchenko, bruce.richardson, mb
In-Reply-To: <20260520093804.29102-1-fengchengwen@huawei.com>
Add /ethdev/list_names telemetry endpoint which returns a dictionary
keyed by port ID with device name as the value, so users can
identify ports by name directly from the telemetry output.
Original /ethdev/list output:
{"/ethdev/list": [0, 1]}
New /ethdev/list_names output:
{"/ethdev/list_names": {"0": "0000:7d:00.0",
"1": "0000:7d:00.1"}}
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
lib/ethdev/rte_ethdev_telemetry.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/lib/ethdev/rte_ethdev_telemetry.c b/lib/ethdev/rte_ethdev_telemetry.c
index a910864bc5..0e71419473 100644
--- a/lib/ethdev/rte_ethdev_telemetry.c
+++ b/lib/ethdev/rte_ethdev_telemetry.c
@@ -61,6 +61,24 @@ eth_dev_handle_port_list(const char *cmd __rte_unused,
return 0;
}
+static int
+eth_dev_handle_port_list_names(const char *cmd __rte_unused,
+ const char *params __rte_unused,
+ struct rte_tel_data *d)
+{
+ char id_str[RTE_TEL_MAX_STRING_LEN];
+ struct rte_eth_dev *dev;
+ int port_id;
+
+ rte_tel_data_start_dict(d);
+ RTE_ETH_FOREACH_DEV(port_id) {
+ dev = &rte_eth_devices[port_id];
+ sprintf(id_str, "%d", port_id);
+ rte_tel_data_add_dict_string(d, id_str, dev->data->name);
+ }
+ return 0;
+}
+
static int
eth_dev_parse_hide_zero(const char *key, const char *value, void *extra_args)
{
@@ -1548,6 +1566,9 @@ RTE_INIT(ethdev_init_telemetry)
rte_telemetry_register_cmd_arg("/ethdev/list",
eth_dev_telemetry_do, eth_dev_handle_port_list,
"Returns list of available ethdev ports. Takes no parameters");
+ rte_telemetry_register_cmd_arg("/ethdev/list_names",
+ eth_dev_telemetry_do, eth_dev_handle_port_list_names,
+ "Returns dict of available ethdev ports by ID-NAMEs. Takes no parameters");
rte_telemetry_register_cmd_arg("/ethdev/stats",
eth_dev_telemetry_do, eth_dev_handle_port_stats,
"Returns the common stats for a port. Parameters: int port_id");
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/2] dmadev: add telemetry endpoint for list names
From: Chengwen Feng @ 2026-05-20 9:38 UTC (permalink / raw)
To: thomas, stephen; +Cc: dev, andrew.rybchenko, bruce.richardson, mb
In-Reply-To: <20260520093804.29102-1-fengchengwen@huawei.com>
Add /dmadev/list_names telemetry endpoint which returns a dictionary
keyed by device ID with device name as the value, so users can
identify devices by name directly from the telemetry output.
Original /dmadev/list output:
{"/dmadev/list": [0, 1]}
New /dmadev/list_names output:
{"/dmadev/list_names": {"0": "hisi_sec2-0-dma0",
"1": "hisi_sec2-0-dma1"}}
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
lib/dmadev/rte_dmadev.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index b75b4f9bd1..98ef7e2b93 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -1157,6 +1157,27 @@ dmadev_handle_dev_list(const char *cmd __rte_unused,
return 0;
}
+static int
+dmadev_handle_dev_list_names(const char *cmd __rte_unused,
+ const char *params __rte_unused,
+ struct rte_tel_data *d)
+{
+ char id_str[RTE_TEL_MAX_STRING_LEN];
+ struct rte_dma_dev *dev;
+ int dev_id;
+
+ rte_tel_data_start_dict(d);
+ for (dev_id = 0; dev_id < dma_devices_max; dev_id++) {
+ if (!rte_dma_is_valid(dev_id))
+ continue;
+ dev = &rte_dma_devices[dev_id];
+ sprintf(id_str, "%d", dev_id);
+ rte_tel_data_add_dict_string(d, id_str, dev->data->dev_name);
+ }
+
+ return 0;
+}
+
#define ADD_CAPA(td, dc, c) rte_tel_data_add_dict_int(td, dma_capability_name(c), !!(dc & c))
static int
@@ -1309,6 +1330,8 @@ RTE_INIT(dmadev_init_telemetry)
{
rte_telemetry_register_cmd("/dmadev/list", dmadev_handle_dev_list,
"Returns list of available dmadev devices by IDs. No parameters.");
+ rte_telemetry_register_cmd("/dmadev/list_names", dmadev_handle_dev_list_names,
+ "Returns dict of available dmadev devices by ID-NAMEs. No parameters.");
rte_telemetry_register_cmd("/dmadev/info", dmadev_handle_dev_info,
"Returns information for a dmadev. Parameters: int dev_id");
rte_telemetry_register_cmd("/dmadev/stats", dmadev_handle_dev_stats,
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/2] Add list names telemetry endpoint
From: Chengwen Feng @ 2026-05-20 9:38 UTC (permalink / raw)
To: thomas, stephen; +Cc: dev, andrew.rybchenko, bruce.richardson, mb
In-Reply-To: <20260520035641.50555-1-fengchengwen@huawei.com>
Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
only integer IDs, making it hard to identify devices. This series add
list_names telemetry endpoint which output both IDs and its device's
name.
---
v2: Add new telemetry endpoint according Bruce's advise.
Chengwen Feng (2):
dmadev: add telemetry endpoint for list names
ethdev: add telemetry endpoint for list names
lib/dmadev/rte_dmadev.c | 23 +++++++++++++++++++++++
lib/ethdev/rte_ethdev_telemetry.c | 21 +++++++++++++++++++++
2 files changed, 44 insertions(+)
--
2.17.1
^ permalink raw reply
* [PATCH v2 2/2] doc: update recommended matching versions for cpfl and idpf
From: Soumyadeep Hore @ 2026-05-20 22:03 UTC (permalink / raw)
To: bruce.richardson, manoj.kumar.subbarao, aman.deep.singh, dev
In-Reply-To: <20260520220306.85273-1-soumyadeep.hore@intel.com>
Update the recommended MEV-ts release version corresponding to DPDK
release in the cpfl and idpf drivers documentation.
Signed-off-by: Soumyadeep Hore <soumyadeep.hore@intel.com>
---
doc/guides/nics/cpfl.rst | 21 ++++++++-------------
doc/guides/nics/idpf.rst | 19 ++++++++-----------
2 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst
index bc42c524ea..377397e621 100644
--- a/doc/guides/nics/cpfl.rst
+++ b/doc/guides/nics/cpfl.rst
@@ -28,19 +28,14 @@ It is highly recommended to upgrade the MEV-ts release
to avoid compatibility issues with the cpfl PMD.
Here is the suggested matching list which has been tested and verified.
- +------------+------------------+
- | DPDK | MEV-ts release |
- +============+==================+
- | 23.07 | 0.9.1 |
- +------------+------------------+
- | 23.11 | 1.0 |
- +------------+------------------+
- | 24.07 | 1.4 |
- +------------+------------------+
- | 24.11 | 1.6 |
- +------------+------------------+
- | 25.07 | 2.0 |
- +------------+------------------+
+===== ==============
+DPDK MEV-ts release
+===== ==============
+26.07 2.2
+25.11 2.0
+24.11 1.6
+23.11 1.0
+===== ==============
Configuration
diff --git a/doc/guides/nics/idpf.rst b/doc/guides/nics/idpf.rst
index c7c76190c8..cc89d22cf0 100644
--- a/doc/guides/nics/idpf.rst
+++ b/doc/guides/nics/idpf.rst
@@ -26,17 +26,14 @@ It is highly recommended to upgrade the idpf kernel driver, MEV-ts release
to avoid compatibility issues with the idpf PMD.
Here is the suggested matching list which has been tested and verified.
- +------------+---------------+------------------+
- | DPDK | Kernel Driver | MEV-ts release |
- +============+===============+==================+
- | 23.07 | 0.0.710 | 0.9.1 |
- +------------+---------------+------------------+
- | 23.11 | 0.0.720 | 1.0 |
- +------------+---------------+------------------+
- | 24.11 | 0.0.754 | 1.6 |
- +------------+---------------+------------------+
- | 25.07 | 0.0.772 | 2.0 |
- +------------+---------------+------------------+
+===== ============= ==============
+DPDK Kernel Driver MEV-ts release
+===== ============= ==============
+26.07 0.0.780 2.2
+25.11 0.0.772 2.0
+24.11 0.0.754 1.6
+23.11 0.0.720 1.0
+===== ============= ==============
Configuration
--
2.47.1
^ permalink raw reply related
* [PATCH v2 1/2] net/idpf/base: add MMG device IDs
From: Soumyadeep Hore @ 2026-05-20 22:03 UTC (permalink / raw)
To: bruce.richardson, manoj.kumar.subbarao, aman.deep.singh, dev
Cc: Christopher Pau
In-Reply-To: <20260520220306.85273-1-soumyadeep.hore@intel.com>
From: Christopher Pau <christopher.pau@intel.com>
Add MMG device ids for PF and VF.
Signed-off-by: Christopher Pau <christopher.pau@intel.com>
Signed-off-by: Soumyadeep Hore <soumyadeep.hore@intel.com>
---
drivers/net/intel/idpf/base/idpf_devids.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/intel/idpf/base/idpf_devids.h b/drivers/net/intel/idpf/base/idpf_devids.h
index 1ae99fcee1..8b10ef9e32 100644
--- a/drivers/net/intel/idpf/base/idpf_devids.h
+++ b/drivers/net/intel/idpf/base/idpf_devids.h
@@ -10,7 +10,10 @@
/* Device IDs */
#define IDPF_DEV_ID_PF 0x1452
+#define IDPF_DEV_ID_PF1 0x11DF
+#define IDPF_DEV_ID_CPF1 0x11E0
#define IDPF_DEV_ID_VF 0x145C
+#define IDPF_DEV_ID_VF1 0x0DE2
#define IDPF_DEV_ID_VF_SIOV 0x0DD5
--
2.47.1
^ permalink raw reply related
* [PATCH v2 0/2] Update IDPF Base Code
From: Soumyadeep Hore @ 2026-05-20 22:03 UTC (permalink / raw)
To: bruce.richardson, manoj.kumar.subbarao, aman.deep.singh, dev
In-Reply-To: <20260509015408.29188-3-soumyadeep.hore@intel.com>
Update idpf base code with compatible configuration on MEV.
---
v2:
- lists only LTS releases
- lists releases in descending order, so that latest is on top
- reworks table to use the new RST table format
---
Christopher Pau (1):
net/idpf/base: add MMG device IDs
Soumyadeep Hore (1):
doc: update recommended matching versions for cpfl and idpf
doc/guides/nics/cpfl.rst | 21 ++++++++-------------
doc/guides/nics/idpf.rst | 19 ++++++++-----------
drivers/net/intel/idpf/base/idpf_devids.h | 3 +++
3 files changed, 19 insertions(+), 24 deletions(-)
--
2.47.1
^ permalink raw reply
* Re: [PATCH v3] ring: fix zero-copy burst API documentation
From: Thomas Monjalon @ 2026-05-20 8:59 UTC (permalink / raw)
To: jinzhiguang
Cc: Konstantin Ananyev, Wathsala Vithanage, Dharmik Thakkar,
Honnappa Nagarahalli, dev, stable
In-Reply-To: <20260519133853.889-1-jinzhiguang@kylinos.cn>
19/05/2026 15:38, jinzhiguang:
> --- a/.mailmap
> +++ b/.mailmap
> @@ -756,6 +756,7 @@ Jing Chen <jing.d.chen@intel.com>
> Jingguo Fu <jingguox.fu@intel.com>
> Jingjing Wu <jingjing.wu@intel.com>
> Jingzhao Ni <jingzhao.ni@arm.com>
> +jinzhiguang <jinzhiguang@kylinos.cn>
Maybe you want to insert a space? What is your first name and family name?
Please use capital letters where appropriate.
^ permalink raw reply
* Re: [PATCH 0/2] enhance telemetry list endpoint with device name
From: Bruce Richardson @ 2026-05-20 7:49 UTC (permalink / raw)
To: fengchengwen; +Cc: Morten Brørup, thomas, stephen, dev
In-Reply-To: <689a32bf-b6e2-4646-8073-cd1f895b692b@huawei.com>
On Wed, May 20, 2026 at 03:31:57PM +0800, fengchengwen wrote:
> On 5/20/2026 1:40 PM, Morten Brørup wrote:
> >> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> >> Sent: Wednesday, 20 May 2026 05.57
> >>
> >> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
> >> only integer IDs, making it hard to identify devices. This series
> >> changes
> >> both to output strings in "ID NAME" format for better usability.
> >
> > For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.
>
> The TEL_DICT could do {"ID", "NAME"}, which like:
> "/ethdev/list": {
> "0": "0000:7d:00.0",
> "1": "0000:7d:00.1"
> }
>
> Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
> "/ethdev/list": {
> 0: "0000:7d:00.0",
> 1: "0000:7d:00.1"
> }
>
> I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.
>
> What's your opinion?
>
I'm not sure about this change at all. This change is only relevant for
those using the script interactively, for any other use, I would expect the
the /ethdev/list call would be followed by the /ethdev/info calls for each
port to get the name. That was the basic design in mind for this, the list
call was purely to provide the ids, any other info you make separate calls
for.
Also, while not officially part of the ABI of DPDK, I think it would be
wrong to go changing the types of the returned data from this /ethdev/list
call. Any user-written interfaces to telemetry will be relying on the
current behaviour to list and query ports. If you really want to have an
easy way to get the names of the ports, I suggest adding instead an
"/ethdev/list_names" API, which can either return the objects above, or
else simply an array of names.
/Bruce
^ permalink raw reply
* Re: [RFC PATCH 0/8] remove use of rte_memcpy from net/intel
From: Bruce Richardson @ 2026-05-20 7:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
In-Reply-To: <20260519124332.5e68fd8f@phoenix.local>
On Tue, May 19, 2026 at 12:43:32PM -0700, Stephen Hemminger wrote:
> On Tue, 19 May 2026 16:05:57 +0000
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> > This RFC proposed to replace all instances of rte_memcpy in Intel
> > (and former-Intel) net drivers with just regular memcpy. This is
> > done on the basis that the memcpy use is not datapath, but is used
> > for flow configuration, virt-channel (to firmware or PF) messaging
> > and other control path functions.
>
> Makes sense. You might also want to look for where structure
> assignment can be used instead of memcpy. Keeping data types
> is a good thing.
Yes, it would be nice to use in places. However, it's not a mechanical
change so I've not taken the time to do the analysis. Just a quick set of
sed replacements for this RFC.
/Bruce
^ permalink raw reply
* Re: [PATCH 0/2] enhance telemetry list endpoint with device name
From: fengchengwen @ 2026-05-20 7:31 UTC (permalink / raw)
To: Morten Brørup, thomas, stephen; +Cc: dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65885@smartserver.smartshare.dk>
On 5/20/2026 1:40 PM, Morten Brørup wrote:
>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
>> Sent: Wednesday, 20 May 2026 05.57
>>
>> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
>> only integer IDs, making it hard to identify devices. This series
>> changes
>> both to output strings in "ID NAME" format for better usability.
>
> For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.
The TEL_DICT could do {"ID", "NAME"}, which like:
"/ethdev/list": {
"0": "0000:7d:00.0",
"1": "0000:7d:00.1"
}
Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
"/ethdev/list": {
0: "0000:7d:00.0",
1: "0000:7d:00.1"
}
I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.
What's your opinion?
>
>
^ permalink raw reply
* [V1 1/1] net/hinic3: Add VXLAN TSO function
From: Feifei Wang @ 2026-05-20 6:58 UTC (permalink / raw)
To: dev; +Cc: Feifei Wang
In-Reply-To: <20260520065817.931-1-wff_light@vip.163.com>
The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN TSO function
Signed-off-by: Feifei Wang <wangfeifei40@huawei.com>
---
drivers/net/hinic3/hinic3_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hinic3/hinic3_ethdev.c b/drivers/net/hinic3/hinic3_ethdev.c
index f4eb788..fbadb1e 100644
--- a/drivers/net/hinic3/hinic3_ethdev.c
+++ b/drivers/net/hinic3/hinic3_ethdev.c
@@ -696,7 +696,7 @@ hinic3_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
RTE_ETH_TX_OFFLOAD_VLAN_INSERT | RTE_ETH_TX_OFFLOAD_IPV4_CKSUM |
RTE_ETH_TX_OFFLOAD_UDP_CKSUM | RTE_ETH_TX_OFFLOAD_TCP_CKSUM |
RTE_ETH_TX_OFFLOAD_SCTP_CKSUM |
- RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM |
+ RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM | RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO |
RTE_ETH_TX_OFFLOAD_TCP_TSO | RTE_ETH_TX_OFFLOAD_MULTI_SEGS;
if (nic_dev->feature_cap & NIC_F_HTN_CMDQ)
hinic3_dev_tnl_tso_support(info, nic_dev);
--
2.47.0.windows.2
^ permalink raw reply related
* [V1 0/1] Add VXLAN TSO function
From: Feifei Wang @ 2026-05-20 6:58 UTC (permalink / raw)
To: dev
V0: The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN TSO function
V1: Add sign-off in the commit message
Feifei Wang (1):
net/hinic3: Add VXLAN TSO function
drivers/net/hinic3/hinic3_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.47.0.windows.2
^ permalink raw reply
* [V0 0/1] Add VXLAN TSO function
From: Feifei Wang @ 2026-05-20 6:41 UTC (permalink / raw)
To: dev
V0:The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN TSO function
Feifei Wang (1):
Add VXLAN TSO function
drivers/net/hinic3/hinic3_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.47.0.windows.2
^ permalink raw reply
* [V0 1/1] Add VXLAN TSO function
From: Feifei Wang @ 2026-05-20 6:41 UTC (permalink / raw)
To: dev; +Cc: Feifei Wang
In-Reply-To: <20260520064112.705-1-wff_light@vip.163.com>
The RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO flag is added to support the VXLAN TSO function
---
drivers/net/hinic3/hinic3_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hinic3/hinic3_ethdev.c b/drivers/net/hinic3/hinic3_ethdev.c
index f4eb788..fbadb1e 100644
--- a/drivers/net/hinic3/hinic3_ethdev.c
+++ b/drivers/net/hinic3/hinic3_ethdev.c
@@ -696,7 +696,7 @@ hinic3_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
RTE_ETH_TX_OFFLOAD_VLAN_INSERT | RTE_ETH_TX_OFFLOAD_IPV4_CKSUM |
RTE_ETH_TX_OFFLOAD_UDP_CKSUM | RTE_ETH_TX_OFFLOAD_TCP_CKSUM |
RTE_ETH_TX_OFFLOAD_SCTP_CKSUM |
- RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM |
+ RTE_ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM | RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO |
RTE_ETH_TX_OFFLOAD_TCP_TSO | RTE_ETH_TX_OFFLOAD_MULTI_SEGS;
if (nic_dev->feature_cap & NIC_F_HTN_CMDQ)
hinic3_dev_tnl_tso_support(info, nic_dev);
--
2.47.0.windows.2
^ permalink raw reply related
* RE: [EXTERNAL] Re: [PATCH v2 1/1] net/mana: add device reset support
From: Wei Hu @ 2026-05-20 6:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Long Li, dpdk, Wei Hu
In-Reply-To: <SA1PR21MB66836A17CA584763D4D3F8A6CE002@SA1PR21MB6683.namprd21.prod.outlook.com>
Hi Stephen,
Many thanks for the review. I will send out a v3 to address most of them.
In the meantime, I would like to discuss further about two points from the
review comments. Please see my input below.
> -----Original Message-----
> 3. Spinlock held across blocking operations.
>
> priv->reset_ops_lock is rte_spinlock_t and is held across:
>
> - mana_reset_enter: mana_dev_stop, mana_dev_close,
> ibv_close_device,
> mana_mp_req_on_rxtx (5s IPC timeout)
> - mana_reset_exit_delay: ibv_close_device, mana_pci_probe,
> mana_mp_req_on_rxtx, mana_dev_start
>
> IPC with a 5-second timeout and device probe under a spinlock is
> not acceptable. Use a sleeping mutex (pthread_mutex_t initialized
> with PTHREAD_PROCESS_SHARED, since priv is in shared memory), or
> split the lock so the long operations run outside it.
>
The concern about holding rte_spinlock_t across blocking operations
is well noted. However, in the current design this works correctly, for
the following reasons:
1. mana_reset_enter runs on the EAL interrupt thread in response
to IBV_EVENT_DEVICE_FATAL. The device is already in a fatal
error state - the blocking IB verbs calls (ibv_close_device,
ibv_dealloc_pd) and IPC (mana_mp_req_on_rxtx) are unavoidable
teardown steps that must complete before recovery can begin.
2. The ethdev operations (configure, queue_setup, rss_hash_update,
etc.) all use rte_spinlock_trylock and return -EBUSY immediately
if the lock is held. They never spin-wait on the lock during
reset, so there is no starvation or latency impact on the
application threads.
3. dev_stop_lock and dev_close_lock use blocking rte_spinlock_lock,
but they first join the reset thread (which releases the lock
when done), so by the time they attempt to acquire the lock,
the reset path has already released it. IMHO, the actual spin-wait
is negligible.
4. The mana_reset_exit_delay path (re-probe, re-start) also holds
the lock, but this runs on a dedicated control thread where
blocking is acceptable. No data path or application thread is
affected.
The net effect is that the spinlock is held for an extended period
only on the interrupt thread and the reset control thread - neither
of which are latency sensitive. Application threads never block on
the spinlock.
That said, switching to pthread_mutex_t with PTHREAD_PROCESS_SHARED
is a valid improvement that would make the locking more conventional
and avoid any theoretical busy-wait concerns. I can make this change if
it is still desirable. I would like to know your thoughts on this.
> Warnings
> --------
>
> 5. Secondary data path has no synchronization with the doorbell unmap.
>
> MANA_MP_REQ_RESET_ENTER causes the secondary MP handler to
> munmap
> proc_priv->db_page and set it to NULL. The secondary's rx_burst /
> tx_burst protect themselves only with an atomic state check:
>
> rte_rcu_qsbr_thread_online(dstate_qsv, tid);
> if (state != MANA_DEV_ACTIVE || !db_page) { ... return 0; }
>
> But the qsbr only has primary threads registered (registration
> happens in mana_dev_configure, which never runs in secondary), so
> thread_online/offline in secondary do not block the primary's
> qsbr_check. The MP handler in secondary therefore unmaps db_page
> while a peer secondary lcore can still be inside rx/tx_burst with
> a stale pointer. Result: SIGSEGV on the next doorbell write.
>
> The secondary needs its own quiescence mechanism (a per-process
> qsbr or a reader-side rwlock around the data path that the MP
> handler acquires before unmap).
>
The concern is based on the assumption that "the qsbr only has
primary threads registered (registration happens in
mana_dev_configure, which never runs in secondary)". This seems
incorrect.
My understanding is when the primary starts, the total number of queues
for primary and all secondaries is already known, which is stored in
priv->num_queues by the time mana_dev_congiure() is called.
The RCU thread IDs are per-queue, not per-process. In mana_dev_configure,
I am assigning tids used in rte_rcu_qsbr_thread_online/offline as:
- RX path: tid = rxq->rxq_idx (0 to num_queues-1)
- TX path: tid = num_queues + txq_idx (num_queues to 2*num_queues-1)
These queue structures (rxq, txq) live in shared hugepage memory
via dev->data->rx_queues[] and dev->data->tx_queues[]. The QSV
itself (priv->dev_state_qsv) is also in shared hugepage memory
(allocated with rte_zmalloc_socket). So both primary and secondary
processes operate on the same QSV with the same thread IDs.
The rte_rcu_qsbr_thread_register call in mana_dev_configure
registers IDs 0..2*num_queues-1, which covers every queue
regardless of which process polls it. I think in DPDK
a given queue is polled by only one lcore at a time, so whether
that lcore is in the primary or a secondary process, it uses the
same tid for the same queue.
The reset synchronization flow is:
1. mana_reset_enter sets dev_state = MANA_DEV_RESET_ENTER
2. Calls rte_rcu_qsbr_check to wait for all registered threads
3. Secondary lcores polling rx/tx_burst see dev_state != ACTIVE,
call rte_rcu_qsbr_thread_offline, and return 0
4. Only after ALL threads (primary and secondary) are quiescent
does rte_rcu_qsbr_check return success
5. Then mana_reset_enter proceeds to stop queues and send
MANA_MP_REQ_RESET_ENTER to unmap secondary doorbells
At step 5, no secondary lcore can be inside the data path with
a stale doorbell pointer - the RCU quiescence check at step 2-4
guarantees this. The secondary MP handler unmaps db_page only
after all secondary data path threads have exited.
So, in my opinion, this works correctly for secondaries as well.
Thanks,
Wei
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox