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

[Florian Fainelli]

On 8/12/26 00:24, Jonas Gorski wrote:
> On Tue, Aug 11, 2026 at 3:19 PM Semih Baskan <strst.gs@xxxxxxxxx> wrote:
> > Hi Vladimir,
> >
> > > 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?
> >
> > Correct, at least on bcm5301x, and this part is measured rather than
> > read from documentation: with VC5_DROP_VTABLE_MISS clear, all three
> > VC4_ING_VID_CHECK settings behave identically for a VTABLE miss (0 of
> > 7 delivered in every combination, standalone RX probes from the
> > measurements behind the cover letter). Whatever the check field
> > controls happens independently of the miss path.
> >
> > 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.
>
> Since other bits (sort of) match with their meanings, one could assume
> it retained it, and now defaults to 1, but there is no guarantee for
> that.

On Northstar, bit 4 in VLAN_CTRL5 is described as:

EGRESS_DIR_FRM_BYPASS_TRUNK_EN: Egress directed frame bypass trunking 
re-direction enable.

1: egress directed frame from management port will bypass re-trunk 
re-directed rule
0: egress directed frame from management port will follow trunking 
re-directed rule

> > > 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?
> >
> > I cannot answer what the bits mean from documentation, but I can answer
> > what they do on bcm5301x, measured just now with two external endpoints
> > on two front ports of a vlan_filtering=0 bridge: neither of the two
> > candidate bits gives that mode. With VC0_VID_CHK_EN cleared, and then
> > with VC0_VID_HASH_VID cleared as well, tagged VID 100 frames still
> > deliver 0 of 7 to the far port and 0 to the CPU, exactly as at the
> > 0xe3 default, while untagged traffic keeps working in every state and
> > the default restores cleanly. So on this chip the 802.1Q header keeps
> > participating in classification as long as VC0_VLAN_EN is set, and
> > clearing those two bits under it does not change that. Clearing
> > VC0_VLAN_EN itself is
> > the earlier thread: it works but costs the VID-keyed ARL. I have not
> > probed VLAN_CTRL2 for undocumented bits; on my chip it reads 0x10.

VC0_VID_CHK_EN is not defined on BCM5310X, however bits 6:5 are 
VLAN_LEARN_MODE with 00: SVL and 01: IVL.

> > > How badly broken are the configurations with only port 5 as CPU port?
> > > Is other management traffic like STP also not delivered correctly?
> >
> > It splits by the port's management class, measured on the RT-N18U
> > earlier in the thread. BPDUs ingressing switch port 0 reach the CPU,
> > because port 0 is WAN class and its traps go to IMP1, which is port 5.
> > Management traps from the LAN class ports 1-4 go to IMP0, which is
> > port 8, and are lost, because GMNGCFG has no "IMP1 only" encoding: the
> > driver's OR of the field mask programs dual IMP mode and port 8 is
> > down. So on the in-tree topology STP is broken on the four LAN ports
> > and working on the one WAN port.
>
> 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. It may allow delivery to IMP1, but the description of the
> WAN port feature is also
>
> "Select a port as a WAN port, then all that port’s traffic is
> forwarded to the CPU port only. The non-
> WAN port traffic from all other local ports does not flood to the WAN port."
>
> 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.

IIRC, the use case on Northstar was to basically have one of the 
internal ports as the "WAN" port and the other one for LAN traffic. The 
idea was that this would double the bandwidth internally since each CPU 
port has allocated bandwidth and this is the scheme that is used to make 
use of the flow accelerator block (FA) which is not supported upstream. 
Now that generate AI is a thing, maybe we will see that at some point.
--
Florian