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

[Semih Baskan]

Hi Vladimir,

> Is this a hardware limitation, or is it because global state
> (dev->vlan_enabled) blinds b53_arl_rw_op()'s attempts to look at FDB
> entries of the other type?

I tested that separation on the RT-N18U (BCM53011 rev 5) during the
measurements for the new series. Two builds kept ARLTBL_IVL_SVL_SELECT
at IVL while disabling the table, so the ARL read/write ops were never
switched to SVL:

  - table off, select held at IVL, VC0 learning-mode bits cleared: a
    static entry with VID 100, present in the hardware dump before the
    toggle, is gone from the dump after it
  - table off, select held at IVL, VC0 "individual VLAN learning mode"
    bits (bits 6:5) kept set as well: same result
  - positive control, table on, identical toggle: the entry survives
    and the dump shows it

The observable is the fdb search path (bridge fdb show dev ... self),
which does not go through b53_arl_rw_op() at all: b53_fdb_dump() only
touches the ARL search registers. The same dump shows the entry before
the toggle and shows survival in the table-on control, so it can tell
the difference. With every mode input the driver has held at IVL, and
with the reads happening through a path b53_arl_rw_op() cannot blind,
the entry still does not survive disabling the table. On this chip
that makes it a property of the table being off rather than an
artifact of the select flip. Jonas also noted in the new thread that
ARLTBL_IVL_SVL_SELECT is not implemented on 5301x at all, which fits:
the bit visibly did nothing in these tests.

I cannot rule out that the entries still sit in silicon and are merely
unreachable in every mode the driver can program, but for the driver
and for forwarding they behave as lost either way.

The measurements are summarized in the new series' cover letter:

https://lore.kernel.org/all/20260806073119.387-1-strst.gs@xxxxxxxxx/

Best regards,
Semih