Re: [RFC PATCH] doc: clarify VLAN and QinQ stripping behaviour

[Patrick Robb <probb@iol.unh.edu>]

[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]

On Mon, Jul 14, 2025 at 4:09 PM Dean Marx <dmarx@iol.unh.edu> 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 for checking the test results on the Intel NICs. That's interesting
that the behavior (only outer tag stripped) differs from the description in
the patch. But, I guess this question will become irrelevant if QinQ strip
without VLAN strip will become disallowed at the ethdev layer. So problem
solved there I guess!

Otherwise, it sounds like there are basically 3 valid "strip" configs a
port can be set to.

1. No strip
2. VLAN Strip
3. VLAN Strip + QinQ strip

And then, as Morten points out, there are various packet profiles which we
can send through these 3 configurations for your testcases.

Single VLAN: Ether() / Dot1Q(vlan=100, type=0x8100) / IP(dst="1.2.3.4") /
UDP(dport=1234, sport=4321)
Double VLAN: Ether() / Dot1Q(vlan=100, type=0x8100) / Dot1Q(vlan=200,
type=0x8100) / IP(dst="1.2.3.4") / UDP(dport=1234, sport=4321)
Single 0x88a8 tag only: Ether() / Dot1Q(vlan=100,
type=0x88a8 / IP(dst="1.2.3.4") / UDP(dport=1234, sport=4321)
Single VLAN + 1 0x88a8 tag: Ether() / Dot1Q(vlan=100, type=0x88a8)
/ Dot1Q(vlan=100, type=0x8100) / IP(dst="1.2.3.4") / UDP(dport=1234,
sport=4321)

Dean I gotta run for now but tomorrow let's see if we can define the
expected behavior for the intersection of these various stripping option
and packet profiles and pseudo code out some testcases based on that.

[-- Attachment #2: Type: text/html, Size: 3880 bytes --]