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

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:

quoted

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.