Linux Ethernet Bridging - Feb 2021 - [Bridge] [PATCH v2 net-next 04/11] net: bridge: offload initial and final port flags through switchdev

On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel
wrote:
> > > The reverse, during unlinking, would be to refuse unlinking if
the upper
> > > has uppers of its own. netdev_upper_dev_unlink() needs to learn
to
> > > return an error and callers such as team/bond need to learn to
handle
> > > it, but it seems patchable.
> >
> > Again, this was treated prior to my deletion in this series and not by
> > erroring out, I just really didn't think it through.
> >
> > So you're saying that if we impose that all switchdev drivers
restrict
> > the house of cards to be constructed from the bottom up, and
destructed
> > from the top down, then the notification of bridge port flags can stay
> > in the bridge layer?
>
> I actually don't think it's a good idea to have this in the bridge
in
> any case. I understand that it makes sense for some devices where
> learning, flooding, etc are port attributes, but in other devices these
> can be {port,vlan} attributes and then you need to take care of them
> when a vlan is added / deleted and not only when a port is removed from
> the bridge. So for such devices this really won't save anything. I
would
> thus leave it to the lower levels to decide.
Just for my understanding, how are per-{port,vlan} attributes such as
learning and flooding managed by the Linux bridge? How can I disable
flooding only in a certain VLAN?

On Thu, Feb 11, 2021 at 01:23:52AM +0200, Vladimir Oltean
wrote:
> On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > > The reverse, during unlinking, would be to refuse unlinking
if the upper
> > > > has uppers of its own. netdev_upper_dev_unlink() needs to
learn to
> > > > return an error and callers such as team/bond need to learn
to handle
> > > > it, but it seems patchable.
> > >
> > > Again, this was treated prior to my deletion in this series and
not by
> > > erroring out, I just really didn't think it through.
> > >
> > > So you're saying that if we impose that all switchdev drivers
restrict
> > > the house of cards to be constructed from the bottom up, and
destructed
> > > from the top down, then the notification of bridge port flags can
stay
> > > in the bridge layer?
> >
> > I actually don't think it's a good idea to have this in the
bridge in
> > any case. I understand that it makes sense for some devices where
> > learning, flooding, etc are port attributes, but in other devices
these
> > can be {port,vlan} attributes and then you need to take care of them
> > when a vlan is added / deleted and not only when a port is removed
from
> > the bridge. So for such devices this really won't save anything. I
would
> > thus leave it to the lower levels to decide.
> 
> Just for my understanding, how are per-{port,vlan} attributes such as
> learning and flooding managed by the Linux bridge? How can I disable
> flooding only in a certain VLAN?
You can't (currently). But it does not change the fact that in some
devices these are {port,vlan} attributes and we are talking here about
the interface towards these devices. Having these as {port,vlan}
attributes allows you to support use cases such as a port being enslaved
to a VLAN-aware bridge and its VLAN upper(s) enslaved to VLAN unaware
bridge(s). Obviously you need to ensure there is no conflict between the
VLANs used by the VLAN-aware bridge and the VLAN device(s).