Re: [PATCH v3] bridge: netlink: check vlan_default_pvid range

on looks good to me, with the above stylistic issue fixed feel free to add my: Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> Thanks!

Re: [PATCH] bridge: netlink: check vlan_default_pvid range

On 5/15/17 4:29 PM, Nikolay Aleksandrov wrote: On 5/15/17 4:21 PM, Tobias Jungel wrote: Thanks Sabrina and Nik. On Mon, 2017-05-15 at 14:01 +0200, Sabrina Dubroca wrote: Hi Tobias, 2017-05-15, 13:08:19 +0200, Tobias Jungel wrote: Currently it is allowed to set the default pvid of a bridge

Re: [PATCH] bridge: netlink: check vlan_default_pvid range

On 5/15/17 4:21 PM, Tobias Jungel wrote: Thanks Sabrina and Nik. On Mon, 2017-05-15 at 14:01 +0200, Sabrina Dubroca wrote: Hi Tobias, 2017-05-15, 13:08:19 +0200, Tobias Jungel wrote: Currently it is allowed to set the default pvid of a bridge to a value above VLAN_VID_MASK (0xfff). This

Re: [PATCH] bridge: netlink: check vlan_default_pvid range

On 5/15/17 2:08 PM, Tobias Jungel wrote: Currently it is allowed to set the default pvid of a bridge to a value above VLAN_VID_MASK (0xfff). This patch checks the passed pvid and disables the pvid in case it is out of bounds. Reproduce by calling: [root@test ~]# ip l a type bridge [root@test

Re: [PATCH net] bridge: netlink: account for IFLA_BRPORT_{B,M}CAST_FLOOD size and policy

On 05/05/17 17:36, Tobias Klauser wrote: > The attribute sizes for IFLA_BRPORT_MCAST_FLOOD and > IFLA_BRPORT_BCAST_FLOOD weren't accounted for in br_port_info_size() > when they were added. Do so now and also add the corresponding policy > entries: > > Cc: Nikolay

Re: [PATCH net-next v3] net: bridge: Fix improper taking over HW learned FDB

roaming. > > Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb > entries") > Signed-off-by: Ido Schimmel <ido...@mellanox.com> > Signed-off-by: Arkadi Sharashevsky <arka...@mellanox.com> > Cc: Nikolay Aleksandrov <niko...@cumu

Re: [PATCH net-next] net: bridge: Fix improper taking over HW learned FDB

roaming. > > Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb > entries") > Signed-off-by: Ido Schimmel <ido...@mellanox.com> > Signed-off-by: Arkadi Sharashevsky <arka...@mellanox.com> > Cc: Nikolay Aleksandrov <niko...@cumulusn

Re: [PATCH net-next] net: bridge: Fix improper taking over HW learned FDB

roaming. > > Fixes: 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb > entries") > Signed-off-by: Ido Schimmel <ido...@mellanox.com> > Signed-off-by: Arkadi Sharashevsky <arka...@mellanox.com> > Cc: Nikolay Aleksandrov <niko...@cumulusn

Re: [PATCH v2 net-next] bridge: add per-port broadcast flood flag

cast is a special case of multicast, this may also need to > be disabled. For this purpose, introduce a flag to disable the flooding > of received l2 broadcasts. This approach is backwards compatible and > provides flexibility in filtering for the desired packet types. >

Re: [iproute2] iplink: add support for IFLA_CARRIER attribute

On 26/04/17 10:08, Zhang Shengju wrote: > Add support to set IFLA_CARRIER attribute. > > Signed-off-by: Zhang Shengju > --- > ip/iplink.c | 12 > 1 file changed, 12 insertions(+) > You should also update the ip-link man page with this new

Re: [PATCHv2 net] bridge: move bridge multicast cleanup to ndo_uninit

hanged, 1 insertion(+), 1 deletion(-) Thank you for modifying the fix to use ndo_uninit(). Important note - this fix is dependent on Ido's earlier ndo_uninit() patch: b6fe0440c637 ("bridge: implement missing ndo_uninit()") Fixes: e10177abf842 ("bridge: multicast: fix handling of temp and perm entries") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled

On 25/04/17 16:32, Mike Manning wrote: > On 24/04/17 20:52, Nikolay Aleksandrov wrote: >> On 24/04/17 17:09, Mike Manning wrote: >>> Flood suppression for packets that are not unicast needs to be handled >>> consistently by also not flooding broadcast packets. As broa

Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled

