[PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries

[PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries

[Petr Machata]

Device drivers may generally need to keep in sync with bridge's FDB. In
particular, for its offload of tc mirror action where the mirrored-to
device is a gretap device, mlxsw needs to listen to a number of events.
SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be a natural notification to
listen to in order to keep up with FDB updates.

However, for removal of FDB entries added due to device activity (as
opposed to explicit addition through "bridge fdb add" or similar), there
are no notifications.

Thus in patch #1, add the "added_by_user" field to switchdev
notifications sent for FDB activity. Adapt drivers to ignore activity on
non-user-added entries, to maintain the current behavior. Specifically
in case of mlxsw, allow mlxsw_sp_span_respin() call for any and all FDB
updates.

In patch #2, change the bridge driver to actually emit notifications for
these FDB entries. Take care not to send notification for bridge
updates that itself originate in SWITCHDEV_FDB_*_TO_BRIDGE events.

Petr Machata (2):
  switchdev: Add fdb.added_by_user to switchdev notifications
  net: bridge: Notify about !added_by_user FDB entries

 .../ethernet/mellanox/mlxsw/spectrum_switchdev.c   |  4 +++
 drivers/net/ethernet/rocker/rocker_main.c          |  2 ++
 include/net/switchdev.h                            |  1 +
 net/bridge/br.c                                    |  4 +--
 net/bridge/br_fdb.c                                | 40 +++++++++++++++-------
 net/bridge/br_private.h                            |  4 +--
 net/bridge/br_switchdev.c                          | 12 ++++---
 net/dsa/slave.c                                    |  5 ++-
 8 files changed, 50 insertions(+), 22 deletions(-)

-- 
2.4.11

[PATCH net-next 1/2] switchdev: Add fdb.added_by_user to switchdev notifications

[Petr Machata]

The following patch enables sending notifications also for events on FDB
entries that weren't added by the user. Give the drivers the information
necessary to distinguish between the two origins of FDB entries.

To maintain the current behavior, have switchdev-implementing drivers
bail out on notifications about non-user-added FDB entries. In case of
mlxsw driver, allow a call to mlxsw_sp_span_respin() so that SPAN over
bridge catches up with the changed FDB.

Signed-off-by: Petr Machata <petrm@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c |  4 ++++
 drivers/net/ethernet/rocker/rocker_main.c                |  2 ++
 include/net/switchdev.h                                  |  1 +
 net/bridge/br_switchdev.c                                | 10 +++++++---
 net/dsa/slave.c                                          |  5 ++++-
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 1af99fe..3973d90 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -2270,6 +2270,8 @@ static void mlxsw_sp_switchdev_event_work(struct work_struct *work)
 	switch (switchdev_work->event) {
 	case SWITCHDEV_FDB_ADD_TO_DEVICE:
 		fdb_info = &switchdev_work->fdb_info;
+		if (!fdb_info->added_by_user)
+			break;
 		err = mlxsw_sp_port_fdb_set(mlxsw_sp_port, fdb_info, true);
 		if (err)
 			break;
@@ -2279,6 +2281,8 @@ static void mlxsw_sp_switchdev_event_work(struct work_struct *work)
 		break;
 	case SWITCHDEV_FDB_DEL_TO_DEVICE:
 		fdb_info = &switchdev_work->fdb_info;
+		if (!fdb_info->added_by_user)
+			break;
 		mlxsw_sp_port_fdb_set(mlxsw_sp_port, fdb_info, false);
 		break;
 	case SWITCHDEV_FDB_ADD_TO_BRIDGE: /* fall through */
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 056cb60..152d694 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -2783,6 +2783,8 @@ static int rocker_switchdev_event(struct notifier_block *unused,
 	switch (event) {
 	case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
 	case SWITCHDEV_FDB_DEL_TO_DEVICE:
+		if (!fdb_info->added_by_user)
+			break;
 		memcpy(&switchdev_work->fdb_info, ptr,
 		       sizeof(switchdev_work->fdb_info));
 		switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 39bc855..d574ce6 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -155,6 +155,7 @@ struct switchdev_notifier_fdb_info {
 	struct switchdev_notifier_info info; /* must be first */
 	const unsigned char *addr;
 	u16 vid;
+	bool added_by_user;
 };
 
 static inline struct net_device *
diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
index ee775f4..71a03c4 100644
--- a/net/bridge/br_switchdev.c
+++ b/net/bridge/br_switchdev.c
@@ -102,13 +102,15 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
 
 static void
 br_switchdev_fdb_call_notifiers(bool adding, const unsigned char *mac,
-				u16 vid, struct net_device *dev)
+				u16 vid, struct net_device *dev,
+				bool added_by_user)
 {
 	struct switchdev_notifier_fdb_info info;
 	unsigned long notifier_type;
 
 	info.addr = mac;
 	info.vid = vid;
+	info.added_by_user = added_by_user;
 	notifier_type = adding ? SWITCHDEV_FDB_ADD_TO_DEVICE : SWITCHDEV_FDB_DEL_TO_DEVICE;
 	call_switchdev_notifiers(notifier_type, dev, &info.info);
 }
@@ -123,12 +125,14 @@ br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb, int type)
 	case RTM_DELNEIGH:
 		br_switchdev_fdb_call_notifiers(false, fdb->key.addr.addr,
 						fdb->key.vlan_id,
-						fdb->dst->dev);
+						fdb->dst->dev,
+						fdb->added_by_user);
 		break;
 	case RTM_NEWNEIGH:
 		br_switchdev_fdb_call_notifiers(true, fdb->key.addr.addr,
 						fdb->key.vlan_id,
-						fdb->dst->dev);
+						fdb->dst->dev,
+						fdb->added_by_user);
 		break;
 	}
 }
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index f3fb3a0..c287f1e 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1441,6 +1441,7 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
 				     unsigned long event, void *ptr)
 {
 	struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
+	struct switchdev_notifier_fdb_info *fdb_info = ptr;
 	struct dsa_switchdev_event_work *switchdev_work;
 
 	if (!dsa_slave_dev_check(dev))
@@ -1458,8 +1459,10 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
 	switch (event) {
 	case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
 	case SWITCHDEV_FDB_DEL_TO_DEVICE:
+		if (!fdb_info->added_by_user)
+			break;
 		if (dsa_slave_switchdev_fdb_work_init(switchdev_work,
-						      ptr))
+						      fdb_info))
 			goto err_fdb_work_init;
 		dev_hold(dev);
 		break;
-- 
2.4.11

[PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB entries

[Petr Machata]

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 <petrm@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(-)

diff --git a/net/bridge/br.c b/net/bridge/br.c
index 671d13c..c6b033e 100644
--- a/net/bridge/br.c
+++ b/net/bridge/br.c
@@ -141,7 +141,7 @@ static int br_switchdev_event(struct notifier_block *unused,
 	case SWITCHDEV_FDB_ADD_TO_BRIDGE:
 		fdb_info = ptr;
 		err = br_fdb_external_learn_add(br, p, fdb_info->addr,
-						fdb_info->vid);
+						fdb_info->vid, false);
 		if (err) {
 			err = notifier_from_errno(err);
 			break;
@@ -152,7 +152,7 @@ static int br_switchdev_event(struct notifier_block *unused,
 	case SWITCHDEV_FDB_DEL_TO_BRIDGE:
 		fdb_info = ptr;
 		err = br_fdb_external_learn_del(br, p, fdb_info->addr,
-						fdb_info->vid);
+						fdb_info->vid, false);
 		if (err)
 			err = notifier_from_errno(err);
 		break;
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index a1c409c..272d1a2 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -39,8 +39,8 @@ static const struct rhashtable_params br_fdb_rht_params = {
 static struct kmem_cache *br_fdb_cache __read_mostly;
 static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
 		      const unsigned char *addr, u16 vid);
-static void fdb_notify(struct net_bridge *br,
-		       const struct net_bridge_fdb_entry *, int);
+static void __fdb_notify(struct net_bridge *br,
+			 const struct net_bridge_fdb_entry *, int, bool);
 
 int __init br_fdb_init(void)
 {
@@ -195,7 +195,8 @@ static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr)
 	}
 }
 
-static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
+static void __fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f,
+			 bool notify)
 {
 	trace_fdb_delete(br, f);
 
@@ -205,10 +206,15 @@ static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
 	hlist_del_init_rcu(&f->fdb_node);
 	rhashtable_remove_fast(&br->fdb_hash_tbl, &f->rhnode,
 			       br_fdb_rht_params);
-	fdb_notify(br, f, RTM_DELNEIGH);
+	__fdb_notify(br, f, RTM_DELNEIGH, notify);
 	call_rcu(&f->rcu, fdb_rcu_free);
 }
 
