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

[Florian Fainelli <florian.fainelli@broadcom.com>]

On 8/12/26 15:06, Vladimir Oltean wrote:
> 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.
> 

Would not we just be better off with enforcing vlan_filtering=1 for any 
bridge that is created? Unlike Marvell switches, the Roboswitch has no 
notion of egress as tag unmodified unfortunately.
-- 
Florian