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

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jul 30, 2025 at 10:10:42PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 30 July 2025 19.29
> > 
> > On Mon, Jul 28, 2025 at 07:48:53PM +0200, Morten Brørup wrote:

<snip>

> > > 2. For more tags, start by strictly conforming to the IEEE 802.3
> > standard.
> > > QinQ is EtherType 0x88a8 and is associated with the outer tag (S-TAG),
> > mbuf->vlan_tci_outer, regardless if an inner tag (C-TAG) is present or
> > not.
> > > VLAN is EtherType 0x8100 and is associated with the inner tag (C-TAG)
> > or simple tag (VLAN tag), mbuf->vlan_tci, regardless if an outer tag is
> > present or not. (Note: When disregarding the outer tag here, this is
> > exactly the same behavior as for VLAN in bullet 1 above.)
> > > This defines placements of the tag IDs in the mbuf and the default
> > EtherTypes used in the packet headers when parsing/stripping/inserting
> > tags.
> > > It also defines the purpose of VLAN and QINQ
> > capability/present/strip/insert flags in the ethdev and mbuf offload
> > flags.
> > >
> > 
> > So based on what you say above, having a VLAN strip setting separate
> > from
> > the QinQ strip enabled setting doesn't make any sense, right? So we
> > should
> > decide and document that when QinQ strip is enabled, VLAN strip must be:
> > 
> > a) always on - which makes sense if single tagged 0x8100 packets are
> > still
> >                stripped as you describe above
> > b) always off - which makes sense in the case below where singly tagged
> >                 packets are treated as outer tags
> > c) ignored - which is a bit of a cop-out, but avoids any issues with
> > backward
> >              compatibility for apps.
> 
> No. I'm saying something else:
> With QinQ stripping/insertion enabled, the VLAN stripping/insertion flag controls what to do with the inner VLAN tag (if present):
> Enabled: If inner VLAN tag is present (and outer QinQ tag was stripped), strip it.
> Disabled: If inner VLAN tag is present (and outer QinQ tag was stripped), don't strip it.
> 
> Think of a conceptual pipeline:
> First stage on RX (if QinQ stripping is enabled), the outermost QinQ tag is stripped, if present. After this, the packet has no outer tag anymore; the outermost tag has been removed, so what was the inner tag before has now become the outermost tag.
> Second stage on RX (if VLAN stripping is enabled), the outermost VLAN tag is stripped, if present. After this, the packet has no inner tag anymore.
> 
> When QinQ stripping is disabled, or HW doesn't support it, there is only the "Second stage".
> This is what I was trying to refer to in my bullet 2 "Note: When disregarding the outer tag here, this is exactly the same behavior as for VLAN in bullet 1 above."
> In other words: The VLAN stripping engine only considers the outermost tag (possibly after QinQ stripping has made the innermost tag become the outermost).
>

So the basic configuration testing table - if we ignore the API for adjusting
the tags recognised as inner/outer - would be the below.

NOTE:  I'm including tag 0x9100 for completeness as an unrecognised tag,
and also because if we do expand to testing the API for setting
inner/outer, we'll probably want to use it. Since this table can be used as
a testing input and we only need one packet for each type, I'm also
including all permutations, even though many should never occur in real
life.

Does this table match what you have explained above? Anything I need to
update on it? [It could probably serve as input to have an AI automatically
generate a full set of DTS VLAN tests, if we give it an example
implementation of one case.]

/Bruce

VLAN Stripping Behavior Table
=============================

Input Pkt Tags       | VLAN Strip        | QinQ Strip           | VLAN+QinQ Strip
---------------------|-------------------|----------------------|----------------------------------
0x8100               | Tag in vlan_tci   |          --          | Tag in vlan_tci
---------------------|-------------------|----------------------|----------------------------------
0x88a8               |        --         | Tag in vlan_tci_outer| Tag in vlan_tci_outer
---------------------|-------------------|----------------------|----------------------------------
0x9100               |        --         |          --          |                --
---------------------|-------------------|----------------------|----------------------------------
                     |                   |                      |
---------------------|-------------------|----------------------|----------------------------------
0x8100 0x8100        | Tag in vlan_tci   |          --          | Tag in vlan_tci
---------------------|-------------------|----------------------|----------------------------------
0x8100 0x88a8        | Tag in vlan_tci   |          --          | Tag in vlan_tci
---------------------|-------------------|----------------------|----------------------------------
0x8100 0x9100        | Tag in vlan_tci   |          --          | Tag in vlan_tci
---------------------|-------------------|----------------------|----------------------------------
0x88a8 0x8100        |        --         | Tag in vlan_tci_outer| Tag in vlan_tci_outer &
                     |                   |                      | tag in vlan_tci
---------------------|-------------------|----------------------|----------------------------------
0x88a8 0x88a8        |        --         | Tag in vlan_tci_outer| Tag in vlan_tci_outer
---------------------|-------------------|----------------------|----------------------------------
0x88a8 0x9100        |        --         | Tag in vlan_tci_outer| Tag in vlan_tci_outer
---------------------|-------------------|----------------------|----------------------------------
0x9100 [any]         |        --         |          --          |                --
---------------------|-------------------|----------------------|----------------------------------