Re: [Bridge] [PATCH iproute2-next 1/2] configure: add the --color option

On 9/15/23 9:59 AM, Stephen Hemminger wrote: > On Wed, 13 Sep 2023 19:58:25 +0200 > Andrea Claudi wrote: > >> This commit allows users/packagers to choose a default for the color >> output feature provided by some iproute2 tools. >> >> The configure script option is documented in the script

Re: [Bridge] [PATCH net-next v2 0/4] Add backup nexthop ID support

| 1 + > net/bridge/br_netlink.c | 12 + > net/bridge/br_private.h | 3 + > net/bridge/br_vlan_tunnel.c | 15 + > net/core/rtnetlink.c | 2 +- > tools/testing/selftests/net/Makefile | 1 + > .../selftests/net/test_bridge_backup_port.sh | 759 ++ > 10 files changed, 838 insertions(+), 1 deletion(-) > create mode 100755 tools/testing/selftests/net/test_bridge_backup_port.sh > For the series: Acked-by: David Ahern

Re: [Bridge] [RFC PATCH net-next 0/4] Add backup nexthop ID support

On 7/13/23 1:09 AM, Ido Schimmel wrote: > tl;dr > = > > This patchset adds a new bridge port attribute specifying the nexthop > object ID to attach to a redirected skb as tunnel metadata. The ID is > used by the VXLAN driver to choose the target VTEP for the skb. This is > useful for EVPN

Re: [Bridge] [PATCH net-next v2 0/8] net: bridge: add flush filtering support

On Mon, Apr 11, 2022 at 12:22:24PM -0700, Roopa Prabhu wrote: > all great points. My only reason to explore RTM_DELNEIGH is to see if we can > find a recipe to support similar bulk deletes of other objects handled via > rtm msgs in the future. Plus, it allows you to maintain symmetry between >

Re: [Bridge] [PATCH net-next v4 05/12] net: rtnetlink: add bulk delete support flag

On 4/13/22 6:21 AM, Nikolay Aleksandrov wrote: >> If a buggy user space application is sending messages with NLM_F_BULK >> set (unintentionally), will it break on newer kernel? I couldn't find >> where the kernel was validating that reserved flags are not used (I >> suspect it doesn't). > >

Re: [Bridge] [PATCH net-next v3 0/8] net: bridge: add flush filtering support

On 4/12/22 7:22 AM, Nikolay Aleksandrov wrote: > Hi, > This patch-set adds support to specify filtering conditions for a bulk > delete (flush) operation. This version uses a new nlmsghdr delete flag > called NLM_F_BULK in combination with a new ndo_fdb_del_bulk op which is > used to signal that

Re: [Bridge] [PATCH net-next v2 1/8] net: rtnetlink: add RTM_FLUSHNEIGH

On Mon, Apr 11, 2022 at 08:29:27PM +0300, Nikolay Aleksandrov wrote: > Add a new rtnetlink type used to flush neigh objects. It will be > initially used to add flush with filtering support for bridge fdbs, but > it also opens the door to add similar support to others (e.g. vxlan). > >

Re: [Bridge] [PATCH v3 iproute2] bridge: add support for L2 multicast groups

On 11/25/20 7:36 AM, Vladimir Oltean wrote: > Extend the 'bridge mdb' command for the following syntax: > bridge mdb add dev br0 port swp0 grp 01:02:03:04:05:06 permanent > > Signed-off-by: Vladimir Oltean > --- > Changes in v3: > - Using rt_addr_n2a_r instead of inet_ntop/ll_addr_n2a directly.

Re: [Bridge] [PATCH v2 iproute2-next] bridge: add support for L2 multicast groups

