Thread (20 messages) 20 messages, 4 authors, 2022-02-14

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...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help