Re: [PATCH net 1/2] net: dsa: let drivers offload 8021q uppers on standalone ports

On Tue, Aug 11, 2026 at 8:25 AM Semih Baskan <[email protected]> wrote:
>
> Hi Vladimir,
>
> > What about VLAN-unaware bridging? Can packets with VID=100 be forwarded
> > autonomously between two ports of a vlan_filtering=0 bridge if that VLAN
> > is not programmed to hardware?
>
> No. On every b53 switch measured so far it cannot, and it fails in the
> same place on all of them. The frame passes ingress admission (with
> filtering off the driver programs VC4_NO_ING_VID_CHK and clears
> VC5_DROP_VTABLE_MISS, one shared code path for every chip), then the
> forwarding stage resolves the egress set from the VLAN table entry for
> that VID. A VID that is not programmed resolves to an empty member set,
> so there is nothing to forward to on any port.
>
> > Does the behaviour depend on silicon capabilities, or is it the same for
> > all switches handled by the b53 driver?

VLAN-unaware bridging does work on BCM5325 and BCM5365. The driver was
originally written for this family (before upstream submission).

There is a register bit that controls what happens when a VLAN-tagged
frame is received for which no (valid) VLAN table entry exists.
Default is drop.

On BCM5325/5365, setting this bit makes the switch *forward* the frame
regardless. This is why it works on those switches even with
VLAN-aware mode enabled in hardware.

On later generations, the bit's function changed to "redirect to CPU".
Stand-alone ports still work there, but VLAN-unaware bridging does
not. Everything goes to CPU, and the tag driver marks it erroneously
as offloaded.

But I didn't notice this until recently. Partially also because there
is no kernel test for VLAN tagged forwarding on a vlan-unaware bridge,
only for standalone ports. Everything saying OK with a vlan-unaware
bridge made me think everything works as expected.

> The port-to-port part has been the same on everything measured. What
> depends on the silicon is only whether the CPU gets a copy of the miss
> frame. Three chips have data across these two threads:
>
>   - BCM53011 (bcm5301x, my RT-N18U): measured for the CPU direction.
>     Every ingress-check setting (NO_ING_VID_CHK, VIO_FWD, VIO_TO_IMP,
>     plus clearing the VC0 miss-drop bit) delivers 0 of 7; the frame dies
>     at member-set resolution, not at admission. Whether a miss frame
>     reaches the CPU at all depends on the IMP routing from the other
>     subthread: with port 8 as IMP it does (indiscriminately), with the
>     in-tree port 5 topology it never does for LAN-class ports.

Only port 5 is an invalid configuration, so no wonder it breaks. The
only valid configurations are port 8 or port 8 + 5, but not port 5
only.

>   - BCM63268 and BCM53115: Jonas measured exactly this case there.
>     Standalone RX works even on a table miss, so the CPU copy exists,
>     but forwarding between ports does not. That is the case you are
>     asking about, on two other generations of this silicon.

Note that BCM53115 also supports a dual IMP / CPU setup, and has the
same limitations, so this isn't something new to BCM5301x. The only
difference is that on BCM5301x the switch is embedded and has ports 5
and 8 (and 7) hardwired to internal MACs, which led to the incorrect
usage of (only) port 5 as CPU.

Best Regards,
Jonas