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

On 30/7/2026 9:57 pm, Ovidiu Panait wrote:

Hi Nazim Amirul,

quoted

On 29/7/2026 7:35 pm, Maxime Chevallier wrote:

quoted

+ Nazim Amirul

On 7/29/26 11:51, Ovidiu Panait wrote:

quoted

Currently, hardware VLAN stripping is broken for 802.1ad tags.

vlan_rx_hw()

quoted

quoted

hardcodes ETH_P_8021Q when putting the hardware tag into the skb,

rather

quoted

quoted

than using the actual protocol from the packet. Because of this,

packets

quoted

quoted

that contain an 802.1ad outer tag are incorrectly passed up the stack

as

quoted

quoted

having an 802.1Q tag.

This issue was observed on the Renesas RZ/V2H platform (which has a

dwmac4

quoted

quoted

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

quoted

quoted

    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

quoted

quoted

    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.

quoted

quoted

    This series disables double VLAN stripping for it, so the 802.1ad

tags

quoted

quoted

    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

quoted

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

quoted

quoted

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

BR,
Nazim