Re: [PATCH net 1/2] net: dsa: let drivers offload 8021q uppers on standalone ports

[Vladimir Oltean <olteanv@gmail.com>]

On Thu, Aug 06, 2026 at 10:31:18AM +0300, Semih Baskan wrote:
> Some switches cannot deliver a tagged frame to the CPU while its VID is
> absent from the VLAN table, not even with VLAN filtering turned off.
> b53 is one of them: its VID lookup is always active, and disabling it
> moves the ARL to shared VLAN learning, where ARL operations force VID 0
> and the hardware table drifts away from the bridge fdb. On such
> hardware a standalone port can only receive the traffic of its 8021q
> uppers if their VIDs are programmed into the table.

Then their "vlan_filtering off" implementation is broken.

BTW, how is the "standalone port" behaviour different than the
vlan_filtering=0 bridge port case? If as you say, the switch must have
the VID in the VLAN table to send the packet to the CPU, what is
different when that port is under a VLAN-unaware bridge such that this
presumably does work?

> The existing opt-in for this class of problem,
> ds->needs_standalone_vlan_filtering, delivers those VIDs but does more:
> dsa_port_reset_vlan_filtering() also forces vlan_filtering=1 on a port
> that leaves a VLAN-unaware bridge. hellcreek wants exactly that. b53
> must not have it, because it sets vlan_filtering_is_global, so the
> forced flip would turn the whole switch into a VLAN filtering device
> the first time any port leaves a VLAN-unaware bridge and change
> behaviour for every other port.

If there is a problem with the vlan_filtering_is_global +
needs_standalone_vlan_filtering combination, then hellcreek also suffers
from it, because it does set both flags as well.

> Add ds->needs_standalone_vlan_offload for the narrower need. It
> advertises NETIF_F_HW_VLAN_CTAG_FILTER on user ports, so the 8021q
> layer reports upper VIDs to .port_vlan_add, and it leaves the
> vlan_filtering state alone.
> 
> Upper offload of such a switch never depends on vlan_filtering: every
> VID was already delivered when the upper was created, since the
> feature bit is always on. dsa_port_vlan_filtering() therefore skips
> its ports entirely when a bridge toggles VLAN awareness. Restoring
> them on the way up would add VIDs that were never cleared, and
> clearing them on the way down would strip the driver's record of a
> bridged port's uppers and the feature bit, leaving a port that later
> leaves the bridge with uppers that cannot receive and no way to
> re-offload them. The conduit change path keeps its explicit teardown
> and restore of standalone VLANs, and now also runs it for a standalone
> port of such a switch while VLAN filtering is off, because that port
> has VLANs on the CPU port too.

I don't really understand the rest of the explanation for the "narrower
need", as it relies on the false fact that hellcreek is somehow not in
the same boat.

Why can't standalone ports tolerate the .port_vlan_filtering() call?