ing for both of these packet types. > > Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag") > Cc: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Signed-off-by: Mike Manning <mmann...@brocade.com> > --- > net/bridge/br_forward.c | 17

Re: [PATCH net] bridge: shutdown bridge device before removing it

On 24/04/17 18:21, Xin Long wrote: > On Mon, Apr 24, 2017 at 10:53 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: >> On 24/04/17 17:41, Xin Long wrote: >>> On Mon, Apr 24, 2017 at 8:07 PM, Nikolay Aleksandrov >>> <niko...@cumulusnetworks.com&

Re: [PATCH net] bridge: shutdown bridge device before removing it

On 24/04/17 17:41, Xin Long wrote: > On Mon, Apr 24, 2017 at 8:07 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: >> On 24/04/17 14:01, Nikolay Aleksandrov wrote: >>> On 24/04/17 10:25, Xin Long wrote: >>>> During removing a bridge device, if

Re: [PATCH net] bridge: shutdown bridge device before removing it

On 24/04/17 14:01, Nikolay Aleksandrov wrote: > On 24/04/17 10:25, Xin Long wrote: >> During removing a bridge device, if the bridge is still up, a new mdb entry >> still can be added in br_multicast_add_group() after all mdb entries are >> removed in br_multicast_dev

Re: [PATCH net] bridge: shutdown bridge device before removing it

On 24/04/17 14:01, Nikolay Aleksandrov wrote: > On 24/04/17 10:25, Xin Long wrote: >> During removing a bridge device, if the bridge is still up, a new mdb entry >> still can be added in br_multicast_add_group() after all mdb entries are >> removed in br_multicast_dev

Re: [PATCH net] bridge: shutdown bridge device before removing it

an mcast packet can get sent via br->dev after the br_multicast_dev_del() call. This is definitely stable material, if I'm not mistaken the issue is there since the introduction of br_dev_delete: commit e10177abf842 Author: Satish Ashok <sas...@cumulusnetworks.com> Date: Wed Jul 15 07:16:

Re: [Patch net] ip6mr: avoid double unregister of pim6reg device

On 21/04/17 23:20, Cong Wang wrote: > On Fri, Apr 21, 2017 at 12:34 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: >> On 21/04/17 22:27, Cong Wang wrote: >>> If we unregister the pim6reg device via default_device_exit_batch(), >>

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 22:50, Nikolay Aleksandrov wrote: > On 21/04/17 22:36, David Miller wrote: >> From: Nikolay Aleksandrov <niko...@cumulusnetworks.com> >> Date: Fri, 21 Apr 2017 21:30:42 +0300 >> >>> On 21/04/17 20:42, Nikolay Aleksandrov wrote: >>>> And

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 22:36, David Miller wrote: > From: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Date: Fri, 21 Apr 2017 21:30:42 +0300 > >> On 21/04/17 20:42, Nikolay Aleksandrov wrote: >>> Andrey Konovalov reported a BUG caused by the ip6mr code which

Re: [Patch net] ip6mr: avoid double unregister of pim6reg device

On 21/04/17 22:27, Cong Wang wrote: > If we unregister the pim6reg device via default_device_exit_batch(), > we will receive a notification and ip6mr_device_event() will > unregister it again. This causes a kernel BUG at net/core/dev.c:6813. > > Like commit 7dc00c82cbb0 ("ipv4: Fix ipmr

[PATCH net] ip6mr: fix notification device destruction

e0b29c57e9b3292c ]--- Reported-by: Andrey Konovalov <andreyk...@google.com> Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- Andrey could you please test with this patch applied ? I have run the reproducer locally and can no longer trigger the bug. I've made "noti

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 20:42, Nikolay Aleksandrov wrote: > Andrey Konovalov reported a BUG caused by the ip6mr code which is caused > because we call unregister_netdevice_many for a device that is already > being destroyed. In IPv4's ipmr that has been resolved by two commits > long time ago by

Re: net/core: BUG in unregister_netdevice_many

On 21/04/17 20:42, Linus Torvalds wrote: > On Fri, Apr 21, 2017 at 10:25 AM, Linus Torvalds > wrote: >> >> I'm assuming that the real cause is simply that "dev->reg_state" ends >> up being NETREG_UNREGISTERING or something. Maybe the BUG_ON() could >> be just

