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

[Vladimir Oltean]

On Tue, Aug 11, 2026 at 09:44:37AM +0200, Jonas Gorski wrote:
> 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.

You need to be more specific, because I don't have a good grasp of the
various vc0/vc1/vc4/vc5 bits and specifically how they interact.

I *think* you are talking about bit VC5_DROP_VTABLE_MISS having
different behaviours when clear, because that's the only reasonable
interpretation of the code consistent with your explanation. Are we sure
there is no other bit which influences "if we don't drop VTABLE misses,
then what?"?

Then I suppose the VC4_ING_VID_CHECK_MASK affects only what happens with
VLAN membership violations (i.e. VTABLE hit, but port not in VLAN). Thus
it does not influence the VC5_DROP_VTABLE_MISS=false case, correct?

If customizing/unifying the behaviour on VTABLE misses is a dead end,
could we consider an alternative? Some switches support having the
VTABLE enabled, but ignore the 802.1Q header from incoming packets
(thus, all packets get classified to the port PVID). Is there any bit
which achieves this in b53? What do VC0_VID_CHK_EN and VC0_VLAN_EN do
exactly? Does B53_VLAN_CTRL2 maybe have some useful hidden bits?

> 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.

Good point. tools/testing/selftests/net/forwarding/bridge_vlan_unaware.sh
should definitely have a test for this condition.

> > 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.

How badly broken are the configurations with only port 5 as CPU port?
Is other management traffic like STP also not delivered correctly?