Re: [RFC PATCH net-next 5/5] net: dsa: add explicit support for host bridge VLANs

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Sun, Feb 13, 2022 at 02:09:35AM +0100, Tobias Waldekranz wrote:
> > 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...