[PATCH dpdk v3] net: fix VLAN packet type
Kevin Traynor
ktraynor at redhat.com
Thu Apr 23 12:59:29 CEST 2026
On 4/23/26 10:49 AM, Robin Jarry wrote:
> Kevin Traynor, Apr 23, 2026 at 11:19:
>> Not shown in diff, but for:
>>
>> pkt_type |=
>> proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN) ?
>> RTE_PTYPE_L2_ETHER_VLAN :
>> RTE_PTYPE_L2_ETHER_QINQ;
>>
>> It seems to be produce the right result, but I'm not sure we should be
>> treating the ptype L2 defines as bitmasks. Maybe I'm wrong and it was
>> planned, but it looks like a coincidence it works now because QINQ (0x7)
>> happens to be a superset of VLAN (0x6) for the OR.
>>
>> Perhaps you could check vlan_depth and assign VLAN or QINQ based on that?
>
> I hadn't considered this. It would make sense to have something like:
>
> l3:
> switch (vlan_depth) {
> case 0:
> pkt_type = RTE_PTYPE_L2_ETHER;
> break;
> case 1:
> pkt_type = RTE_PTYPE_L2_ETHER_VLAN;
> break;
> default:
> pkt_type = RTE_PTYPE_L2_ETHER_QINQ;
> break;
> }
>
> Mind that this will report RTE_PTYPE_L2_ETHER_QINQ even if we have
> double stacked 802.1Q tags (ether type 0x8100) and no 802.1ad S-tag
> (QinQ 0x88A8). I don't think this is an issue, but I'll let you judge.
>
I'm not sure about this.
> I can send a v4 with this if that suits you.
>
Setting pkt_type later has some implications for early returns (now i
notice that's present in v3 too)
Would this work ?
@@ -358,10 +358,12 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
struct rte_vlan_hdr vh_copy;
+ if (vlan_depth == 0) {
+ pkt_type =
+ proto ==
rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN) ?
+ RTE_PTYPE_L2_ETHER_VLAN :
+ RTE_PTYPE_L2_ETHER_QINQ;
+ }
if (++vlan_depth > RTE_NET_VLAN_MAX_DEPTH)
return 0;
- pkt_type |=
- proto == rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN) ?
- RTE_PTYPE_L2_ETHER_VLAN :
- RTE_PTYPE_L2_ETHER_QINQ;
vh = rte_pktmbuf_read(m, off, sizeof(*vh), &vh_copy);
if (unlikely(vh == NULL))
More information about the stable
mailing list