[PATCH net-next] net: bridge: notify on hw fdb takeover

Recently we added support for SW fdbs to take over HW ones, but that results in changing a user-visible fdb flag thus we need to send a notification, also it's consistent with how HW takes over SW entries. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br

Re: [PATCH net v2 1/2] bridge: implement missing ndo_uninit()

On 08/04/17 16:49, Ido Schimmel wrote: > On Sat, Apr 08, 2017 at 09:30:42AM -0400, Stephen Hemminger wrote: >> On Sat, 8 Apr 2017 14:41:58 +0300 >> wrote: >> >>> static void br_dev_free(struct net_device *dev) >>> { >>> - struct net_bridge *br = netdev_priv(dev); >>> -

Re: [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 18:36, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 18:27:37 +0300 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> On 07/04/17 18:22, Stephen Hemminger wrote: >>> On Fri, 7 Apr 2017 17:19:48 +0300 >>> Nikolay Aleksand

Re: [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 18:22, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 17:19:48 +0300 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> On 07/04/17 17:10, Stephen Hemminger wrote: >>> On Fri, 7 Apr 2017 15:49:15 +0300 >>> <ido...@mellanox.com&g

Re: [PATCH net] bridge: netlink: register netdevice before executing changelink

cuting its >> ndo_init(). >> >> Fix this by changing the order of both operations, so that >> br_changelink() is only processed after the netdevice is registered, >> when the VLAN group is already initialized. >> >> The changelink() call is done on a best-

Re: [BUG] kernel oops during bridge creation

On 06/04/17 23:44, Ido Schimmel wrote: > On Thu, Apr 06, 2017 at 11:26:06PM +0300, Nikolay Aleksandrov wrote: >> Actually making br_vlan_init() idempotent might work, keep the code as-is >> just init the >> the vlans before the changelink() in newlink(), then the second v

Re: [BUG] kernel oops during bridge creation

On 06/04/17 21:58, Ido Schimmel wrote: > +Nik > Thanks! > On Thu, Apr 06, 2017 at 08:19:35PM +0200, Peter V. Saveliev wrote: >> Operation: >> >> # ip link add name test type bridge vlan_default_pvid 1 >> >> Result: >> >> Kernel oops. Minimal required netlink packet structure: >> >> ifinfmsg: >>

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

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)

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

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

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

require to age them themselves. Signed-off-by: Nikolay Aleksandrov <niko...@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/

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

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

Re: [PATCH net-next v4] net: ipv4: add support for ECMP hash policy choice

On 16/03/17 18:49, Nikolay Aleksandrov wrote: > On 16/03/17 18:41, Stephen Hemminger wrote: >> On Thu, 16 Mar 2017 15:28:00 +0200 >> Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: >> >>> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysc

Re: [Patch net] bridge: resolve a false alarm of lockdep

private.h | 9 - > 2 files changed, 1 insertion(+), 10 deletions(-) > Interesting, thanks Cong! Fixes: 410b3d48f5111 ("bridge: fdb: add proper lock checks in searching functions") Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH net-next v4] net: ipv4: add support for ECMP hash policy choice

On 16/03/17 18:41, Stephen Hemminger wrote: > On Thu, 16 Mar 2017 15:28:00 +0200 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c >> index d6880a6149ee..62c4f94923e5 100644 >>

[PATCH net-next v4] net: ipv4: add support for ECMP hash policy choice

always use it for the hash calculation, otherwise we fallback to fl4, that is if skb is NULL fl4 has to be set. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- v4: - fix the ICMP send ip_forward case to use the skb_in addresses - use hash_keys directly when extractin

Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

On 15/03/17 13:32, Jakub Sitnicki wrote: > On Tue, Mar 14, 2017 at 03:36 PM GMT, Nikolay Aleksandrov wrote: >> This patch adds support for ECMP hash policy choice via a new sysctl >> called fib_multipath_hash_policy and also adds support for L4 hashes. >&g

Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

> On Mar 15, 2017, at 1:18 PM, Nicolas Dichtel <nicolas.dich...@6wind.com> > wrote: > > Le 15/03/2017 à 11:46, Nikolay Aleksandrov a écrit : > [snip] >> This doesn’t fit the NETCONFA model well, there is no “all”, “default” or >> per iface option to be set, a

Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

> On Mar 15, 2017, at 11:17 AM, Nicolas Dichtel > wrote: > > Le 15/03/2017 à 00:45, David Ahern a écrit : >> On 3/14/17 5:27 PM, Stephen Hemminger wrote: >>> On Tue, 14 Mar 2017 15:38:40 -0700 >>> Roopa Prabhu wrote: >>> > That's

Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

> On Mar 14, 2017, at 5:36 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: > > This patch adds support for ECMP hash policy choice via a new sysctl > called fib_multipath_hash_policy and also adds support for L4 hashes. > The current values for fib_multip

Re: [PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

On 14/03/17 17:55, Stephen Hemminger wrote: > On Tue, 14 Mar 2017 17:36:15 +0200 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> This patch adds support for ECMP hash policy choice via a new sysctl >> called fib_multipath_hash_policy and also

[PATCH net-next v3] net: ipv4: add support for ECMP hash policy choice

then it will be used instead of being calculated (currently only for L4). In L3 mode we always calculate the hash due to the ICMP error special case, the flow dissector's field consistentification should handle the address order thus we can remove the address reversals. Signed-off-by: Nikolay

Re: [PATCH net-next v2] net: ipv4: add support for ECMP hash policy choice

On 08/03/17 14:05, Jakub Sitnicki wrote: > Hi Nikolay, > > On Tue, Mar 07, 2017 at 11:01 AM GMT, Nikolay Aleksandrov wrote: >> This patch adds support for ECMP hash policy choice via a new sysctl >> called fib_multipath_hash_policy and also adds support for L4 hashes.

[PATCH net-next v2] net: ipv4: add support for ECMP hash policy choice

then it will be used instead of being calculated. The ICMP inner IP addresses use is removed. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- v2: - removed the output_key_hash as it's not needed anymore - reverted to my original/internal patch with L3 as defaul

Re: [PATCH net-next] net: ipv4: add support for ECMP hash policy choice

On 06/03/17 18:24, David Ahern wrote: > On 3/6/17 7:59 AM, Nikolay Aleksandrov wrote: >> diff --git a/include/net/route.h b/include/net/route.h >> index c0874c87c173..77a5c613a290 100644 >> --- a/include/net/route.h >> +++ b/include/net/route.h >> @@ -113,13 +11

[PATCH net-next] net: ipv4: add support for ECMP hash policy choice

policy then it will be used instead of being calculated. The ICMP inner IP addresses use is removed, and we switch to L4 default for better distribution. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- I'm not happy with using an integer, but it produces the smallest churn

Re: [PATCH] net: bridge: allow IPv6 when multicast flood is disabled

On 01/03/17 11:57, Mike Manning wrote: > On 28/02/17 09:20, Nikolay Aleksandrov wrote: >> We are aware of this and have discussed it, but I’m not sure this is the >> best way to fix it, >> it will still allow local IPv4 mcast to be flooded on all ports even with

Re: [PATCH v2] net: bridge: allow IPv6 when multicast flood is disabled

multicast flood flag") > Cc: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Signed-off-by: Mike Manning <mmann...@brocade.com> > --- > net/bridge/br_forward.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/bridge/br_forward.c

Re: [PATCH] net: bridge: allow IPv6 when multicast flood is disabled

ed by us. And similar to the unicast case, > set auto-mask if the multicast flood flag is set. > > Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag") > Cc: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Signed-off-by: Mike Manning <mman

Re: [PATCH net-next] bridge: vlan_tunnel: explicitly reset metadata attrs to NULL on failure

struct > net_bridge_vlan_group *vg, > return 0; > out: > dst_release(>tinfo.tunnel_dst->dst); > + vlan->tinfo.tunnel_dst = NULL; > + vlan->tinfo.tunnel_id = 0; > > return err; > } > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH net-next] bridge: don't indicate expiry on NTF_EXT_LEARNED fdb entries

