* Re: [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags
From: David Marchand @ 2026-05-20 12:42 UTC (permalink / raw)
To: Robin Jarry; +Cc: dev, Kevin Traynor
In-Reply-To: <DINGHEW3M9WT.3F4XUUTLNKEL3@redhat.com>
On Wed, 20 May 2026 at 13:09, Robin Jarry <rjarry@redhat.com> wrote:
> >> - } 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.
There is this point and the code has been behaving like this for
years, so some applications may have been relying on this behavior.
I don't mind leaving as is.
--
David Marchand
^ permalink raw reply
* Re: [PATCH 0/6] net/idpf: fix split queue AVX2 datapath
From: Bruce Richardson @ 2026-05-20 12:36 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-1-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:29PM +0530, Shaiq Wani wrote:
> Fix the split queue AVX2 vectorized path to correctly handle the
> virtchnl2_rx_flex_desc_adv_nic_3 completion descriptor format and
> the flex scheduled Tx descriptor encoding.
>
> The split queue completion descriptor layout is significantly
> different from the single queue path — the generation bit, DD bit,
> and packet length occupy different positions than the base Rx
> descriptor, and the buffer queue owns the mbuf pool rather than the
> completion queue.
>
> On Rx, four issues are fixed:
> - Generation bit extraction order (mask-before-shift)
> - DD bit byte offset (byte 8 not byte 1)
> - mbuf initializer sourced from bufq2 instead of the completion queue
> - Packet type inserted into the correct AVX2 lane
>
> On Tx, two issues are fixed:
> - Buffer size shift corrected from 34 to 48 for flex descriptors
> - Burst clamped to tx_rs_thresh with proper tx_next_rs tracking
>
> Shaiq Wani (6):
> net/idpf: fix gen bit extraction in split queue AVX2 Rx
> net/idpf: fix DD bit byte offset in split queue AVX2 Rx
> net/idpf: fix mbuf initializer source in split queue AVX2 Rx
> net/idpf: fix ptype insert position in split queue AVX2 Rx
> net/idpf: fix split queue AVX2 Tx buffer size shift
> net/idpf: fix split queue AVX2 Tx burst and completion
>
Series applied to dpdk-next-net-intel
Thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH 6/6] net/idpf: fix split queue AVX2 Tx burst and completion
From: Bruce Richardson @ 2026-05-20 12:25 UTC (permalink / raw)
To: Shaiq Wani; +Cc: dev, aman.deep.singh
In-Reply-To: <20260511090935.2288837-7-shaiq.wani@intel.com>
On Mon, May 11, 2026 at 02:39:35PM +0530, Shaiq Wani wrote:
> Clamp burst size to tx_rs_thresh to prevent crossing completion
> boundaries. Update tx_next_rs on ring wrap and after each burst
> so that completion tracking in idpf_splitq_scan_cq_ring works
> correctly. Fix sw_ring pointer to use base-plus-offset.
>
> 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>
> ---
> .../net/intel/idpf/idpf_common_rxtx_avx2.c | 24 ++++++++++++++-----
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> index 7c547b5f09..b6c4fdf20e 100644
> --- a/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> +++ b/drivers/net/intel/idpf/idpf_common_rxtx_avx2.c
> @@ -884,17 +884,21 @@ idpf_splitq_xmit_fixed_burst_vec_avx2(void *tx_queue, struct rte_mbuf **tx_pkts,
> struct ci_tx_queue *txq = (struct ci_tx_queue *)tx_queue;
> struct idpf_flex_tx_sched_desc *txdp;
> struct ci_tx_entry_vec *txep;
> - uint16_t n, nb_commit;
> + uint16_t n, nb_commit, tx_id;
> uint64_t cmd_dtype = IDPF_TXD_FLEX_FLOW_CMD_EOP;
> - uint16_t tx_id = txq->tx_tail;
>
> - nb_commit = (uint16_t)RTE_MIN(txq->nb_tx_free, nb_pkts);
> - nb_pkts = nb_commit;
> + /* cross rs_thresh boundary is not allowed */
> + nb_pkts = RTE_MIN(nb_pkts, txq->tx_rs_thresh);
> +
> + nb_pkts = (uint16_t)RTE_MIN(txq->nb_tx_free, nb_pkts);
> + nb_commit = nb_pkts;
> if (unlikely(nb_pkts == 0))
> return 0;
>
> - txdp = (struct idpf_flex_tx_sched_desc *)&txq->desc_ring[tx_id];
> - txep = &txq->sw_ring_vec[tx_id];
> + tx_id = txq->tx_tail;
> + txdp = &txq->desc_ring[tx_id];
> + txep = (void *)txq->sw_ring;
> + txep += tx_id;
>
> txq->nb_tx_free = (uint16_t)(txq->nb_tx_free - nb_pkts);
>
> @@ -909,10 +913,14 @@ idpf_splitq_xmit_fixed_burst_vec_avx2(void *tx_queue, struct rte_mbuf **tx_pkts,
> idpf_splitq_vtx1_avx2(txdp, *tx_pkts++, cmd_dtype);
>
> nb_commit = (uint16_t)(nb_commit - n);
> +
> tx_id = 0;
> + txq->tx_next_rs = (uint16_t)(txq->tx_rs_thresh - 1);
>
> + /* avoid reach the end of ring */
> txdp = &txq->desc_ring[tx_id];
> txep = (void *)txq->sw_ring;
> + txep += tx_id;
> }
>
> ci_tx_backlog_entry_vec(txep, tx_pkts, nb_commit);
> @@ -920,6 +928,10 @@ idpf_splitq_xmit_fixed_burst_vec_avx2(void *tx_queue, struct rte_mbuf **tx_pkts,
> idpf_splitq_vtx_avx2(txdp, tx_pkts, nb_commit, cmd_dtype);
>
> tx_id = (uint16_t)(tx_id + nb_commit);
> + if (tx_id > txq->tx_next_rs)
> + txq->tx_next_rs =
> + (uint16_t)(txq->tx_next_rs + txq->tx_rs_thresh);
> +
> txq->tx_tail = tx_id;
>
> IDPF_PCI_REG_WRITE(txq->qtx_tail, txq->tx_tail);
> --
> 2.34.1
>
^ permalink raw reply
* 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
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