On Fri, Feb 26, 2021 at 01:23:23PM +0100, Tobias Waldekranz wrote: > If VLAN filtering is enabled, we would also have to replay that. Port > attributes also, right? > > I like the pull model, because it saves the bridge from doing lots of > dumpster diving. However, should there be a single `bridge_replay` that > takes care of everything? > > Rather than this kit-car approarch which outsources ordering etc to each > switchdev driver, you issue a single call saying: "bring me up to > speed". It seems right that that knowledge should reside in the bridge > since it was the one who sent the original events that are being > replayed.
Yes, in the non-RFC version I'm going to do that. I'm also thinking I could just pass the blocking and atomic switchdev notifiers as an argument to the switchdev_bridge_port_offload_notify() call, such that the drivers need to do one thing and one thing only. For the purposes of this RFC I just wanted to have something that works for address filtering.
