DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Robin Jarry" <rjarry@redhat.com>
To: "David Marchand" <david.marchand@redhat.com>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags
Date: Wed, 20 May 2026 13:09:43 +0200	[thread overview]
Message-ID: <DINGHEW3M9WT.3F4XUUTLNKEL3@redhat.com> (raw)
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.


  reply	other threads:[~2026-05-20 11:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22 10:28 [PATCH dpdk] net: fix L2 ptype assignment in VLAN loop Robin Jarry
2026-04-22 10:35 ` Robin Jarry
2026-04-22 10:38 ` [PATCH dpdk v2] " Robin Jarry
2026-04-22 13:16   ` Thomas Monjalon
2026-04-22 13:18     ` Robin Jarry
2026-04-22 13:23   ` David Marchand
2026-04-22 13:32 ` [PATCH dpdk v3] net: fix VLAN packet type Robin Jarry
2026-04-23  9:19   ` Kevin Traynor
2026-04-23  9:49     ` Robin Jarry
2026-04-23 10:59       ` Kevin Traynor
2026-04-23 11:11         ` Robin Jarry
2026-04-23 11:24 ` [PATCH dpdk v4] " Robin Jarry
2026-04-24 16:18   ` Kevin Traynor
2026-04-25  8:40   ` David Marchand
2026-04-27 10:47     ` Robin Jarry
2026-04-27 15:53       ` Thomas Monjalon
2026-04-30 10:12         ` David Marchand
2026-04-30 11:06           ` Morten Brørup
2026-05-15 11:17     ` Kevin Traynor
2026-05-18 13:27 ` [PATCH dpdk v5 0/5] Fix and improve VLAN/MPLS parsing in rte_net_get_ptype Robin Jarry
2026-05-18 13:27   ` [PATCH dpdk v5 1/5] Revert "net: fix packet type for stacked VLAN" Robin Jarry
2026-05-20  9:47     ` David Marchand
2026-05-20 10:24     ` Kevin Traynor
2026-05-18 13:27   ` [PATCH dpdk v5 2/5] net: support multiple stacked VLAN tags Robin Jarry
2026-05-20  9:56     ` David Marchand
2026-05-20 11:09       ` Robin Jarry [this message]
2026-05-20 12:42         ` David Marchand
2026-05-18 13:27   ` [PATCH dpdk v5 3/5] net: add unit tests for rte_net_get_ptype Robin Jarry
2026-05-18 13:27   ` [PATCH dpdk v5 4/5] net: parse L3 protocol after MPLS labels Robin Jarry
2026-05-18 18:00     ` Stephen Hemminger
2026-05-18 13:27   ` [PATCH dpdk v5 5/5] net: add truncated packet tests for rte_net_get_ptype Robin Jarry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DINGHEW3M9WT.3F4XUUTLNKEL3@redhat.com \
    --to=rjarry@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox