[PATCH net-next 0/2] net: bridge: allow user-space to add ext learned entries

[PATCH net-next 0/2] net: bridge: allow user-space to add ext learned entries

[Nikolay Aleksandrov]

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

[PATCH net-next 1/2] net: bridge: allow SW learn to take over HW fdb entries

[Nikolay Aleksandrov via Bridge]

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@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@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

[PATCH net-next 2/2] net: bridge: allow to add externally learned entries from user-space

[Nikolay Aleksandrov]

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

Re: [PATCH net-next 0/2] net: bridge: allow user-space to add ext learned entries

[Nikolay Aleksandrov via Bridge]

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.

Re: [PATCH net-next 1/2] net: bridge: allow SW learn to take over HW fdb entries

[Ido Schimmel]

On Thu, Mar 23, 2017 at 12:27:12PM +0200, Nikolay Aleksandrov wrote:
> 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@cumulusnetworks.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

Reviewed-by: Ido Schimmel <idosch@mellanox.com>

Re: [PATCH net-next 2/2] net: bridge: allow to add externally learned entries from user-space

[Ido Schimmel]

On Thu, Mar 23, 2017 at 12:27:13PM +0200, Nikolay Aleksandrov wrote:
> 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@cumulusnetworks.com>

Reviewed-by: Ido Schimmel <idosch@mellanox.com>

Re: [PATCH net-next 0/2] net: bridge: allow user-space to add ext learned entries

[Ido Schimmel]

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.

Re: [PATCH net-next 0/2] net: bridge: allow user-space to add ext learned entries

[David Miller]

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