Hi Morten,

From: Vladimir Medvedkin [mailto:medvedkinv@gmail.com]
Sent: Monday, 7 July 2025 22.10

 

 

That's not quite correct.

There are 2 valid usecases, that may bring some ambiguity:

    1. Some vendors may support mixing dual/single tagged packets on a physical port, (for example refer to the JunOS flexible-vlan-tagging)

    2. Service provider(SP) provides L2 connectivity to a customer, and customer is able to send non tagged frames via SP infrastructure.

 

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) whether the packet is non tagged encapsulated into SP's QinQ, or a regular VLAN packet belonging to the internal SP infrastructure?

In each case, NIC has to place the VLAN tag in different places of the descriptor/mbuf.

 

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).

 

I’m not sure I understand your example.

Are you talking about packets ingressing on a backbone port (i.e. not a customer-facing port) on a DPDK-based SP exit node?

And the backbone is using one individual VLAN ID per customer?

So customers’ untagged traffic is VLAN tagged packets in the backbone, and customers VLAN tagged traffic is double tagged packets in the backbone?

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.

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?

Oh no. I'm just pointing out the fundamental problem, which is the inability to recognize from a single tagged packet whether it is an untagged customer packet inside the QinQ S-VLAN or just a regular VLAN, due to the lack of the above mentioned information inside a NIC parsing pipeline.

So, given that, I'm pretty much aligned with Bruce in his suggestion in a following mail. We can also add a note into documentation reflecting single tagged stripping behaviour for a QinQ usecase, so developers should keep in mind when they rely on vlan/QinQ stripping in their QinQ-capable dataplane. Or, as an extra, we can introduce devarg controlling where to put that tag.

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.

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.

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.

 

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.

--

Regards,

Vladimir

-- 
Regards,
Vladimir