On Mon, 11 Apr 2022 12:22:24 -0700 Roopa Prabhu wrote: > >> I thought about that option, but I didn't like overloading delneigh like > >> that. > >> del currently requires a mac address and we need to either signal the > >> device supports> a null mac, or we should push that verification to > >> ndo_fdb_del users. Also we'll have > > that's the only thing, overloading delneigh with a flush-behaviour > > (multi-del or whatever) > > would require to push the mac check to ndo_fdb_del implementers > > > > I don't mind going that road if others agree that we should do it through > > delneigh > > + a bit/option to signal flush, instead of a new rtm type. > > > >> attributes which are flush-specific and will work only when flushing as > >> opposed to when > >> deleting a specific mac, so handling them in the different cases can > >> become a pain. > > scratch the specific attributes, those can be adapted for both cases > > > >> MDBs will need DELMDB to be modified in a similar way. > >> > >> IMO a separate flush op is cleaner, but I don't have a strong preference. > >> This can very easily be adapted to delneigh with just a bit more > >> mechanical changes > >> if the mac check is pushed to the ndo implementers. > >> > >> FLUSHNEIGH can easily work for neighs, just need another address family > >> rtnl_register > >> that implements it, the new ndo is just for PF_BRIDGE. :) > > all great points. My only reason to explore RTM_DELNEIGH is to see if we > can find a recipe to support similar bulk deletes of other objects > handled via rtm msgs in the future. Plus, it allows you to maintain > symmetry between flush requests and object delete notification msg types. > > Lets see if there are other opinions.
I'd vote for reusing RTM_DELNEIGH, but that's purely based on intuition, I don't know this code. I'd also lean towards core creating struct net_bridge_fdb_flush_desc rather than piping raw netlink attrs thru. Lastly feels like fdb ops should find a new home rather than ndos, but that's largely unrelated..
