Re: [PATCH net-next v7 09/10] net: dsa: realtek: rtl8365mb: make L2/LUT access work on family D

[Luiz Angelo Daros de Luca]

> The L2 lookup table on family D switches (e.g. RTL8367S-VB) differs
> from family C in ways that make the current FDB/MDB code misbehave:
>
>  - An L2 entry is 5 words instead of 6, with a different field layout
>    in words 3 and 4 (port, age, static and multicast member bits).
>  - There is no EFID and no per-bridge FDB isolation. The register at
>    0x0A32, used as the per-port EFID register on family C, is the LUT
>    aging timer on family D, so writing an EFID there corrupts it.
>  - In the table access interface, the SPA field is 3 bits wide and the
>    address register is 12 bits wide, with no address extension bit.
>  - Only ports 0..7 are present in the LUT and there is no
>    FLUSH_PORT_EXT register.
>
> Teach the table and L2 code about these differences, selecting the
> layout at runtime with rtl8365mb_get_family(). Family C behaviour is
> unchanged.
>
> Specifically:
>
>  - rtl8365mb_table: use the family D port mask and address width, and
>    read the hit address from status bits [11:0].
>  - rtl8365mb_l2: add family D unicast/multicast entry (de)serialisers
>    behind *_any() wrappers, pass the proper entry size to the table
>    layer, reject ports above 7, report SVL (FID) entries with VID 0.
>    Use age 6 for static unicast entries as the vendor code does, and
>    look an entry up before deleting it so that a missing entry is not
>    allocated by the delete.
>  - rtl8365mb_main: make port_set_efid() a no-op on family D, add a LUT
>    init step that clears IPMC_HASH and BCAM_DISABLE and programs the
>    aging timer, and do not advertise fdb_isolation or
>    max_num_bridges. Traffic between bridges is then isolated by the
>    port isolation masks only.

So, family D does not have EFID support? I'm curious how this will
work in the FDB table when you have two bridges using the same VLAN
and receiving traffic from the same MAC address. On family C and
earlier, the L2 table uses both EFID and FID/VID as lookup keys.
Without EFID on family D, what are the implications?

The number of EFIDs defines the number of supported bridges. Without
EFID, should we limit the number of bridges to 1 (or prevent creating
multiple bridges with conflicting VLANs)? Turning a used field or
function into a no-op without handling its architectural consequences
can lead to subtle bugs.

This highlights why a simple end-user test isn't enough when adding
support for a new family. Every feature needs to be tested
individually and aligned with the driver changes. I've had the
RTL8367R up and running for months, but I'm still testing features and
finding bugs (and the support is still incomplete). That's also why
the VLAN/FDB offloading patches took so long to get merged. Alvin's
original implementation worked well for standard use cases, but
covering edge cases and verifying all features required a significant
amount of rigorous testing and bug fixing.

Best regards,

Luiz