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

[Jonas Gorski]

On Wed, Aug 12, 2026 at 11:21 AM Semih Baskan <strst.gs@xxxxxxxxx> wrote:
>
> Hi Jonas,
>
> On Wed, Aug 12, 2026 at 10:24 AM Jonas Gorski <jonas.gorski@xxxxxxxxx> wrote:
> > > One observation for the "is there another bit" question: on my
> > > BCM53011 the running value of VLAN_CTRL5 is 0x10. That is bit 4, which
> > > the driver never writes and has no name for. I do not know what it
> > > does, and it may simply be the bootloader default, but it is a bit in
> > > exactly the register you are asking about.
> >
> > Assuming you mean VLAN_CTRL2, this bit is described for BCM5325 as
> > "When set to 1, GMRP,GVRP are checked by the
> > VLAN's forward map" with a default of 0.
>
> I did mean VLAN_CTRL5; both registers happen to read 0x10 here.
> Broadcom's published MDK definitions for BCM53010 [1] name both bits:
>
> VLAN_CTRL5 bit 4 is EGRESS_DIR_FRM_BYPASS_TRUNK_EN, a bypass for
> trunking redirection of egress directed frames, unrelated to the miss
> path. The same file gives DROP_VTABLE_MISS the exact text you quoted
> for the newer chips (drop when set, forward to IMP when clear), and no
> other option.
>
> For VLAN_CTRL2, bit 4 is documented as reserved on this chip; the
> GMRP/GVRP forward map check you quote from BCM5325 moved to bit 5
> (EN_GMRP_GVRP_V_FWDMAP), which reads 0 here. So the set bit is a
> reserved default, not the retained BCM5325 function. The remaining
> VLAN_CTRL2 fields are GMRP/GVRP untag handling and a v_fwdmap bypass
> for the management port, so nothing in it changes ingress
> classification.

I copied the wrong line, bit 4 on BCM5325 is en_GMRP_GVRP_v_tagging /
"When set to 1, GMRP,GVRP frames are tagged
according to VLAN rule". Bit 5 is also the fwd map (I guess somewhere
I did a 0-index / 1-index swap in my head), so no changes there.

> The same file also names what b53 calls VC0_VID_CHK_EN and
> VC0_VID_HASH_VID: one two bit field, VLAN_LEARN_MODE (00 SVL, 11 IVL,
> 01 and 10 illegal settings). It selects how the ARL is hashed, not
> how ingress frames are classified, which explains why clearing those
> bits changed nothing in my measurement. (My intermediate test state
> cleared only bit 6, which per this description is an illegal encoding;
> the legal all clear SVL state behaved identically, so the conclusion
> stands.) And the VID to PVID rewrite bits in VLAN_CTRL0 are documented
> to act only on frames with VID 0, so on this chip they cannot reclassify
> real tagged traffic; that rules out the last candidate for a tag-blind
> mode here.

I think the register description might be wrong here, because changing
the VID to PVID for untagged packets is the default / expected
behavior.

The datasheet for switches I do have say it replaces it if the VID is not 0:

"1=
• For a single-tag frame with VID not = 0, change
the VID to PVID.
• For a double-tag frame with outer VID not = 0,
change outer VID to PVID.
0 = No change for 1Q/ISP tag if VID is not 0."


> > One thing you could try is to mark all ports as WAN ports. The
> > WAN_PORT_SEL register (page 0, offset 0x26, 16 bit) has a bitmask for
> > wan ports.
>
> I tried it today, and first read the register as is: WAN_PORT_SEL
> reads 0x0000 on my BCM53011, three consistent reads. The kernel
> driver never writes it on this generation (it uses offset 0x26 only
> on BCM5325, as the protected port register there), so it has been
> 0x0000 through every measurement I have reported in this thread.
>
> My earlier statement that BPDUs ingressing switch port 0 reach the CPU
> was a counter attribution error. That probe read a +7 delta on the wan
> netdev counter with no capture running (that image had no tcpdump),
> while the BPDU source was a live bridge port on another router, a device
> that also chatters IPv6 multicast. Today, with captures bracketing every
> counter, BPDU class frames are delivered on none of the ports I probed:
> crafted ones on lan2, on lan3 bridged and standalone, and on port 0,
> plus real kernel STP hellos on port 0 itself, all zero, while the same
> frames with a benign multicast destination deliver 10 of 10 to the CPU
> on every port tried. So there is no WAN/LAN asymmetry and no special
> port 0: with WAN_SELECT empty, everything trap classed aims at IMP0
> exactly as the GMNGCFG text says, and IMP0 is down. Your description of
> the port-5-only breakage was right, and it is worse than I previously
> reported: STP delivery is dead on the WAN port too, not just the LAN
> ports.
>
> Then the experiment you suggested, on the live system, volatile write
> with a timed revert armed: WAN_PORT_SEL set to 0x000c, marking the
> two ports that had my test endpoints (lan2/port 2, lan3/port 3),
> leaving the management port alone.
>
> - No trap rescue appears: BPDUs into a WAN-marked port still deliver
>   nothing, so the marking does not retarget the trap path at IMP1 on
>   this topology.
> - Isolation is exactly as the description implies: unicast between
>   the two WAN-marked ports through the same vlan-unaware bridge went
>   from 7/7 to 0/7, and even plain multicast to CPU delivery on the
>   marked ports went from 10/10 to zero, consistent with "forwarded to
>   the CPU port only" resolving to the dead IMP0 here.
> - My management connection through a port I had not marked also
>   dropped, and came back only when the timed revert fired. The
>   effect is broader than the marked ports.
>
> > So it may also isolate them from each other. Also out of curiosity,
> > can you wan port talk with non-wan talks in a bridge? Because the
> > description implies it should not.
>
> The pair I could measure says no: the two WAN-marked ports in the same
> bridge stopped talking to each other entirely, and on this port 5
> topology they stopped talking to the CPU too. The BCM53010 text also
> says port 5 can be selected as a WAN port only when IMP1 is disabled, so
> the CPU port itself cannot be WAN marked on a topology like mine.

The description of GLOBAL_CONFIG / GC_FRM_MGMT_PORT_M says that
"11=Enable Dual-IMP ports(both IMP0 and IMP1)   All traffic to CPU
from LAN ports will be forwarded to IMP0; and All traffic from WAN
ports will be forwarded to IMP1."

so I had the faint hope that making all ports WAN ports makes it trap
to IMP1/5 instead of IMP0/8.

But if it doesn't, and additionally isolates them, then this obviously
won't work, and enabling port 8 as CPU port really is the only option.

Thank you for the quick confirmation.

Best regards,
Jonas