Linux Ethernet Bridging - Mar 2017 - [Bridge] [PATCH net-next 1/2] net: bridge: allow SW learn to take over HW fdb entries

Hi,
This set adds the ability to add externally learned entries from
user-space. For symmetry and proper function we need to allow SW entries
to take over HW learned ones (similar to how HW can take over SW entries
currently) which is needed for our use case (evpn) where we have pure SW
ports and HW ports mixed in a single bridge. This does not play well with
switchdev devices currently because there's no feedback when the entry is
taken over, but this case has never worked anyway and feedback can be
easily added when needed.
Patch 02 simply allows to use NTF_EXT_LEARNED from user-space, we already
have Quagga patches that make use of this functionality.

Thanks,
 Nik

Nikolay Aleksandrov (2):
  net: bridge: allow SW learn to take over HW fdb entries
  net: bridge: allow to add externally learned entries from user-space

 net/bridge/br_fdb.c | 5 +++++
 1 file changed, 5 insertions(+)

-- 
2.1.4

Allow to take over an entry which was previously learned via HW when it
shows up from a SW port. This is analogous to how HW takes over SW learned
entries already.

Suggested-by: Roopa Prabhu <roopa at cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
---
 net/bridge/br_fdb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 4f598dc2d916..e4c8adf517ea 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -594,6 +594,9 @@ void br_fdb_update(struct net_bridge *br, struct
net_bridge_port *source,
 				fdb->updated = now;
 			if (unlikely(added_by_user))
 				fdb->added_by_user = 1;
+			/* Take over HW learned entry */
+			if (unlikely(fdb->added_by_external_learn))
+				fdb->added_by_external_learn = 0;
 			if (unlikely(fdb_modified))
 				fdb_notify(br, fdb, RTM_NEWNEIGH);
 		}
-- 
2.1.4

The NTF_EXT_LEARNED flag was added for switchdev and externally learned
entries, but it can also be used for entries learned via a software
in user-space which requires dynamic entries that do not expire.
One such case that we have is with quagga and evpn which need dynamic
entries but also require to age them themselves.

Signed-off-by: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
---
 net/bridge/br_fdb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index e4c8adf517ea..7e5902e69f85 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -857,6 +857,8 @@ static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge
*br,
 		br_fdb_update(br, p, addr, vid, true);
 		rcu_read_unlock();
 		local_bh_enable();
+	} else if (ndm->ndm_flags & NTF_EXT_LEARNED) {
+		err = br_fdb_external_learn_add(br, p, addr, vid);
 	} else {
 		spin_lock_bh(&br->hash_lock);
 		err = fdb_add_entry(br, p, addr, ndm->ndm_state,
-- 
2.1.4

On 23/03/17 12:27, Nikolay Aleksandrov wrote:
> Hi,
> This set adds the ability to add externally learned entries from
> user-space. For symmetry and proper function we need to allow SW entries
> to take over HW learned ones (similar to how HW can take over SW entries
> currently) which is needed for our use case (evpn) where we have pure SW
> ports and HW ports mixed in a single bridge. This does not play well with
> switchdev devices currently because there's no feedback when the entry
is
> taken over, but this case has never worked anyway and feedback can be
> easily added when needed.
> Patch 02 simply allows to use NTF_EXT_LEARNED from user-space, we already
> have Quagga patches that make use of this functionality.
> 
> Thanks,
>  Nik
> 
A minor clarification: the functionality is necessary so the aging can
be handled by user-space software (e.g. quagga w/ evpn) when the entry
has been learned externally, but can also dynamically move to a local
bridge port and then the aging should be done by the bridge.

On Thu, Mar 23, 2017 at 12:27:11PM +0200, Nikolay Aleksandrov
wrote:
> Hi,
> This set adds the ability to add externally learned entries from
> user-space. For symmetry and proper function we need to allow SW entries
> to take over HW learned ones (similar to how HW can take over SW entries
> currently) which is needed for our use case (evpn) where we have pure SW
> ports and HW ports mixed in a single bridge. This does not play well with
> switchdev devices currently because there's no feedback when the entry
is
> taken over, but this case has never worked anyway and feedback can be
> easily added when needed.
Yea, correct. I think we should handle FDB offload in a similar fashion
to route offload. FDBs aren't only of interest to the port to which they
point, but also to the other ports in the bridge. In your example use
case we would actually need to forward to the CPU packets that hit FDB
entries pointing to the SW ports. What would currently happen is that we
would simply flood such packets via the HW ports.

From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
Date: Thu, 23 Mar 2017 12:27:11 +0200
> This set adds the ability to add externally learned entries from
> user-space. For symmetry and proper function we need to allow SW entries
> to take over HW learned ones (similar to how HW can take over SW entries
> currently) which is needed for our use case (evpn) where we have pure SW
> ports and HW ports mixed in a single bridge. This does not play well with
> switchdev devices currently because there's no feedback when the entry
is
> taken over, but this case has never worked anyway and feedback can be
> easily added when needed.
> Patch 02 simply allows to use NTF_EXT_LEARNED from user-space, we already
> have Quagga patches that make use of this functionality.
Series applied.