From: Bruce Richardson <bruce.richardson@intel.com>
To: Dean Marx <dmarx@iol.unh.edu>
Cc: <dev@dpdk.org>, <techboard@dpdk.org>
Subject: Re: [RFC PATCH] doc: clarify VLAN and QinQ stripping behaviour
Date: Tue, 15 Jul 2025 08:47:27 +0100 [thread overview]
Message-ID: <aHYHj9vtdXm8MgY_@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <CABD7UXPVg56UwvmtOsssBwV2HzmgV4ZJZCb=FrnVQKkggtD2+Q@mail.gmail.com>
On Mon, Jul 14, 2025 at 04:09:11PM -0400, Dean Marx wrote:
> On Mon, Jul 14, 2025 at 9:30 AM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > The behaviour of VLAN tag stripping Rx offloads is unclear in DPDK, and
> > not very well documented. Even the documentation that does exist appears
> > contradictory.
> >
> > For example, the doxygen docs for the mbuf flag
> > RTE_MBUF_F_RX_QINQ_STRIPPED says:
> >
> > "If RTE_MBUF_F_RX_QINQ_STRIPPED is set and RTE_MBUF_F_RX_VLAN_STRIPPED
> > is unset, only the outer VLAN is removed from packet data,..."
> >
> > but the docs for RTE_MBUF_F_RX_QINQ says:
> >
> > "If the flag RTE_MBUF_F_RX_QINQ_STRIPPED is also present, both VLANs
> > headers have been stripped from mbuf data, ..."
> >
> > Without a good definition of what the correct behaviour is, it's not
> > possible to assess and ensure conformance across drivers. Update the
> > documentation for NIC features, ethdev and mbuf library to all report
> > the same information: that VLAN strip feature is stripping one flag, and
> > QinQ strip feature is removing two.
>
> I'm working on testing QinQ/VLAN stripping features across PMDs, and
> so far I've found that our Intel devices are capable of QinQ
> stripping, while our Mellanox/Broadcom devices are not. When QinQ
> stripping is enabled on an Intel PMD, the test packet is received with
> its outer VLAN layer stripped, but the inner VLAN layer remains
> intact. Thus, the doxygen example is more accurate for what is
> currently supported. I'm also running some tests on VLAN stripping
> behavior, I'll update this thread with the results once these are
> finished.
Thanks. Let me know how the testing otherwise goes. If only Intel NICs are
supporting QinQ, then it can't be that widely used a feature yet, so we may
be able to tweak things a bit if it diverges from what is expected.
I also wonder if the definition of expected behaviour is preventing other
NICs from implementing the feature?
Can you also check with VLAN stripping enabled? My biggest issue with the
behaviour description of QinQ strip only removing outer tag is that it
implies for QinQ traffoc that VLAN strip alone should strip inner tag without
removing outer. That doesn't make sense to me - and I'm not sure if NIC
hardware supports such features of removing inner headers while leaving
outer.
/Bruce
next prev parent reply other threads:[~2025-07-15 7:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 13:30 Bruce Richardson
2025-07-14 15:06 ` Stephen Hemminger
2025-07-14 15:11 ` Bruce Richardson
2025-07-14 16:33 ` Morten Brørup
2025-07-14 16:49 ` Bruce Richardson
2025-07-15 15:04 ` Morten Brørup
2025-07-15 16:20 ` Bruce Richardson
2025-07-14 20:09 ` Dean Marx
2025-07-14 21:41 ` Patrick Robb
2025-07-15 7:47 ` Bruce Richardson [this message]
2025-07-15 21:15 ` Patrick Robb
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=aHYHj9vtdXm8MgY_@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=techboard@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;
as well as URLs for NNTP newsgroup(s).