On Wed, Jul 30, 2025 at 10:10:42PM +0200, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@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
