RE: RE: [PATCH net 0/5] net: stmmac: Fix double VLAN 802.1ad tag handling

[Ovidiu Panait]

Hi Nazim,

> 
> On 30/7/2026 9:57 pm, Ovidiu Panait wrote:
> > Hi Nazim Amirul,
> >
> >> On 29/7/2026 7:35 pm, Maxime Chevallier wrote:
> >>> + Nazim Amirul
> >>>
> >>> On 7/29/26 11:51, Ovidiu Panait wrote:
> >>>> Currently, hardware VLAN stripping is broken for 802.1ad tags.
> >> vlan_rx_hw()
> >>>> hardcodes ETH_P_8021Q when putting the hardware tag into the skb,
> >> rather
> >>>> than using the actual protocol from the packet. Because of this,
> >> packets
> >>>> that contain an 802.1ad outer tag are incorrectly passed up the stack
> >> as
> >>>> having an 802.1Q tag.
> >>>>
> >>>> This issue was observed on the Renesas RZ/V2H platform (which has a
> >> dwmac4
> >>>> IP), when testing QinQ ping:
> >>>>
> >>>>     # DUT
> >>>>     ip link add link end0 name end0.100 type vlan proto 802.1ad id
> 100
> >>>>     ip link add link end0.100 name end0.100.200 type vlan proto
> 802.1q
> >> id 200
> >>>>     ip addr add 172.16.3.2/24 dev end0.100.200
> >>>>     ip link set end0 up
> >>>>     ip link set end0.100 up
> >>>>     ip link set end0.100.200 up
> >>>>
> >>>>     # Peer
> >>>>     ip link add link eth0 name eth0.100 type vlan proto 802.1ad id
> 100
> >>>>     ip link add link eth0.100 name eth0.100.200 type vlan proto
> 802.1q
> >> id 200
> >>>>     ip addr add 172.16.3.1/24 dev eth0.100.200
> >>>>     ip link set eth0 up
> >>>>     ip link set eth0.100 up
> >>>>     ip link set eth0.100.200 up
> >>>>     ping 172.16.3.2
> >>>>       -- FAIL --
> >>>>
> >>>> This series addresses the issue for both dwmac4 and dwxgmac2:
> >>>> - dwmac4: since dwmac4 does not expose the tag type in the RDES3
> >>>>     descriptor, it cannot support hardware double VLAN stripping
> >> correctly.
> >>>>     This series disables double VLAN stripping for it, so the 802.1ad
> >> tags
> >>>>     are left in place and are handled by the software VLAN path.
> >>>>
> >>>> - dwxgmac2: the RDES3 descriptor does report the type, so the code
> was
> >>>>     updated to read it instead of hardcoding ETH_P_8021Q.
> >>>>
> >>>> Note: patch 5/5 was compile tested only, as I do not have the
> hardware.
> >>>> However, it uses the same codepath as dwmac4, so it has the same
> issue.
> >>> Nazim Amirul, as you seem to have access to some AgileX5 with XGMAC,
> can
> >> you
> >>> see if you can reproduce the issue on your side and if this series
> >> solves it ?
> >>
> >> Hi Maxime,
> >>
> >> Tested on my end and seeing the same failure as above without this
> >> series, is this patch 5 is the only patch needed to fix the problem?
> >
> > For dwxgmac2 yes, patch 5 is the only one that is needed. Dwmac4 doesn't
> report
> > the type of the stripped tag (802.1ad vs 802.1Q) so the other patches
> are needed
> > to disable the double VLAN stripping.
> >
> > Thanks,
> > Ovidiu
> >
> >>> Thanks :)
> >>>
> >>> Maxime
> >
> Hi Maxime, Ovidiu
> 
> I tested patch 5 alone on Agilex5 :)
> 
> Setup (back-to-back):
> 
> ip link add link eth0 name eth0.100 type vlan proto 802.1ad id 100
> ip link add link eth0.100 name eth0.100.200 type vlan proto 802.1q id 200
> # DUT1: 172.16.3.1/24 on eth0.100.200
> # DUT2: 172.16.3.2/24 on eth0.100.200
> Results:
> 
> ethtool -K eth0 rx-vlan-offload off → QinQ ping PASS
> ethtool -K eth0 rx-vlan-offload on → QinQ ping FAIL (100% loss)
> ethtool -k eth0 shows rx-vlan-offload: on and rx-vlan-stag-hw-parse: on.
> 
> So the software VLAN path is fine, but with HW RX VLAN stripping
> enabled, patch 5 alone does not fix QinQ on this XGMAC.

Could you please also test if single VLAN works with hw stripping enabled,
before/after applying patch 5?

> I will be happy to collect more data (tcpdump / RDES3 ET-LT) or try
> additional patches from the series if you have a preferred next step.
>

Yes, a tcpdump log and dumping RDES3 ET-LT from within
dwxgmac2_wrback_get_rx_vlan_type() could also help with debugging this.


Thanks,
Ovidiu

> BR,
> Nazim