Hi Petr, On Wed, Jul 19, 2023 at 01:01:17PM +0200, Petr Machata wrote: > When a front panel joins a bridge via another netdevice (typically a LAG), > the driver needs to learn about the objects configured on the bridge port. > When the bridge port is offloaded by the driver for the first time, this > can be achieved by passing a notifier to switchdev_bridge_port_offload(). > The notifier is then invoked for the individual objects (such as VLANs) > configured on the bridge, and can look for the interesting ones. > > Calling switchdev_bridge_port_offload() when the second port joins the > bridge lower is unnecessary, but the replay is still needed. To that end, > add a new function, switchdev_bridge_port_replay(), which does only the > replay part of the _offload() function in exactly the same way as that > function. > > Cc: Jiri Pirko <jiri@xxxxxxxxxxx> > Cc: Ivan Vecera <ivecera@xxxxxxxxxx> > Cc: Roopa Prabhu <roopa@xxxxxxxxxx> > Cc: Nikolay Aleksandrov <razor@xxxxxxxxxxxxx> > Cc: bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx > Signed-off-by: Petr Machata <petrm@xxxxxxxxxx> > Reviewed-by: Danielle Ratson <danieller@xxxxxxxxxx> > --- I just noticed this commit in the kernel, and the commit message did not really convince me. As unnecessary as the second switchdev_bridge_port_offload() call may be, it does not hurt either, because it just bumps p->offload_count in the bridge. And with just this justification, adding a new function to the switchdev API is equally unnecessary. Even worse, switchdev_bridge_port_replay() is a partial misnomer, and will become a complete misnomer soon. Out of 3 object classes (FDB, MDB and VLAN), FDB and VLAN are not actually replayed just for the given bridge port given as argument, but for all ports of the bridge. And Tobias wants to change things so that the same will happen for MDB too. https://lore.kernel.org/netdev/87bk927bxl.fsf@xxxxxxxxxxxxxx/ Can mlxsw not use the same replay code path as DSA, through the _offload() and _unoffload() entry points?