n't > indicate expiry for such fdb entries. > > CC: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > CC: Jiri Pirko <j...@resnulli.us> > CC: Ido Schimmel <ido...@mellanox.com> > Signed-off-by: Roopa Prabhu <ro...@cumulusnetworks.com> > --- >

[PATCH iproute2 net-next 0/3] iplink: add support for link xstats

xstats link option and you can find an example in patch 02's commit message. Thanks, Nik Nikolay Aleksandrov (3): iplink: add support for xstats subcommand iplink: bridge: add support for displaying xstats iplink: bridge_slave: add support for displaying xstats ip/Makefile

[PATCH iproute2 net-next 2/3] iplink: bridge: add support for displaying xstats

MLD reports: RX: v1 0 v2 0 TX: v1 0 v2 0 MLD leaves: RX: 0 TX: 0 MLD parse errors: 0 Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- ip/iplink_bridge.c

[PATCH iproute2 net-next 1/3] iplink: add support for xstats subcommand

This patch adds support for a new xstats link subcommand which uses the specified link type's new parse/print_ifla_xstats callbacks to display extended statistics. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- ip/Makefile | 2 +- ip/ip_common.h

[PATCH iproute2 net-next 3/3] iplink: bridge_slave: add support for displaying xstats

This patch adds support to the bridge_slave link type for displaying xstats by reusing the previously added bridge xstats callbacks. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- ip/ip_common.h | 3 +++ ip/iplink_bridge.c | 6 +++-

