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

[Jonas Gorski]

On Tue, Aug 11, 2026 at 11:58 AM Vladimir Oltean <olteanv@xxxxxxxxx> wrote:
>
> 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 don't know that in detail either, and have to find some of this out
by experimenting.

>
> 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?"?

If there is, I haven't found it. The register description sounds like
there isn't:

On BCM5325/65, this bit is described as

"This bit applies to ingress frames tagged with a VID not
found in the VLAN table. If the DA is not found in the ARL
table, this bit controls the what happens to the frame.
0 = Ingress frame with VLAN table miss is flooded to all
ports.
1 = Ingress frame with VLAN table miss is dropped."

On newer chips, this bit is described as

"Frames with an invalid VID do not have a
corresponding entry in the VLAN table.
1 = Ingress frames with invalid VID are dropped.
0 = Ingress frames with invalid VID are forwarded to
the IMP port."

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

Right. that's 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?

Not to my knowledge. There is a bit to enable replacing the VID in
VLAN tagged packets with the PVID (in VLAN Control 0), but presumably
this would also rewrite the header.

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

Yes. Anything that is supposed to be forwarded to IMP only is sent out
via the main IMP / port 8, and since port 8 is disabled, it is just
dropped. This presumably applies to all local multicast traffic.

Anything that is flooded is fine, since the floodmasks have port 5 set.

Best regards,
Jonas