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).
> 
> And there is symmetry for TX, except the two conceptual pipeline stages are swapped.
> 

Thank you, that is clear now.

/Bruce