Nikolay Aleksandrov <niko...@cumulusnetworks.com> writes: > On 01/05/18 20:04, Petr Machata wrote: >> Do not automatically bail out on sending notifications about activity on >> non-user-added FDB entries. Instead, notify about this activity except >> for cases where the activity itself originates in a notification, to >> avoid sending duplicate notifications. >> >> Signed-off-by: Petr Machata <pe...@mellanox.com> >> --- >> net/bridge/br.c | 4 ++-- >> net/bridge/br_fdb.c | 40 +++++++++++++++++++++++++++------------- >> net/bridge/br_private.h | 4 ++-- >> net/bridge/br_switchdev.c | 2 +- >> 4 files changed, 32 insertions(+), 18 deletions(-) >> > > Hi Petr, > We already have 7 different fdb delete functions, I'm really not a fan of > adding yet another one for such trivial change. > Why don't you just add the new notify parameter to the already existing > fdb_delete() ? (actually about the name see below) > IMO it's confusing - if one wants a notification then use fdb_delete() or > __fdb_delete(true) > vs __fdb_delete(false) if a notification is not required. I think simply > having the last > parameter everywhere for fdb_delete() shows the intention clearer and avoids > another > fdb delete function.
All right--this is how I had it written actually, but then decided to do this wrapping, because so many of the calls end up being true. I'll send a v2 with just the extra argument. > Another point, the notify parameter has a confusing name in this context > because > you're controlling the switchdev notifications not the rtnetlink ones. I'd > suggest > changing the name to something more descriptive like swdev_notify, otherwise > you > could get the funny end result of calling __fdb_notify() with notify == false > which > to me means don't notify. :-) OK, swdev_notify it will be. > Also please add the bridge maintainers to the CC list. bri...@lists.linux-foundation.org? I saw it's a moderated list and for some reason that made me think it's not meant for patch postings. I'll add them the next time. Thanks, Petr