[PATCH net-next 1/3] bridge: fdb: converge fdb searching functions into one

abusers of __br_fdb_get which called it under hash_lock and replace them with br_fdb_find(). Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_device.c | 2 +- net/bridge/br_fdb.c | 113 net/bridge/br_i

[PATCH net-next 0/3] bridge: minor fdb cleanup

Hi, These patches aim to simplify the bridge fdb API a little by removing some redundant functions and converting them into wrappers of a single function. Also add proper lock checking to avoid future mistakes for the search functions. Thanks, Nik Nikolay Aleksandrov (3): bridge: fdb

[PATCH net-next 3/3] bridge: fdb: converge fdb_delete_by functions into one

We can simplify the logic of entries pointing to the bridge by converging the fdb_delete_by functions, this would allow us to use the same function for both cases since the fdb's dst is set to NULL if it is pointing to the bridge thus we can always check for a port match. Signed-off-by: Nikolay

[PATCH net-next 2/3] bridge: fdb: add proper lock checks in searching functions

In order to avoid new errors add checks to br_fdb_find and fdb_find_rcu functions. The first requires hash_lock, the second obviously RCU. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_fdb.c | 4 net/bridge/br_private.h | 9 + 2 files c

Re: [PATCH net-next] bridge: avoid unnecessary read of jiffies

letions(-) > Yep, good catch. Maybe you can use READ_ONCE() even though it's not needed just to show why it's done this way. Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

[PATCH net-next] bridge: tunnel: fix attribute checks in br_parse_vlan_tunnel_info

These checks should go after the attributes have been parsed otherwise we're using tb uninitialized. Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support") Reported-by: Colin Ian King <colin.k...@canonical.com> Signed-off-by: Nikolay Aleksandrov <niko...@

Re: [PATCH][net-next] net: bridge: remove redundant check to see if err is set

return err; > } > > return err; > Actually that code can be reduced further, I'll follow up with a patch later. Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: bridge: per vlan dst_metadata netlink support

On 07/02/17 12:25, Colin Ian King wrote: > Hi, > > Static analysis with CoverityScan on net/bridge/br_netlink_tunnel.c has > picked up and issue where tb[] is being referenced but contains > uninitialized data. > > 222 int br_parse_vlan_tunnel_info(struct nlattr *attr, > 223

Re: [PATCH net-next 0/4] bridge: improve cache utilization

On 04/02/17 22:46, Stephen Hemminger wrote: > On Sat, 4 Feb 2017 18:05:05 +0100 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> Hi all, >> This is the first set which begins to deal with the bad bridge cache >> access patterns. The first pat

[PATCH net-next 2/4] bridge: move to workqueue gc

expired in __br_fdb_get that causes false-sharing and is completely unnecessary if we cleanup entries, at worst we'll get 10ms of traffic for that entry before it gets deleted. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_device.c| 1 + net/bridge/br

[PATCH net-next 1/4] bridge: modify bridge and port to have often accessed fields in one cache line

cket). Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_private.h | 43 --- 1 file changed, 20 insertions(+), 23 deletions(-) diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h index 40177df45ba6..ec8560349

[PATCH net-next 0/4] bridge: improve cache utilization

