Re: [PATCH net v6] net: stmmac: remove software VLAN tag stripping

From: Maxime Chevallier

Date: Sat Sep 12 2026 - 17:37:32 EST


Hi,

On 9/11/26 16:11, peilinhe2020@xxxxxxx wrote:
> From: Peilin He <he.peilin@xxxxxxxxxx>

Eaxh patch should be an independent thread, not a reply to the previous
one.

>
> The software VLAN stripping logic in stmmac_rx_vlan() was originally
> introduced in 2014 by commit b93819854d6e ("stmmac: Add vlan rx for
> better GRO performance.") as a workaround to improve GRO performance,
> since at that time GRO could not handle frames with VLAN tags. However,
> this limitation was resolved in 2015 by commit 66e5133f19e9 ("vlan: Add
> GRO support for non hardware accelerated vlan"), which added GRO support
> for non-hardware-accelerated VLAN frames. Keeping a software fallback
> path for VLAN stripping is no longer necessary and only adds complexity.
>
> Fixes: b93819854d6e ("stmmac: Add vlan rx for better GRO performance.")
> Signed-off-by: Peilin He <he.peilin@xxxxxxxxxx>
> Reviewed-by: xu xin <xu.xin16@xxxxxxxxxx>
> Reviewed-by: Jiang Kun <jiang.kun2@xxxxxxxxxx>

So this patch breaks all the stmmac selftests on some dwmac1000, e.g. on
dwmac-meson8b :

# ethtool -t eth0

[trimming the output to tests that don't report -95, i.e. -EOPNOTSUPP]

The test result is FAIL
The test extra info:
1. MAC Loopback -110
2. MMC Counters -110
3. EEE -110
4. Hash Filter MC -110
8. Flow Control -110
28. Jumbo Frame -110

However I'd say this patch is still correct, what seems to be happening is :

As now we don't have the NETIF_F_HW_VLAN_[C|S]TAG_RX flags set anymore, the
platforms that don't support VLAN offloads end-up skipping this check in
stmmac_phylink_setup() :

if (!(priv->plat->flags & STMMAC_FLAG_RX_CLK_RUNS_IN_LPI) &&
!(priv->dev->features & NETIF_F_VLAN_FEATURES))
config->eee_rx_clk_stop_enable = true;

So if we enter LPI during the selfests, PHY stops rxc, and notoriously on
stmmac if you don't have RXC, half the features don't work, and especially
the DMA RX path.

This is confirmed by running :

# ethtool --set-eee eth0 eee off
# ethtool -t eth0
The test result is PASS
The test extra info:
1. MAC Loopback 0
2. MMC Counters 0
4. Hash Filter MC 0
8. Flow Control 0
28. Jumbo Frame 0


A solution is to block RXC from being disabled in the selftests.

Can you add the following patch to your series, as patch number 1 so
that ethtool selftests still work during bisect ? I've tested it on
the board who'se selftest failed with this patch and it works :)

Thanks,

Maxime

--------------------8x------------------------------------------