Re: [RFC PATCH net-next 5/5] net: dsa: add explicit support for host bridge VLANs
flat view
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: 2022-02-13 11:34:50
On Sun, Feb 13, 2022 at 02:09:35AM +0100, Tobias Waldekranz wrote:
quoted
Therefore: - user ports contain only bridge port (forwarding) VLANs, and no refcounting is necessary - DSA ports contain both forwarding and host VLANs. Refcounting is necessary among these 2 types. - CPU ports contain only host VLANs. Refcounting is also necessary.This is pretty much true, though this does not take foreign interfaces into account. It would be great if the condifion could be refined to: The CPU port should be a member of all VLANs where either (a) the host is a member, or (b) at least one foreign interface is a member. I.e. in a situation like this: br0 / \ swp0 tap0 If br0 is not a member of VLAN X, but tap0 is, then the CPU port still needs to be a member of X. Otherwise the (software) bridge will never get a chance to software forward it over the tunnel.
This is a good observation and it can be done - just in the same way as we treat FDB entries on foregin interfaces as upstream-facing FDB entries in DSA. It also has implications upon the replay procedure, because if we want this to happen, we must replay all bridge VLAN groups, not just the port and the bridge VLANs. Again, similar to how br_switchdev_fdb_replay() replays the entire FDB. I can start working on these changes, but in parallel I'd also like an Ack from Nikolay, Roopa, Jiri, Ido on the approach from patches 1-3, since the whole refcounting thing depends on that. I think it's fairly safe, but maybe it breaks something I haven't thought of...