From: Stephen Hemminger <stephen@networkplumber.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: kvm@vger.kernel.org, netdev@vger.kernel.org, mcgrof@suse.com,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
xen-devel@lists.xenproject.org
Subject: Re: [Bridge] [RFC v3 4/6] bridge: enable root block during device registration
Date: Mon, 3 Mar 2014 15:43:30 -0800 [thread overview]
Message-ID: <20140303154330.238a20bc@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <1393886825-24323-5-git-send-email-mcgrof@do-not-panic.com>
On Mon, 3 Mar 2014 14:47:03 -0800
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> root block support was added via 1007dd1a on v3.8 but toggling
> this flag is only allowed after a device has been registered and
> added to a bridge as its a bridge *port* primitive, not a *net_device*
> feature. There are work arounds possible to account for the lack
> of netlink tools to toggle root_block, such as using the root_block
> syfs attribute [0] or using udev / the driver to set the MAC address
> to something high such as FE:FF:FF:FF:FF:FF, but neither of these
> ensure root block is respected _from_the_start_ through device
> initialization.
>
> In order to support the root_block feature from the start since device
> initialization and in order to avoid having to require userspace
> work arounds to existing deployments this exposes a private
> net_device flag which enables drivers that know they want to
> start with the root_block feature enabled form the start. The
> only caveat with this is topologies that require STP or non-root
> will either have to use sysfs [0] or netlink tools like the
> iproute2 bridge util to toggle the flag off after initialization.
> This is an accepted compromise.
>
> This flag is required given that ndo_add_slave() currently does not
> allow specifying any other parameters other than the net_device. We
> could extend this but in order to do that properly we'd need to
> evaluate all other types of master device implementations.
>
> [0] echo 1 > /sys/devices/vif-2-0/net/vif2.0/brport/root_block
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: bridge@lists.linux-foundation.org
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xenproject.org
> Cc: kvm@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
> include/linux/netdevice.h | 7 +++++++
> net/bridge/br_if.c | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 1a86948..b17643a 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1181,6 +1181,11 @@ struct net_device_ops {
> * @IFF_LIVE_ADDR_CHANGE: device supports hardware address
> * change when it's running
> * @IFF_MACVLAN: Macvlan device
> + * @IFF_BRIDGE_ROOT_BLOCK: don't consider this net_device for root port
> + * when this interface is added to a bridge. This makes use of the
> + * root_block mechanism but since its a bridge port primitive this
> + * flag can be used to instantiate the preference to have root block
> + * enabled from the start since initialization.
> */
Doing this in priv flags bloats what is a limited resource (# of bits).
Plus there are issues (what if this is changed after adding to bridge)?
Maybe better to enhance existing netlink infrastructure to allow passing
flags on adding port to bridge.
Also, unless device is up, nothing will happen right away when added to bridge.
Root port status can be changed since device is disabled.
next prev parent reply other threads:[~2014-03-03 23:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1393886825-24323-1-git-send-email-mcgrof@do-not-panic.com>
2014-03-03 22:47 ` [Bridge] [RFC v3 1/6] bridge: preserve random init MAC address Luis R. Rodriguez
2014-03-03 22:47 ` [Bridge] [RFC v3 2/6] bridge: trigger a bridge calculation upon port changes Luis R. Rodriguez
2014-03-03 22:47 ` [Bridge] [RFC v3 3/6] bridge: fix bridge root block on designated port Luis R. Rodriguez
2014-03-03 22:47 ` [Bridge] [RFC v3 4/6] bridge: enable root block during device registration Luis R. Rodriguez
2014-03-03 23:43 ` Stephen Hemminger [this message]
2014-03-03 23:58 ` Luis R. Rodriguez
2014-03-04 0:31 ` Stephen Hemminger
2014-03-04 0:53 ` Luis R. Rodriguez
2014-03-03 22:47 ` [Bridge] [RFC v3 5/6] xen-netback: use a random MAC address and force bridge root block Luis R. Rodriguez
2014-03-03 22:47 ` [Bridge] [RFC v3 6/6] tun: add initialization root block support Luis R. Rodriguez
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=20140303154330.238a20bc@nehalam.linuxnetplumber.net \
--to=stephen@networkplumber.org \
--cc=bridge@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=netdev@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox