Hi Morten,
On 7/7/2025 11:00 PM, Morten Brørup wrote:
*From:*Vladimir Medvedkin [mailto:medvedk...@gmail.com]
*Sent:* Monday, 7 July 2025 22.10
<snip>
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).
that's correct
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?
yes
And the backbone is using one individual VLAN ID per customer?
yes
So customers’ untagged traffic is VLAN tagged packets in the backbone,
and customers VLAN tagged traffic is double tagged packets in the
backbone?
yes
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.
Indeed, SP usually allocate VLAN tags in blocks and uses them for
different purposes. For example, vlans 100-200 for internal infra and
vlans 500-1000 for customers QinQ. This allocation scheme is individual
for every SP. And this piece of information helps to to distinguish QinQ
from a regular VLAN.
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 justpointingout thefundamentalproblem,which istheinabilityto
recognizefrom asingletaggedpacketwhetheritis an untagged customer
packetinsidethe QinQS-VLANorjusta regularVLAN,dueto thelackof the above
mentionedinformation 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.
No, I'm not talking about that. I haven't heard if anyone used this in
practice and I faced with some switches that just start misbehaving
after receiving triple tagged VLAN packets.
<snip>
--
Regards,
Vladimir
--
Regards,
Vladimir
