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

[Jonas Gorski]

Hi,

On Wed, Aug 12, 2026 at 10:50 PM Vladimir Oltean <olteanv@xxxxxxxxx> wrote:
>
> On Wed, Aug 05, 2026 at 09:44:51AM +0200, Jonas Gorski wrote:
> > Unfortunately what this does is break modifying ARL entries with VID
> > != 0, which is why I haven't added this.
> >
> > While SVL is active, any ARL add/remove operations ignore the VID
> > field/register and force it to 0, making existing static ARL entries
> > with VID != 0 inaccessible, and any (static) ARL entries added will
> > have their VID set to 0, regardless what the software entry said.
> >
> > This causes the ARL hardware table to go out of sync with the bridge
> > fdb/mdb software tables, and will lead to potentially hard to debug
> > network issues.
> >
> > The options to remedy this are:
> >
> > 1. keep track of all static fdb (and mdb) entries added to the
> > hardware table, so we "sync" it on switching vlan filtering on/off (or
> > find a way to do so without having a copy), or
> > 2. while vlan filtering is off, have static vlan table entries for all
> > possible VIDs, or
> > 3. use direct memory access registers to directly modify the ARL table
> > memory instead of going through default registers while SVL is
> > enabled.
> >
> > Neither one is a quick and easy fix.
> >
> > 1/2 make switching vlan filtering likely a costly operation (I test
> > implemented 2, and it takes several seconds for SPI connected switches
> > - not sure if this is acceptable). 3 requires knowing the in-memory
> > formats for each switch chip, which aren't publicly documented.
> >
> > Best regards,
> > Jonas
>
> I think the only reliable way to fix VLAN unaware mode in a way that's
> portable across all b53 variants is a variant of this patch: allow
> 802.1Q mode to be disabled. Then we need to deal with the fallout caused
> by it upon the ARL.
>
> 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

You already found the issue with dropping the software entries; we
need to keep them.

That said, maximum is 4k entries, and assuming an entry is 6 bytes mac
+ 2 bytes vid + 2 bytes port (mask), it would still be just 40kB,
which is nothing compared to the buffers wifi drivers tend to consume
(e.g. IIRC ath12k requires a device with 512? MiB RAM). The switch
memory itself is 64kB, which I would assume is the maximum we may ever
need.

The algorithm how the index is calculated is documented, so we could
then just emulate the ARL table in software, and then even do
collision checks, at least between static entries. Though we won't
know if they collide with learned dynamic entries. Which makes me
wonder, what's the expected priority here? Currently we reject adding
a static entry if all bins are occupied by dynamic entries (unless a
dynamic entry matches the static one).

One (non) issue here is that BCM5325 and BCM5365 do not support
hardware flushing, so flushing can only by done by deleting all
entries individually. That being said, they are also the ones where
VLAN-unaware bridging works already, so they wouldn't need it.

> 2. I see bcm_sf2 has support for B53_JOIN_ALL_VLAN_EN; IIUC this
>    proposal is a soft emulation of that. Would it work though? 2 concerns:
>    - in b53_switch_chips[] I see not all switches have a full 4K VLAN table

Funny enough, these are the same ones where DROP_VTABLE_MISS=0 floods
instead of traps to IMP, so we don't need it for those.

>    - unless b53 has a feature equivalent to MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED
>      rather than the port-wide vl->untag, the emulation would either push a
>      VLAN tag in originally untagged frames, or strip a VLAN tag from
>      previously VLAN tagged frames. Neither option fits the bill for
>      what vlan_filtering=0 semantics expect (ignore the tag).

Modern b53 switches supports full 4k VLAN table entries, including 0
and 4095. By using 0 as the VLAN for untagged frames and setting PVID
to 0, we can leave all valid VIDs (1-4094) as tagged.

There is also a (global) bit in VLAN_CTRL5 to configure something
similar to MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED:

 *     PRESV_NON1Q      - en_preserv_non_1q_frame: (default 0)When
enabled, it preserves untagged frame as untagged frame at TX
regardless of untag map in VLAN table, and preserves priority (802.1p)
tagged frames as priority tagged frames at TX if untag map in VLAN
Table is 0, but otherwise ntag priority tag.

This is obviously incompatible with VLAN-aware bridges, but should be
fine for VLAN-unaware ones.

>
> 3. From a distance it doesn't sound bad, but I cannot comment on the
>    feasibility of this and the scalability across the 4 b53_arl_ops;
>    maybe Florian can.

The main issue here is finding out the various in-memory formats, as
they are not documented in the datasheets or public code. And there
will likely be more than 4, as devices may have the same ARL access
register layouts, but their in-memory layouts can differ (AFAICT
bcm53115 and bcm53118 despite same generation/family have different
layouts).

Though it could be combined with 1. for those we don't have the layouts.

>
> The big advantage of option #1 is that it shouldn't depend on any HW
> functionality which is only present on some silicon variants. I don't
> see any downside except for the higher SW complexity in the control path.
>
> We could also discuss falling back to software bridging for the
> vlan_filtering=0 case, but that penalizes the data path, so it would
> probably not be the option of choice.

Right, that would be the quick workaround to allow functionality. We
just need to not mark them as forwarded, as DROP_VTABLE_MISS=0 will
have them sent to CPU already.

Best regards,
Jonas