Re: Timing of host-joined bridge multicast groups with switchdev

Ido Schimmel
2021-02-23T19:30:39Z

On Tue, Feb 23, 2021 at 08:02:36PM +0200, Vladimir Oltean wrote:
> On Tue, Feb 23, 2021 at 07:56:22PM +0200, Ido Schimmel wrote:
> > For route offload you get a dump of all the existing routes when you
> > register your notifier. It's a bit different with bridge because you
> > don't care about existing bridges when you just initialize your driver.
> >
> > We had a similar issue with VXLAN because its FDB can be populated and
> > only then attached to a bridge that you offload. Check
> > vxlan_fdb_replay(). Probably need to introduce something similar for
> > FDB/MDB entries.
>
> So you would be in favor of a driver-voluntary 'pull' type of approach
> at bridge join, instead of the bridge 'pushing' the addresses?
>
> That's all fine, except when we'll have more than 3 switchdev drivers,
> how do we expect to manage all this complexity duplicated in many places
> in the kernel, instead of having it in a central place? Are there corner
> cases I'm missing which make the 'push' approach impractical?

Not sure. It needs to be scheduled when the driver is ready to handle
it. In br_add_if() after netdev_master_upper_dev_link() is probably a
good place.

It also needs to be done once and not every time another port joins the
bridge. This can be done using the port's parent ID, similar to what we
are already doing with the offload forward mark in
nbp_switchdev_mark_set().

But I'm not sure how we replay it only for a single notifier block. I'm
not familiar with setups where you have more than one listener let alone
more than one that is interested in notifications from a specific
bridge, so maybe it is OK to just replay it for all the listeners. But I
would prefer to avoid it if we can.