Thanks, Nik Nikolay Aleksandrov (4): bridge: modify bridge and port to have often accessed fields in one cache line bridge: move to workqueue gc bridge: move write-heavy fdb members in their own cache line bridge: fdb: write to used and updated at most once per jiffy net/bridge/br_de

[PATCH net-next 3/4] bridge: move write-heavy fdb members in their own cache line

not using that fdb (and are only doing lookups over it). The point is with this move we make sure that only communicating parties get the false-sharing, in a later patch we'll show how to avoid that too. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/b

[PATCH net-next 4/4] bridge: fdb: write to used and updated at most once per jiffy

Writing once per jiffy is enough to limit the bridge's false sharing. After this change the bridge doesn't show up in the local load HitM stats. Suggested-by: David S. Miller <da...@davemloft.net> Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br

Re: [PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used updates

On 03/02/17 03:47, David Miller wrote: > From: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Date: Tue, 31 Jan 2017 16:31:58 +0100 > >> @@ -197,7 +197,8 @@ int br_handle_frame_finish(struct net *net, struct sock >> *sk, struct sk_buff *skb >&g

Re: [PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used updates

On 03/02/17 23:24, Stephen Hemminger wrote: > On Fri, 3 Feb 2017 19:34:19 +0100 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> On 03/02/17 19:28, Stephen Hemminger wrote: >>> On Fri, 3 Feb 2017 09:30:37 +0100 >>> Nikolay Aleksand

Re: [PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used updates

On 03/02/17 19:28, Stephen Hemminger wrote: > On Fri, 3 Feb 2017 09:30:37 +0100 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> On 03/02/17 03:47, David Miller wrote: >>> From: Nikolay Aleksandrov <niko...@cumulusnetworks.com> >&

Re: [PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used updates

On 03/02/17 03:47, David Miller wrote: > From: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Date: Tue, 31 Jan 2017 16:31:58 +0100 > >> @@ -197,7 +197,8 @@ int br_handle_frame_finish(struct net *net, struct sock >> *sk, struct sk_buff *skb >&g

Re: [PATCH RFC net-next 0/4] bridge: improve cache utilization

On 31/01/17 19:21, Stephen Hemminger wrote: > On Tue, 31 Jan 2017 19:09:09 +0100 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> On 31/01/17 17:41, Nikolay Aleksandrov wrote: >>>> >>>> I agree with the first 3 patches, but

Re: [PATCH RFC net-next 0/4] bridge: improve cache utilization

On 31/01/17 19:45, Nikolay Aleksandrov wrote: > On 31/01/17 19:21, Stephen Hemminger wrote: >> On Tue, 31 Jan 2017 19:09:09 +0100 >> Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: >> >>> On 31/01/17 17:41, Nikolay Aleksandrov wrote: >>

Re: [PATCH RFC net-next 0/4] bridge: improve cache utilization

On 31/01/17 17:41, Nikolay Aleksandrov wrote: >> >> I agree with the first 3 patches, but not the last one. >> Changing the API just for a performance hack is not necessary. Instead make >> the algorithm smarter and use per-cpu values. >> > > Thanks for the fe

Re: [PATCH RFC net-next 0/4] bridge: improve cache utilization

> > I agree with the first 3 patches, but not the last one. > Changing the API just for a performance hack is not necessary. Instead make > the algorithm smarter and use per-cpu values. > Thanks for the feedback, I would very much prefer any of the other two approaches I tried (per-cpu pool

Re: [PATCH RFC net-next 3/4] bridge: move write-heavy fdb members in their own cache line

On 31/01/17 17:37, Stephen Hemminger wrote: > On Tue, 31 Jan 2017 16:31:57 +0100 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> Fdb's used and updated fields are written to on every packet forward and >> packet receive respectively. Thus if we

[PATCH RFC net-next 2/4] bridge: move to workqueue gc

expired in __br_fdb_get that causes false-sharing and is completely unnecessary if we cleanup entries, at worst we'll get ~10ms of traffic for that entry before it gets deleted. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_device.c| 1 + net/

[PATCH RFC net-next 3/4] bridge: move write-heavy fdb members in their own cache line

not using that fdb (and are only doing lookups over it). The point is with this move we make sure that only communicating parties get the false-sharing, in a later patch we'll show how to avoid that too. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/b

[PATCH RFC net-next 4/4] bridge: add ability to turn off fdb used updates

transmit to that fdb will not touch the "used" field. The default is used_enabled = 1 to avoid breaking user-space, strongly suggest if not needed to set it to 0. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- include/uapi/linux/if_link.h | 1 + net/bridge/

[PATCH RFC net-next 0/4] bridge: improve cache utilization

r_fdb_update 0.10% ksoftirqd/0[k] br_handle_frame_finish Thanks, Nik Nikolay Aleksandrov (4): bridge: modify bridge and port to have often accessed fields in one cache line bridge: move to workqueue gc bridge: move write-heavy fdb members in their own cache line bridge:

[PATCH RFC net-next 1/4] bridge: modify bridge and port to have often accessed fields in one cache line

flags & vlan group to the beginning, so they're in the same cache line with the port's state (both flags and state are checked on each packet). Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_private.h | 43 -

Re: [RFC PATCH net-next 5/5] bridge: vlan lwt dst_metadata hooks in ingress and egress paths

unnel port, use tunnel info attached to > vlan to set dst_metadata on the skb > > CC: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > Signed-off-by: Roopa Prabhu <ro...@cumulusnetworks.com> > --- > CC'ing Nikolay for some more eyes as he has been trying to

Re: [RFC PATCH net-next 4/5] bridge: vlan lwt and dst_metadata netlink support

ch/detach > dst_metadata to bridged packets on ports. > > Use case: > example use for this is a vxlan bridging gateway or vtep > which maps vlans to vn-segments (or vnis). User can configure > per-vlan tunnel information which the bridge driver can use > to bridge vlan into

Re: [RFC PATCH net-next 2/5] vxlan: make COLLECT_METADATA mode bridge friendly

On 21/01/17 06:46, Roopa Prabhu wrote: > From: Roopa Prabhu > > This patch series makes vxlan COLLECT_METADATA mode bridge > and layer2 network friendly. Vxlan COLLECT_METADATA mode today > solves the per-vni netdev scalability problem in l3 networks. > When vxlan

Re: [PATCH net-next v5] bridge: multicast to unicast

1 + > include/uapi/linux/if_link.h | 1 + > net/bridge/br_forward.c | 39 ++++++- > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c| 90 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 3 +- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 114 insertions(+), 29 deletions(-) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

[PATCH iproute2 net-next v2] ipmroute: add support for RTNH_F_UNRESOLVED

25.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- v2: sent latest version, with dumping the state in one line ip/ipmroute.c | 2 ++ ip/iproute.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/ip

[PATCH iproute2 net-next] ipmroute: add support for RTNH_F_UNRESOLVED

25.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- ip/ipmroute.c | 6 ++ ip/iproute.c | 2 ++ 2 files changed, 8 insertions(+) diff --git a/ip/ipmroute.c b/ip/ipmroute.c index 512afcd2086e..913f3fd28e14

Re: [PATCH iproute2 net-next] ipmroute: add support for RTNH_F_UNRESOLVED

On 20/01/17 15:04, Nikolay Aleksandrov wrote: > This patch adds a new field that is printed in the end of the line which > denotes the real entry state. Before this patch an entry's IIF could > disappear and it would look like an unresolved one (iif = unresolved): > (3.0.16.1,

Re: [PATCH net-next v4] bridge: multicast to unicast

2 +- > net/bridge/br_multicast.c| 96 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 8 ++-- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 121 insertions(+), 31 deletions(-) > Looks good to me, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH iproute2 net-next] iplink: bridge_slave: add support for IFLA_BRPORT_FLUSH

+-- > 1 file changed, 7 insertions(+), 2 deletions(-) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCHv2 iproute2 net-next 2/5] iplink: bridge: add support for IFLA_BR_VLAN_STATS_ENABLED

++ > 1 file changed, 13 insertions(+) > Thanks, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCHv2 iproute2 net-next 3/5] iplink: bridge: add support for IFLA_BR_MCAST_STATS_ENABLED

++ > 1 file changed, 13 insertions(+) > Thanks, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH iproute2 net-next 1/5] iplink: bridge: add support for IFLA_BR_FDB_FLUSH

changed, 4 insertions(+), 1 deletion(-) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH iproute2 net-next 5/5] iplink: bridge: add support for IFLA_BR_MCAST_MLD_VERSION

++ > 1 file changed, 13 insertions(+) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

<    1   2   3   4   5   6   7   8   9   10   >