From d27656d02d85078c63f060fca9c5d99794791a75 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Fri, 25 Feb 2022 11:22:18 +0200 Subject: [PATCH] docs: net: dsa: sja1105: document limitations of tc-flower rule VLAN awareness After change "net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging", tag_8021q enforces two different pvids on a port, depending on whether it is standalone or in a VLAN-unaware bridge. Up until now, there was a single pvid, represented by dsa_tag_8021q_rx_vid(), and that was used as the VLAN for VLAN-unaware virtual link rules, regardless of whether the port was bridged or standalone. To keep VLAN-unaware virtual links working, we need to follow whether the port is in a bridge or not, and update the VLAN ID from those rules. In fact we can't fully do that. Depending on whether the switch is VLAN-aware or not, we can accept Virtual Link rules with just the MAC DA, or with a MAC DA and a VID. So we already deny changes to the VLAN awareness of the switch. But the VLAN awareness may also change as a result of joining or leaving a bridge. One might say we could just allow the following: a port may leave a VLAN-unaware bridge while it has VLAN-unaware VL (tc-flower) rules, and the driver will update those with the new tag_8021q pvid for standalone mode, but the driver won't accept joining a bridge at all while VL rules were installed in standalone mode. This is sort of a compromise made because leaving a bridge is an operation that cannot be vetoed. But this sort of setup change is not fully supported, either: as mentioned, VLAN filtering changes can also be triggered by leaving a bridge, therefore, the existing veto we have in place for turning VLAN filtering off with VLAN-aware VL rules active still isn't fully effective. I really don't know how to deal with this in a way that produces predictable behavior for user space. Since at the moment, keeping this feature fully functional on constellation changes (not changing the tag_8021q port pvid when joining a bridge) is blocking progress for the DSA FDB isolation, I'd rather document it as a (potentially temporary) limitation and go on without it. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller --- Documentation/networking/dsa/sja1105.rst | 27 ++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index 29b1bae0cf00..e0219c1452ab 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -293,6 +293,33 @@ of dropped frames, which is a sum of frames dropped due to timing violations, lack of destination ports and MTU enforcement checks). Byte-level counters are not available. +Limitations +=========== + +The SJA1105 switch family always performs VLAN processing. When configured as +VLAN-unaware, frames carry a different VLAN tag internally, depending on +whether the port is standalone or under a VLAN-unaware bridge. + +The virtual link keys are always fixed at {MAC DA, VLAN ID, VLAN PCP}, but the +driver asks for the VLAN ID and VLAN PCP when the port is under a VLAN-aware +bridge. Otherwise, it fills in the VLAN ID and PCP automatically, based on +whether the port is standalone or in a VLAN-unaware bridge, and accepts only +"VLAN-unaware" tc-flower keys (MAC DA). + +The existing tc-flower keys that are offloaded using virtual links are no +longer operational after one of the following happens: + +- port was standalone and joins a bridge (VLAN-aware or VLAN-unaware) +- port is part of a bridge whose VLAN awareness state changes +- port was part of a bridge and becomes standalone +- port was standalone, but another port joins a VLAN-aware bridge and this + changes the global VLAN awareness state of the bridge + +The driver cannot veto all these operations, and it cannot update/remove the +existing tc-flower filters either. So for proper operation, the tc-flower +filters should be installed only after the forwarding configuration of the port +has been made, and removed by user space before making any changes to it. + Device Tree bindings and board design =====================================