+static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
+{
+	__fdb_delete(br, f, true);
+}
+
 /* Delete a local entry if no other port had the same address. */
 static void fdb_delete_local(struct net_bridge *br,
 			     const struct net_bridge_port *p,
@@ -514,6 +520,12 @@ static struct net_bridge_fdb_entry *fdb_create(struct net_bridge *br,
 	return fdb;
 }
 
+static void fdb_notify(struct net_bridge *br,
+		       const struct net_bridge_fdb_entry *fdb, int type)
+{
+	__fdb_notify(br, fdb, type, true);
+}
+
 static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
 		  const unsigned char *addr, u16 vid)
 {
@@ -686,14 +698,16 @@ static inline size_t fdb_nlmsg_size(void)
 		+ nla_total_size(sizeof(struct nda_cacheinfo));
 }
 
-static void fdb_notify(struct net_bridge *br,
-		       const struct net_bridge_fdb_entry *fdb, int type)
+static void __fdb_notify(struct net_bridge *br,
+			 const struct net_bridge_fdb_entry *fdb, int type,
+			 bool notify)
 {
 	struct net *net = dev_net(br->dev);
 	struct sk_buff *skb;
 	int err = -ENOBUFS;
 
-	br_switchdev_fdb_notify(fdb, type);
+	if (notify)
+		br_switchdev_fdb_notify(fdb, type);
 
 	skb = nlmsg_new(fdb_nlmsg_size(), GFP_ATOMIC);
 	if (skb == NULL)
@@ -856,7 +870,7 @@ static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge *br,
 		rcu_read_unlock();
 		local_bh_enable();
 	} else if (ndm->ndm_flags & NTF_EXT_LEARNED) {
-		err = br_fdb_external_learn_add(br, p, addr, vid);
+		err = br_fdb_external_learn_add(br, p, addr, vid, true);
 	} else {
 		spin_lock_bh(&br->hash_lock);
 		err = fdb_add_entry(br, p, addr, ndm->ndm_state,
@@ -1065,7 +1079,7 @@ void br_fdb_unsync_static(struct net_bridge *br, struct net_bridge_port *p)
 }
 
 int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
-			      const unsigned char *addr, u16 vid)
+			      const unsigned char *addr, u16 vid, bool notify)
 {
 	struct net_bridge_fdb_entry *fdb;
 	bool modified = false;
@@ -1083,7 +1097,7 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
 			goto err_unlock;
 		}
 		fdb->added_by_external_learn = 1;
-		fdb_notify(br, fdb, RTM_NEWNEIGH);
+		__fdb_notify(br, fdb, RTM_NEWNEIGH, notify);
 	} else {
 		fdb->updated = jiffies;
 
@@ -1102,7 +1116,7 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
 		}
 
 		if (modified)
-			fdb_notify(br, fdb, RTM_NEWNEIGH);
+			__fdb_notify(br, fdb, RTM_NEWNEIGH, notify);
 	}
 
 err_unlock:
@@ -1112,7 +1126,7 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
 }
 
 int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p,
-			      const unsigned char *addr, u16 vid)
+			      const unsigned char *addr, u16 vid, bool notify)
 {
 	struct net_bridge_fdb_entry *fdb;
 	int err = 0;
@@ -1121,7 +1135,7 @@ int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p,
 
 	fdb = br_fdb_find(br, addr, vid);
 	if (fdb && fdb->added_by_external_learn)
-		fdb_delete(br, fdb);
+		__fdb_delete(br, fdb, notify);
 	else
 		err = -ENOENT;
 
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 1a50931..b9ab4e5 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -553,9 +553,9 @@ int br_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
 int br_fdb_sync_static(struct net_bridge *br, struct net_bridge_port *p);
 void br_fdb_unsync_static(struct net_bridge *br, struct net_bridge_port *p);
 int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
-			      const unsigned char *addr, u16 vid);
+			      const unsigned char *addr, u16 vid, bool notify);
 int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p,
-			      const unsigned char *addr, u16 vid);
+			      const unsigned char *addr, u16 vid, bool notify);
 void br_fdb_offloaded_set(struct net_bridge *br, struct net_bridge_port *p,
 			  const unsigned char *addr, u16 vid);
 
diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
index 71a03c4..35474d4 100644
--- a/net/bridge/br_switchdev.c
+++ b/net/bridge/br_switchdev.c
@@ -118,7 +118,7 @@ br_switchdev_fdb_call_notifiers(bool adding, const unsigned char *mac,
 void
 br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb, int type)
 {
-	if (!fdb->added_by_user || !fdb->dst)
+	if (!fdb->dst)
 		return;
 
 	switch (type) {
-- 
2.4.11

Re: [PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB entries

[Nikolay Aleksandrov]

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 <petrm@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.

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. :-)

Also please add the bridge maintainers to the CC list.

Thanks,
  Nik

Re: [Bridge] [PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB entries

[Nikolay Aleksandrov]

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 <petrm@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.

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. :-)

Also please add the bridge maintainers to the CC list.

Thanks,
  Nik

Re: [PATCH net-next 1/2] switchdev: Add fdb.added_by_user to switchdev notifications

[Nikolay Aleksandrov]

On 01/05/18 20:04, Petr Machata wrote:
> The following patch enables sending notifications also for events on FDB
> entries that weren't added by the user. Give the drivers the information
> necessary to distinguish between the two origins of FDB entries.
> 
> To maintain the current behavior, have switchdev-implementing drivers
> bail out on notifications about non-user-added FDB entries. In case of
> mlxsw driver, allow a call to mlxsw_sp_span_respin() so that SPAN over
> bridge catches up with the changed FDB.
> 
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> ---
>   drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c |  4 ++++
>   drivers/net/ethernet/rocker/rocker_main.c                |  2 ++
>   include/net/switchdev.h                                  |  1 +
>   net/bridge/br_switchdev.c                                | 10 +++++++---
>   net/dsa/slave.c                                          |  5 ++++-
>   5 files changed, 18 insertions(+), 4 deletions(-)
> 

Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

Re: [PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries

[Andrew Lunn]

On Tue, May 01, 2018 at 07:04:19PM +0200, Petr Machata wrote:
> Device drivers may generally need to keep in sync with bridge's FDB. In
> particular, for its offload of tc mirror action where the mirrored-to
> device is a gretap device, mlxsw needs to listen to a number of events.
> SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be a natural notification to
> listen to in order to keep up with FDB updates.
> 
> However, for removal of FDB entries added due to device activity (as
> opposed to explicit addition through "bridge fdb add" or similar), there
> are no notifications.

Hi Petr

Could you explain this some more. Why is mlxsw special in that it
needs this, but other drivers don't. The b53 driver supports tc
mirror, for example.

    Andrew

Re: [PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries

[Petr Machata]

Andrew Lunn <andrew@lunn.ch> writes:

> On Tue, May 01, 2018 at 07:04:19PM +0200, Petr Machata wrote:
>> Device drivers may generally need to keep in sync with bridge's FDB. In
>> particular, for its offload of tc mirror action where the mirrored-to
>> device is a gretap device, mlxsw needs to listen to a number of events.
>> SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be a natural notification to
>> listen to in order to keep up with FDB updates.
>> 
>> However, for removal of FDB entries added due to device activity (as
>> opposed to explicit addition through "bridge fdb add" or similar), there
>> are no notifications.
>
> Could you explain this some more. Why is mlxsw special in that it
> needs this, but other drivers don't. The b53 driver supports tc
> mirror, for example.

mlxsw supports offload of tc mirror to a gretap netdevice to achieve
mirroring of traffic encapsulated in GRE. However, the device doesn't do
routing and switching on the encapsulated mirrored packets. You need to
configure exact parameters--L2 and L3 addresses, VLAN tagging if any,
etc., and a single front panel port to forward to.

To offload this, the driver sort of plays the game of networking stack.
Finds the underlay route, finds the neighbor to get the Ethernet address
(and possibly kick starts ARP resolution), and if the target netdevice
is a bridge, queries the FDB to find the one port to forward to (and
bails out if it needs to flood, we can't really offload that).

Now any time anything in that pipeline changes, the stuff after that
point needs to be redone, and the offloading decision (if and how) may
change.

So if an administrator decides to remove an FDB entry by hand, the
driver should notice this and reflect the intent by removing offloads
that depend on existence of that FDB entry. But since there's no event,
mlxsw doesn't notice this outright. It does notice later, because of an
unrelated event--e.g. from a neighbor, a FIB notification, whatever it
happens to be. That discrepancy is what I'm trying to fix.

Thanks,
Petr

Re: [PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB entries

[Petr Machata]

Nikolay Aleksandrov <nikolay@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 <petrm@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.

bridge@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

Re: [Bridge] [PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB entries

[Petr Machata]

Nikolay Aleksandrov <nikolay@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 <petrm@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.

bridge@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