On 10/29/20 4:28 PM, Vladimir Oltean wrote: > @@ -168,9 +176,14 @@ static void print_mdb_entry(FILE *f, int ifindex, const > struct br_mdb_entry *e, > print_string(PRINT_ANY, "port", " port %s", >ll_index_to_name(e->ifindex)); > > + if (af == AF_INET || af ==

Re: [Bridge] [RFC PATCH bpf-next 2/3] bpf: Add helper to do forwarding lookups in kernel FDB table

On 8/4/20 5:27 AM, Yoshiki Komachi wrote: > > I guess that no build errors will occur because the API is allowed when > CONFIG_BRIDGE is enabled. > > I successfully build my kernel applying this patch, and I don’t receive any > messages from build robots for now. If CONFIG_BRIDGE is a module,

Re: [Bridge] [RFC PATCH bpf-next 0/3] Add a new bpf helper for FDB lookup

On 8/5/20 4:26 AM, Yoshiki Komachi wrote: >> >> Just to clarify for myself. I expect that with just the helpers here >> we should only expect static configurations to work, e.g. any learning >> and/or aging is not likely to work if we do redirects in the XDP path. > > As you described above,

Re: [Bridge] [PATCH net] net: bridge: clear bridge's private skb space on xmit

On 7/31/20 10:26 AM, Nikolay Aleksandrov wrote: > We need to clear all of the bridge private skb variables as they can be > stale due to the packet being recirculated through the stack and then > transmitted through the bridge device. Similar memset is already done on > bridge's input. We've seen

Re: [Bridge] [RFC PATCH bpf-next 2/3] bpf: Add helper to do forwarding lookups in kernel FDB table

On 7/30/20 10:44 PM, Yoshiki Komachi wrote: > diff --git a/net/core/filter.c b/net/core/filter.c > index 654c346b7d91..68800d1b8cd5 100644 > --- a/net/core/filter.c > +++ b/net/core/filter.c > @@ -5084,6 +5085,46 @@ static const struct bpf_func_proto > bpf_skb_fib_lookup_proto = { >

Re: [Bridge] [PATCH net-next 3/8] net: bridge: vlan: add rtm definitions and dump support

On 1/14/20 9:45 AM, Nikolay Aleksandrov wrote: > On 14/01/2020 18:36, Nikolay Aleksandrov wrote: >> On 14/01/2020 17:34, David Ahern wrote: >>> On 1/14/20 6:55 AM, Jakub Kicinski wrote: >>>> On Mon, 13 Jan 2020 17:52:28 +0200, Nikolay Aleksandrov wrote: >>>

Re: [Bridge] [PATCH net-next 3/8] net: bridge: vlan: add rtm definitions and dump support

On 1/14/20 9:50 AM, Nikolay Aleksandrov wrote: > Ah fair enough, so nlmsg_parse() would be better even without attrs. that was the intention. It would be a good verification of the theory if you could run a test with a larger ancillary header.

Re: [Bridge] [PATCH net-next 3/8] net: bridge: vlan: add rtm definitions and dump support

On 1/14/20 6:55 AM, Jakub Kicinski wrote: > On Mon, 13 Jan 2020 17:52:28 +0200, Nikolay Aleksandrov wrote: >> +static int br_vlan_rtm_dump(struct sk_buff *skb, struct netlink_callback >> *cb) >> +{ >> +int idx = 0, err = 0, s_idx = cb->args[0]; >> +struct net *net = sock_net(skb->sk); >>

Re: [Bridge] [PATCH iproute2 v4] iplink: add support for STP xstats

On 12/11/19 6:07 PM, Vivien Didelot wrote: > Add support for the BRIDGE_XSTATS_STP xstats, as follow: > > # ip link xstats type bridge_slave dev lan4 stp > lan4 > STP BPDU: RX: 0 TX: 61 > STP TCN: RX: 0 TX: 0 > STP

Re: [Bridge] [PATCH net-next v2] net: bridge: add STP xstats

On 12/10/19 2:20 PM, Vivien Didelot wrote: > diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h > index 1b3c2b643a02..e7f2bb782006 100644 > --- a/include/uapi/linux/if_bridge.h > +++ b/include/uapi/linux/if_bridge.h > @@ -156,6 +156,15 @@ struct bridge_vlan_xstats { >

Re: [PATCH net] net: bridge: mcast: don't delete permanent entries when fast leave is enabled

On 7/30/19 5:21 AM, Nikolay Aleksandrov wrote: > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 3d8deac2353d..f8cac3702712 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1388,6 +1388,9 @@ br_multicast_leave_group(struct net_bridge *br,

[Bridge] [PATCH v2 net-next 7/7] mlxsw: spectrum: Add extack messages for enslave failures

add br0.11 link br0 type vlan id 11 $ ip li set swp11 master br0 Error: spectrum: Enslaving a port to a device that already has an upper device is not supported. Signed-off-by: David Ahern <dsah...@gmail.com> Reviewed-by: Ido Schimmel <ido...@mellanox.com> Tested-by: Ido Schimme

[Bridge] [PATCH v2 net-next 6/7] net: bridge: Pass extack to down to netdev_master_upper_dev_link

Pass extack arg to br_add_if. Add messages for a couple of failures and pass arg to netdev_master_upper_dev_link. Signed-off-by: David Ahern <dsah...@gmail.com> Acked-by: Stephen Hemminger <step...@networkplumber.org> --- net/bridge/br_device.c | 2 +- net/bridge/br_if

[Bridge] [PATCH v2 net-next 5/7] net: bonding: Add extack messages for some enslave failures

A number of bond_enslave errors are logged using the netdev_err API. Return those messages to userspace via the extack facility. Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/bonding/bond_main.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/b

[Bridge] [PATCH v2 net-next 4/7] net: vrf: Add extack messages for enslave errors

Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/vrf.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 77d0655a0250..0b54f553228e 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -772,8 +

[Bridge] [PATCH v2 net-next 3/7] net: Add extack to upper device linking

Add extack arg to netdev_upper_dev_link and netdev_master_upper_dev_link Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/bonding/bond_main.c| 7 --- drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +- drivers/net/hyperv/netvsc

[Bridge] [PATCH v2 net-next 2/7] net: Add extack to ndo_add_slave

Pass extack to do_set_master and down to ndo_add_slave Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/bonding/bond_main.c| 5 +++-- drivers/net/bonding/bond_options.c | 2 +- drivers/net/team/team.c| 3 ++- drivers/net/vrf.c | 3 ++- i

[Bridge] [PATCH v2 net-next 0/7] net: Plumb extack error reporting to enslavements

Another round of extending extack error reporting, this time for enslavements through ndo_add_slave and notifiers. v2 - changed how the messages are added to bonding driver per Jiri's request - fixed spectrum message for LAG overflow per Ido's comment David Ahern (7): net: Add extack

Re: [Bridge] [PATCH net-next 5/7] net: bonding: Add extack messages for some enslave failures

he netdev_err API. >>>> Return those messages to userspace via the extack facility. >>>> >>>> Signed-off-by: David Ahern <dsah...@gmail.com> >>>> --- >>>> drivers/net/bonding/bond_main.c | 12 >>>> 1 file

Re: [Bridge] [PATCH net-next 6/7] net: bridge: Pass extack to down to netdev_master_upper_dev_link

On 10/4/17 8:13 AM, Stephen Hemminger wrote: > On Tue, 3 Oct 2017 21:58:53 -0700 > David Ahern <dsah...@gmail.com> wrote: > >> Pass extack arg to br_add_if. Add messages for a couple of failures >> and pass arg to netdev_master_upper_dev_link. >> >> Signed

Re: [Bridge] [PATCH net-next 7/7] mlxsw: spectrum: Add extack messages for enslave failures

On 10/4/17 6:24 AM, Ido Schimmel wrote: > On Tue, Oct 03, 2017 at 09:58:54PM -0700, David Ahern wrote: >> mlxsw fails device enslavement for a number of reasons. Use the extack >> facility to return an error message to the user stating why the enslave >> is failing. >&g

Re: [Bridge] [PATCH net-next 5/7] net: bonding: Add extack messages for some enslave failures

On 10/3/17 11:38 PM, Jiri Pirko wrote: > Wed, Oct 04, 2017 at 06:58:52AM CEST, dsah...@gmail.com wrote: >> A number of bond_enslave errors are logged using the netdev_err API. >> Return those messages to userspace via the extack facility. >> >> Signed-off-by: Dav

[Bridge] [PATCH net-next 6/7] net: bridge: Pass extack to down to netdev_master_upper_dev_link

Pass extack arg to br_add_if. Add messages for a couple of failures and pass arg to netdev_master_upper_dev_link. Signed-off-by: David Ahern <dsah...@gmail.com> --- net/bridge/br_device.c | 2 +- net/bridge/br_if.c | 15 +++ net/bridge/br_ioctl.c | 2 +- net/

[Bridge] [PATCH net-next 5/7] net: bonding: Add extack messages for some enslave failures

A number of bond_enslave errors are logged using the netdev_err API. Return those messages to userspace via the extack facility. Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/bonding/bond_main.c | 12 1 file changed, 12 insertions(+) diff --git a/drive

[Bridge] [PATCH net-next 4/7] net: vrf: Add extack messages for enslave errors

Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/vrf.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 77d0655a0250..0b54f553228e 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -772,8 +

[Bridge] [PATCH net-next 3/7] net: Add extack to upper device linking

Add extack arg to netdev_upper_dev_link and netdev_master_upper_dev_link Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/bonding/bond_main.c| 7 --- drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +- drivers/net/hyperv/netvsc

[Bridge] [PATCH net-next 2/7] net: Add extack to ndo_add_slave

Pass extack to do_set_master and down to ndo_add_slave Signed-off-by: David Ahern <dsah...@gmail.com> --- drivers/net/bonding/bond_main.c| 5 +++-- drivers/net/bonding/bond_options.c | 2 +- drivers/net/team/team.c| 3 ++- drivers/net/vrf.c | 3 ++- i

[Bridge] [PATCH net-next 1/7] net: Add extack to netdev_notifier_info

initalize on stack when info is declared. Signed-off-by: David Ahern <dsah...@gmail.com> --- include/linux/netdevice.h | 10 +- net/core/dev.c| 79 --- 2 files changed, 56 insertions(+), 33 deletions(-) diff --git a/include

[Bridge] [PATCH net-next 0/7] net: Plumb extack error reporting to enslavements

Another round of extending extack error reporting, this time for enslavements through ndo_add_slave and notifiers. David Ahern (7): net: Add extack to netdev_notifier_info net: Add extack to ndo_add_slave net: Add extack to upper device linking net: vrf: Add extack messages for enslave

Re: [Bridge] [net-next v3] bridge: trigger RTM_NEWLINK when interface is modified by bridge ioctl

On 9/21/17 11:20 AM, Roopa Prabhu wrote: > this patch seems fine...but ideally I would have assumed > netdev_upper_dev_unlink which > is eventually called in both paths would generate the RTN_NEWLINK > IFF_MASTER in response > to the NETDEV_CHANGEUPPER notifier. If we add it there now, it might >

Re: [Bridge] [net-next v3] bridge: trigger RTM_NEWLINK when interface is modified by bridge ioctl

; > > + if (!ret) > + rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_MASTER, GFP_KERNEL); > + > return ret; > } > > Agreed that this is needed for userspace to know about the master change when done through ioctl. The bridge code is emitting a lot of what appears to be redundant messages for both paths (netlink and ioctl). Reviewed-by: David Ahern <dsah...@gmail.com>

Re: [Bridge] [PATCH net-next] bridge: add tracepoint in br_fdb_update

On 8/31/17 9:21 AM, Roopa Prabhu wrote: > On Thu, Aug 31, 2017 at 5:38 AM, Jesper Dangaard Brouer > wrote: >> On Wed, 30 Aug 2017 22:18:13 -0700 >> Roopa Prabhu wrote: >> >>> From: Roopa Prabhu >>> >>> This extends bridge

Re: [Bridge] [PATCH] bridge: only provide proxy ARP when CONFIG_INET is enabled

On 1/13/15 2:33 PM, Arnd Bergmann wrote: The effect is very similar to my patch (probably same object code), the only difference should be that it would add an ugly #ifdef instead of the preferred IS_ENABLED() check, so you don't get any compile-time coverage of the function. Indeed. As long

Re: [Bridge] [PATCH] bridge: only provide proxy ARP when CONFIG_INET is enabled

On 1/13/15 1:57 PM, David Miller wrote: From: Cong Wang cw...@twopensource.com Date: Tue, 13 Jan 2015 11:25:45 -0800 On Tue, Jan 13, 2015 at 6:10 AM, Arnd Bergmann a...@arndb.de wrote: When IPV4 support is disabled, we cannot call arp_send from the bridge code, which would result in a kernel