Re: [PATCH net] net: dsa: b53: be VLAN unaware when not filtering

[Vladimir Oltean <olteanv@gmail.com>]

On Wed, Aug 12, 2026 at 11:50:47PM +0300, Vladimir Oltean wrote:
> 1. This looks implementable with some complexity isolated within the b53
>    driver:
>    - on any .port_fdb_add(), .port_fdb_del(), .port_mdb_add(), .port_mdb_del(),
>      compare the VID of the entry with the dev->vlan_enabled state.
>      - if VID != 0 and dev->vlan_enabled, or if VID == 0 and !dev->vlan_enabled,
>        commit the operation directly to the ARL, as is currently done
>      - if VID == 0 and !dev->vlan_enabled, or if VID != 0 and dev->vlan_enabled,
>        operate on a software list, allocating, deleting or modifying a
>        local representation of the ARL entry
>    - on vlan_filtering toggles from 0 to 1 or from 1 to 0, acquire
>      dev->arl_mutex and flush out all static and dynamic ARL entries
>      across the entire switch, commit the static ones from the software
>      list and clear the software list
>    - dev->vlan_enabled will probably need to be merged with
>      dev->vlan_filtering, since the vlan_enabled=1 vlan_filtering=0 case
>      is broken

Actually this algorithm is too simplistic as I specified it. In this sequence:

ip link add br0 type bridge vlan_filtering 0 && ip link set swp0 master br0
bridge fdb add swp0 00:01:02:03:04:05 master static
ip link set br0 type bridge vlan_filtering 1
ip link set br0 type bridge vlan_filtering 0 # the 00:01:02:03:04:05 address would be lost here

Furthermore, the ARL is limited in size (1024, 2048 or 4096 entries),
and we could mistakenly end up queuing more than we can commit.

I'm not yet sure what are reasonable amendments that would keep the
complexity in check. Currently the most obvious would be to do a one-time
allocation of dev->num_arl_bins * dev->num_arl_buckets, to always keep
all entries in software, and only the active ones in hardware. But I
need to think about this some more, as I'm aware OpenWrt typically
doesn't operate with huge memory budgets.

I'm not sure that avoiding local copies is possible, because the ARL
entries don't come from a single source - we have bridge FDB, bridge
MDB, ndo_dflt_fdb_add(), dev->uc, dev->mc, dev->dev_addr, sometimes
replicated per VLAN, etc. They all only converge at driver level.