<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Vladimir Medvedkin [mailto:medvedkinv@gmail.com] <br><b>Sent:</b> Monday, 7 July 2025 22.10<br><br><o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><div><p class=MsoNormal>Hi Morten, all,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>пн, 7 июл. 2025 г. в 19:09, Morten Brørup <<a href="mailto:mb@smartsharesystems.com" target="_blank">mb@smartsharesystems.com</a>>:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>> 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.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>That's not quite correct.<o:p></o:p></p></div><div><p class=MsoNormal>There are 2 valid usecases, that may bring some ambiguity:<o:p></o:p></p></div><div><p class=MsoNormal> 1. Some vendors may support mixing dual/single tagged packets on a physical port, (for example refer to the JunOS flexible-vlan-tagging)<o:p></o:p></p></div><div><p class=MsoNormal> 2. Service provider(SP) provides L2 connectivity to a customer, and customer is able to send non tagged frames via SP infrastructure.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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>whether</span> the packet is non tagged encapsulated into SP's QinQ, or a regular VLAN packet belonging to the internal SP infrastructure?<o:p></o:p></p></div><div><p class=MsoNormal><span class=gmail-anegp0gi0b9av8jahpyh>In</span> <span class=gmail-anegp0gi0b9av8jahpyh>each</span> <span class=gmail-anegp0gi0b9av8jahpyh>case</span>, NIC has to <span class=gmail-anegp0gi0b9av8jahpyh>place</span> the <span class=gmail-anegp0gi0b9av8jahpyh>VLAN</span> <span class=gmail-anegp0gi0b9av8jahpyh>tag</span> <span class=gmail-anegp0gi0b9av8jahpyh>in</span> <span class=gmail-anegp0gi0b9av8jahpyh>different</span> <span class=gmail-anegp0gi0b9av8jahpyh>places</span> of the <span class=gmail-anegp0gi0b9av8jahpyh>descriptor/mbuf</span>.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I was trying to make the point that QinQ stripping only needs to support 2, 1, or 0 tags, it doesn’t need an option to support only 2 or 0 tags (and disallow 1 tag).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m not sure I understand your example.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Are you talking about packets ingressing on a backbone port (i.e. not a customer-facing port) on a DPDK-based SP exit node?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>And the backbone is using one individual VLAN ID per customer?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So customers’ untagged traffic is VLAN tagged packets in the backbone, and customers VLAN tagged traffic is double tagged packets in the backbone?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In such a case, the VLAN ID used internally for infrastructure/management purposes by the SP will be reserved, and not assigned to any customer.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>And you suggest putting the VLAN ID of the single tagged packets in the vlan_tci_outer and set RTE_MBUF_F_RX_QINQ but not RTE_MBUF_F_RX_VLAN, instead of treating them as normal VLAN tagged packets?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>OK, then the “superfluous” VLAN stripping flag could be used for indicating which mbuf field vlan_tci/vlan_tci_outer the VLAN ID of single VLAN tagged packets should go into, when QinQ stripping is enabled.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But: If QinQ/VLAN stripping is not enabled, the VLAN ID of such a single VLAN tagged packet will still go into the mbuf->vlan_tci field with RTE_MBUF_F_RX_VLAN (but not RTE_MBUF_F_RX_VLAN_STRIPPED) set.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So I don’t think such flexibility about where to put the VLAN ID of single VLAN tagged packets is a good idea, if such optional behavior is only available when stripping the VLAN/QinQ tags, but not when simply parsing the VLAN/QinQ tagged packets.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you are talking about a backbone using QinQ with individual {outer, inner} ID pair per customer, VLAN tagged customer traffic will be triple tagged packets in such a backbone.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>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" 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" target="_blank">https://doc.dpdk.org/guides/testpmd_app_ug/run_app.html</a><o:p></o:p></p></blockquote></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p></div><p class=MsoNormal><br><span class=gmailsignatureprefix>-- </span><o:p></o:p></p><div><div><div><p class=MsoNormal>Regards,<o:p></o:p></p></div><p class=MsoNormal>Vladimir<o:p></o:p></p></div></div></div></div></div></div></body></html>