net: mscc: ocelot: treat 802.1ad tagged traffic as 802.1Q-untagged
authorVladimir Oltean <vladimir.oltean@nxp.com>
Thu, 15 Aug 2024 00:07:07 +0000 (03:07 +0300)
committerDavid S. Miller <davem@davemloft.net>
Fri, 16 Aug 2024 08:59:32 +0000 (09:59 +0100)
commit36dd1141be70b5966906919714dc504a24c65ddf
tree9270f9a0dd52ed9dbc196b253475fe43b0540642
parentf1288fd7293b91442ad7420394c252a252ecaa30
net: mscc: ocelot: treat 802.1ad tagged traffic as 802.1Q-untagged

I was revisiting the topic of 802.1ad treatment in the Ocelot switch [0]
and realized that not only is its basic VLAN classification pipeline
improper for offloading vlan_protocol 802.1ad bridges, but also improper
for offloading regular 802.1Q bridges already.

Namely, 802.1ad-tagged traffic should be treated as VLAN-untagged by
bridged ports, but this switch treats it as if it was 802.1Q-tagged with
the same VID as in the 802.1ad header. This is markedly different to
what the Linux bridge expects; see the "other_tpid()" function in
tools/testing/selftests/net/forwarding/bridge_vlan_aware.sh.

An idea came to me that the VCAP IS1 TCAM is more powerful than I'm
giving it credit for, and that it actually overwrites the classified VID
before the VLAN Table lookup takes place. In other words, it can be
used even to save a packet from being dropped on ingress due to VLAN
membership.

Add a sophisticated TCAM rule hardcoded into the driver to force the
switch to behave like a Linux bridge with vlan_filtering 1 vlan_protocol
802.1Q.

Regarding the lifetime of the filter: eventually the bridge will
disappear, and vlan_filtering on the port will be restored to 0 for
standalone mode. Then the filter will be deleted.

[0]: https://lore.kernel.org/netdev/20201009122947.nvhye4hvcha3tljh@skbuf/

Fixes: 7142529f1688 ("net: mscc: ocelot: add VLAN filtering")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/ethernet/mscc/ocelot.c
drivers/net/ethernet/mscc/ocelot_vcap.c
include/soc/mscc/ocelot_vcap.h