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

[Semih Baskan]

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.

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

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

Best regards,
Semih