All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: netdev@vger.kernel.org
Cc: roopa@cumulusnetworks.com, andrew@lunn.ch, davem@davemloft.net,
	bridge@lists.linux-foundation.org,
	Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Subject: [PATCH net-next v2 0/3] net: bridge: add an option to disabe linklocal learning
Date: Sat, 24 Nov 2018 04:34:19 +0200	[thread overview]
Message-ID: <20181124023422.13908-1-nikolay@cumulusnetworks.com> (raw)

Hi,
This set adds a new bridge option which can control learning from
link-local packets, by default learning is on to be consistent and avoid
breaking users expectations. If the new no_linklocal_learn option is
enabled then the bridge will stop learning from link-local packets.

In order to save space for future boolean options, patch 01 adds a new
bool option API that uses a bitmask to control boolean options. The
bridge is by far the largest netlink attr user and we keep adding simple
boolean options which waste nl attr ids and space. We're not directly
mapping these to the in-kernel bridge flags because some might require
more complex configuration changes (e.g. if we were to add the per port
vlan stats now, it'd require multiple checks before changing value).
Any new bool option needs to be handled by both br_boolopt_toggle and get
in order to be able to retrieve its state later. All such options are
automatically exported via netlink. The behaviour of setting such
options is consistent with netlink option handling when a missing
option is being set (silently ignored), e.g. when a newer iproute2 is used
on older kernel. All supported options are exported via bm's optmask
when dumping the new attribute.

v2: address Andrew Lunn's comments, squash a minor change into patch 01,
    export all supported options via optmask when dumping, add patch 03,
    pass down extack so options can return meaningful errors, add
    WARN_ON on unsupported options (should not happen)

Thanks,
 Nik

Nikolay Aleksandrov (3):
  net: bridge: add support for user-controlled bool options
  net: bridge: add no_linklocal_learn bool option
  net: bridge: export supported boolopts

 include/uapi/linux/if_bridge.h | 21 ++++++++++
 include/uapi/linux/if_link.h   |  1 +
 net/bridge/br.c                | 76 ++++++++++++++++++++++++++++++++++
 net/bridge/br_input.c          |  4 +-
 net/bridge/br_netlink.c        | 17 +++++++-
 net/bridge/br_private.h        |  9 ++++
 net/bridge/br_sysfs_br.c       | 22 ++++++++++
 net/core/rtnetlink.c           |  2 +-
 8 files changed, 149 insertions(+), 3 deletions(-)

-- 
2.17.2

WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: netdev@vger.kernel.org
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
	andrew@lunn.ch, roopa@cumulusnetworks.com,
	bridge@lists.linux-foundation.org, davem@davemloft.net
Subject: [Bridge] [PATCH net-next v2 0/3] net: bridge: add an option to disabe linklocal learning
Date: Sat, 24 Nov 2018 04:34:19 +0200	[thread overview]
Message-ID: <20181124023422.13908-1-nikolay@cumulusnetworks.com> (raw)

Hi,
This set adds a new bridge option which can control learning from
link-local packets, by default learning is on to be consistent and avoid
breaking users expectations. If the new no_linklocal_learn option is
enabled then the bridge will stop learning from link-local packets.

In order to save space for future boolean options, patch 01 adds a new
bool option API that uses a bitmask to control boolean options. The
bridge is by far the largest netlink attr user and we keep adding simple
boolean options which waste nl attr ids and space. We're not directly
mapping these to the in-kernel bridge flags because some might require
more complex configuration changes (e.g. if we were to add the per port
vlan stats now, it'd require multiple checks before changing value).
Any new bool option needs to be handled by both br_boolopt_toggle and get
in order to be able to retrieve its state later. All such options are
automatically exported via netlink. The behaviour of setting such
options is consistent with netlink option handling when a missing
option is being set (silently ignored), e.g. when a newer iproute2 is used
on older kernel. All supported options are exported via bm's optmask
when dumping the new attribute.

v2: address Andrew Lunn's comments, squash a minor change into patch 01,
    export all supported options via optmask when dumping, add patch 03,
    pass down extack so options can return meaningful errors, add
    WARN_ON on unsupported options (should not happen)

Thanks,
 Nik

Nikolay Aleksandrov (3):
  net: bridge: add support for user-controlled bool options
  net: bridge: add no_linklocal_learn bool option
  net: bridge: export supported boolopts

 include/uapi/linux/if_bridge.h | 21 ++++++++++
 include/uapi/linux/if_link.h   |  1 +
 net/bridge/br.c                | 76 ++++++++++++++++++++++++++++++++++
 net/bridge/br_input.c          |  4 +-
 net/bridge/br_netlink.c        | 17 +++++++-
 net/bridge/br_private.h        |  9 ++++
 net/bridge/br_sysfs_br.c       | 22 ++++++++++
 net/core/rtnetlink.c           |  2 +-
 8 files changed, 149 insertions(+), 3 deletions(-)

-- 
2.17.2


             reply	other threads:[~2018-11-24 13:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-24  2:34 Nikolay Aleksandrov [this message]
2018-11-24  2:34 ` [Bridge] [PATCH net-next v2 0/3] net: bridge: add an option to disabe linklocal learning Nikolay Aleksandrov
2018-11-24  2:34 ` [PATCH net-next v2 1/3] net: bridge: add support for user-controlled bool options Nikolay Aleksandrov
2018-11-24  2:34   ` [Bridge] " Nikolay Aleksandrov
2018-11-24 16:10   ` Andrew Lunn
2018-11-24 16:10     ` [Bridge] " Andrew Lunn
2018-11-24 16:18     ` nikolay
2018-11-24 16:18       ` [Bridge] " nikolay
2018-11-24 16:25       ` Andrew Lunn
2018-11-24 16:25         ` [Bridge] " Andrew Lunn
2018-11-24 16:46         ` nikolay
2018-11-24 16:46           ` [Bridge] " nikolay
2018-11-25  8:12           ` Nikolay Aleksandrov
2018-11-25  8:12             ` [Bridge] " Nikolay Aleksandrov
2018-11-26 17:39             ` Stephen Hemminger
2018-11-26 17:39               ` [Bridge] " Stephen Hemminger
2018-11-26 17:41               ` Nikolay Aleksandrov
2018-11-26 17:41                 ` [Bridge] " Nikolay Aleksandrov
2018-11-25 15:45   ` Andrew Lunn
2018-11-25 15:45     ` [Bridge] " Andrew Lunn
2018-11-24  2:34 ` [PATCH net-next v2 2/3] net: bridge: add no_linklocal_learn bool option Nikolay Aleksandrov
2018-11-24  2:34   ` [Bridge] " Nikolay Aleksandrov
2018-11-24 16:27   ` Andrew Lunn
2018-11-24 16:27     ` [Bridge] " Andrew Lunn
2018-11-24  2:34 ` [PATCH net-next v2 3/3] net: bridge: export supported boolopts Nikolay Aleksandrov
2018-11-24  2:34   ` [Bridge] " Nikolay Aleksandrov
2018-11-24 16:16   ` Andrew Lunn
2018-11-24 16:16     ` [Bridge] " Andrew Lunn
2018-11-24 16:20     ` nikolay
2018-11-24 16:20       ` [Bridge] " nikolay
2018-11-24 16:26   ` Andrew Lunn
2018-11-24 16:26     ` [Bridge] " Andrew Lunn
2018-11-27 23:04 ` [PATCH net-next v2 0/3] net: bridge: add an option to disabe linklocal learning David Miller
2018-11-27 23:04   ` [Bridge] " David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181124023422.13908-1-nikolay@cumulusnetworks.com \
    --to=nikolay@cumulusnetworks.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.