<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Morten, all,</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 7 июл. 2025 г. в 19:09, Morten Brørup <<a href="mailto:mb@smartsharesystems.com" target="_blank">mb@smartsharesystems.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> From: Bruce Richardson [mailto:<a href="mailto:bruce.richardson@intel.com" target="_blank">bruce.richardson@intel.com</a>]<br> > Sent: Friday, 4 July 2025 13.32<br> <br> > Hi all,<br> > <br> > this email discussion comes at a bit of a fortunate time for me, as I'm<br> > currently looking at our vlan tag/qinq stripping behaviour in our Intel<br> > NIC<br> > drivers, and there is some discussion internally as to what our driver<br> > behaviour should be compared to what it has historically been. :-)<br> > <br> > The documentation - both in the NIC guide [1] and the testpmd guide [2]<br> > -<br> > is rather short on detail as to what exactly the behaviour should be<br> > when<br> > vlan strip or qinq strip is implemented. Therefore, I'd hope that those<br> > more familiar with networking than me would be able to help clarify<br> > things<br> > so we can document the correct behaviour precisely - and hopefully test<br> > our<br> > drivers against it in future!<br> > <br> > The simple cases are obvious (looking only at stripping behaviour here):<br> > * no vlan stripping - nothing done to packet<br> > * no vlan tag in pkg - nothing to do, irrespective of offload<br> > * Vlan strip enabled and single vlan tag present - HW should strip the<br> > tag and<br> > place it in descriptor for placing in mbuf.<br> > <br> > Now the questions I have:<br> > * To handle questions with 2 vlan tags, the QinQ case - do we need to<br> > enable both vlan-strip and QinQ strip, or does QinQ strip imply<br> > stripping<br> > both?<br> > - one suggested interpretation here, was that QinQ implies stripping<br> > the<br> > tag with id EtherType 0x88a8, and vlan stripping implies taking off<br> > the<br> > tag with 0x8100<br> > - another interpretation is vlan strip means just to take off one tag<br> > (if<br> > present), and qinq strip means to take off both tags (if present).<br> > <br> <br> First off, consider VLAN stripping...<br> It strips the VLAN tag if present, but also allows (and parses) untagged packets.<br> A link with a mix of tagged and untagged packets is called a "hybrid link", so this scenario is perfectly valid and common.<br> Referring to this behavior, I would expect something similar for QinQ stripping, i.e. with QinQ stripping enabled, two, one or zero tags are allowed (and parsed).<br> This makes the VLAN strip flag superfluous when the QinQ strip flag is set.<br> <br> You could have a QinQ trunk carrying only QinQ tagged packets and untagged Layer 2 Control Protocol packets (LACP etc.).<br> In this case you might want the ability to drop VLAN tagged packets, which should not occur on the link.<br></blockquote><div><br></div><div>That's not quite correct.</div><div>There are 2 valid usecases, that may bring some ambiguity:</div><div> 1. Some vendors may support mixing dual/single tagged packets on a physical port, (for example refer to the JunOS flexible-vlan-tagging)</div><div> 2. Service provider(SP) provides L2 connectivity to a customer, and customer is able to send non tagged frames via SP infrastructure.</div><div><br></div><div>Thus, upon receive single tagged packet at the SP exit node (the switch customer is connected to) how does it distinguish (w/o reading local configuration, i.e. VLAN A - QinQ outer tag, vlans B and C - regular VLANs) <span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">whether</span> the packet is non tagged encapsulated into SP's QinQ, or a regular VLAN packet belonging to the internal SP infrastructure?</div><div><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">In</span><span style="white-space:pre-wrap"> </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">each</span><span style="white-space:pre-wrap"> </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">case</span><span style="white-space:pre-wrap">, NIC has</span><span style="white-space:pre-wrap"> to </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">place</span><span style="white-space:pre-wrap"> the </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">VLAN</span><span style="white-space:pre-wrap"> </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">tag</span><span style="white-space:pre-wrap"> </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">in</span><span style="white-space:pre-wrap"> </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">different</span><span style="white-space:pre-wrap"> </span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">places</span><span style="white-space:pre-wrap"> of the </span><span style="white-space:pre-wrap"></span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">descriptor</span><span style="white-space:pre-wrap"></span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">/</span><span class="gmail-aNeGP0gI0B9AV8JaHPyH" style="white-space:pre-wrap">mbuf</span><span style="white-space:pre-wrap">.</span></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> However, since we don't have such a feature for VLAN trunks, I wouldn't expect it for QinQ trunks either.<br> <br> Another important detail...<br> Formally, QinQ is EtherType 0x88a8 with two VLAN tags.<br> However, I think double-tagging with EtherType 0x8100 is still broadly in use (in old networks, where it is difficult to upgrade to the official QinQ EtherType), so I would also treat packets with two VLAN tags (of EtherType 0x8100) as QinQ.<br> There was also an intermediate unofficial EtherType 0x9100 for QinQ tagging, before EtherType 0x88a8 was standardized... but I think we can ignore that.<br> <br> > The question above leads to other consequences:<br> > * if we enable qinq strip, but get a single-vlan tagged frame, what is<br> > the<br> > behaviour?<br> > * if we get a qinq packet, but regular vlan strip is enabled, which tag,<br> > if<br> > any, is stripped?<br> > * should it be an error to enable both qinq strip and vlan strip at the<br> > same time? Should it be an error to enable qinq strip without vlan<br> > strip?<br> > * in the mbuf, we have a "vlan_tci" field, and an "vlan_tci_outer"<br> > field.<br> > For single vlan strip, presumably only the vlan_tci field should be<br> > used,<br> > and for qinq traffic stripped, it's obvious which field goes where.<br> > However, what if we have QinQ strip and we only receive a single vlan<br> > tag, where should that be put? Should it go in inner or outer?<br> <br> >From a protocol parsing perspective, a single VLAN tagged packet has no "outer" tag.<br> <br> Also: Consider the link being configured as a "super-hybrid link" (probably not an official name for such a link, but expanding on the common term "hybrid link"), carrying a mix of untagged, VLAN tagged and QinQ tagged packets. In this case, a single VLAN tagged packet is just a normal VLAN tagged packet, with the VLAN ID obviously going to the ordinary vlan_tci field.<br> <br> > <br> > Feedback welcome, and suggested doc updates welcome too.<br> > <br> > Thanks,<br> > /Bruce<br> > <br> > <br> > [1] <a href="https://doc.dpdk.org/guides/nics/features.html#vlan-offload" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/nics/features.html#vlan-offload</a><br> > [2] <a href="https://doc.dpdk.org/guides/testpmd_app_ug/run_app.html" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/testpmd_app_ug/run_app.html</a><br> </blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div>Vladimir<br></div></div></div> </div>