[PATCH] net: support VLAN stacking packet type parsing

[Medvedkin, Vladimir]

Hi Morten,

On 7/7/2025 11:00 PM, Morten Brørup wrote:
>
> *From:*Vladimir Medvedkin [mailto:medvedkinv at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20250708/f48570e8/attachment-0001.htm>