net: dsa: felix: dynamically determine tag_8021q CPU port for traps
Ocelot switches support a single active CPU port at a time (at least as a trapping destination, i.e. for control traffic). This is true regardless of whether we are using the native copy-to-CPU-port-module functionality, or a redirect action towards the software-defined tag_8021q CPU port. Currently we assume that the trapping destination in tag_8021q mode is the first CPU port, yet in the future we may want to migrate the user ports to the second CPU port. For that to work, we need to make sure that the tag_8021q trapping destination is a CPU port that is active, i.e. is used by at least some user port on which the trap was added. Otherwise, we may end up redirecting the traffic to a CPU port which isn't even up. Note that due to the current design where we simply choose the CPU port of the first port from the trap's ingress port mask, it may be that a CPU port absorbes control traffic from user ports which aren't affine to it as per user space's request. This isn't ideal, but is the lesser of two evils. Following the user-configured affinity for traps would mean that we can no longer reuse a single TCAM entry for multiple traps, which is what we actually do for e.g. PTP. Either we duplicate and deduplicate TCAM entries on the fly when user-to-CPU-port mappings change (which is unnecessarily complicated), or we redirect trapped traffic to all tag_8021q CPU ports if multiple such ports are in use. The latter would have actually been nice, if it actually worked, but it doesn't, since a OCELOT_MASK_MODE_REDIRECT action towards multiple ports would not take PGID_SRC into consideration, and it would just duplicate the packet towards each (CPU) port, leading to duplicates in software. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Showing
Please register or sign in to comment