netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, <kvm@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	<bridge@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
Date: Fri, 21 Feb 2014 13:02:33 +0000	[thread overview]
Message-ID: <53074E69.4060206@citrix.com> (raw)
In-Reply-To: <CAB=NE6WKhBJyyUO5o8B53J+F4PqF2PHvvbV3=yS3qs0ZDRKH7Q@mail.gmail.com>

On 20/02/14 20:01, Luis R. Rodriguez wrote:
> On Thu, Feb 20, 2014 at 5:19 AM, Zoltan Kiss <zoltan.kiss@citrix.com> wrote:
>> How about this: netback sets the root_block flag and a random MAC by
>> default. So the default behaviour won't change, DAD will be happy, and
>> userspace don't have to do anything unless it's using netback for STP root
>> bridge (I don't think there are too many toolstacks doing that), in which
>> case it has to remove the root_block flag instead of setting a random MAC.
>
> :D that's exactly what I ended up proposing too. I mentioned how
> xen-netback could do this as well, we'd keep or rename the flag I
> added, and then the bridge could would look at it and enable the root
> block if the flag is set. Stephen however does not like having the
> bridge code look at magic flags for this behavior and would prefer for
> us to get the tools to ask for the root block. Let's follow more up on
> that thread
We don't need that new flag, just forget about it. Set that root_block 
flag from netback device init, around the time you generate the random 
MAC, or at the earliest possible time. Nothing else has to be done from 
kernel side. If someone wants netback to be a root port, then remove 
root_block from their tools, instead of changing the the MAC address, as 
it happens now.
Another problem with the random addresses, pointed out by Ian earlier, 
that when adding/removing interfaces, the bridge does recalculate it's 
MAC address, and choose the lowest one. In the general usecase I think 
that's normal, but in case of Xen networking, we would like to keep the 
bridge using the physical interface's MAC, because the local port of the 
bridge is used for Dom0 network traffic, therefore changing the bridge 
MAC when a netback device has lower MAC breaks that traffic. I think the 
best is to address this from userspace: if it set the MAC of the bridge 
explicitly, dev_set_mac_address() does dev->addr_assign_type = 
NET_ADDR_SET;, so br_stp_recalculate_bridge_id() will exit before 
changing anything.
And when I say userspace, I mean Xen specific tools which does 
networking configuration, e.g. xapi in XenServer case. Not brctl, it 
doesn't have to know whether this is a xenbrX device or a bridge used 
for another purposes.

Zoli

  reply	other threads:[~2014-02-21 13:02 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-15  2:59 [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends Luis R. Rodriguez
2014-02-15  2:59 ` [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge Luis R. Rodriguez
2014-02-16 18:56   ` Ben Hutchings
2014-02-16 18:57   ` Stephen Hemminger
2014-02-18 21:02     ` Luis R. Rodriguez
2014-02-19  9:52       ` [Xen-devel] " Ian Campbell
2014-02-19 14:35         ` Zoltan Kiss
2014-02-19 17:02           ` Luis R. Rodriguez
2014-02-19 17:08             ` Stephen Hemminger
2014-02-19 17:59               ` Luis R. Rodriguez
2014-02-20 17:19                 ` Stephen Hemminger
2014-02-20 20:24                   ` Luis R. Rodriguez
2014-02-21 13:02                     ` Zoltan Kiss
2014-02-21 16:01                       ` Luis R. Rodriguez
2014-02-22  1:38                         ` Luis R. Rodriguez
2014-02-20 13:19             ` Zoltan Kiss
2014-02-20 20:01               ` Luis R. Rodriguez
2014-02-21 13:02                 ` Zoltan Kiss [this message]
2014-02-21 15:59                   ` Luis R. Rodriguez
2014-02-17 17:52   ` Zoltan Kiss
2014-02-19 16:45     ` Luis R. Rodriguez
2014-02-20 14:47       ` Zoltan Kiss
2014-02-20 20:28         ` Luis R. Rodriguez
2014-02-15  2:59 ` [RFC v2 2/4] net: enables interface option to skip IP Luis R. Rodriguez
2014-02-17 20:23   ` Dan Williams
2014-02-18 21:19     ` Luis R. Rodriguez
2014-02-18 21:42       ` Stephen Hemminger
2014-02-19 17:13         ` Luis R. Rodriguez
2014-02-19 16:45       ` Dan Williams
2014-02-19 17:20         ` Luis R. Rodriguez
2014-02-19 19:13           ` Zoltan Kiss
2014-02-20 20:39             ` Luis R. Rodriguez
2014-02-21 13:02               ` Zoltan Kiss
2014-02-22  1:40                 ` Luis R. Rodriguez
2014-02-20  0:56           ` Dan Williams
2014-02-20  0:58             ` Hannes Frederic Sowa
2014-02-20  1:02               ` Dan Williams
2014-02-20 20:31             ` Luis R. Rodriguez
2014-02-24 18:22               ` Dan Williams
2014-02-24 20:33                 ` Luis R. Rodriguez
2014-02-24 23:04                 ` David Miller
2014-02-25  0:02                   ` Ben Hutchings
2014-02-25  0:12                     ` David Miller
2014-02-25  2:01                       ` Ben Hutchings
2014-02-25  2:23                         ` Hannes Frederic Sowa
2014-02-25 19:50                       ` Paul Marks
2014-02-25 21:07                   ` Dan Williams
2014-02-25 21:18                     ` David Miller
2014-02-26  1:29                       ` Hannes Frederic Sowa
2014-02-15  2:59 ` [RFC v2 3/4] xen-netback: use a random MAC address Luis R. Rodriguez
2014-02-17 10:29   ` [Xen-devel] " David Vrabel
2014-02-18 11:22     ` Ian Campbell
2014-02-18 21:30       ` Luis R. Rodriguez
2014-02-15  2:59 ` [RFC v2 4/4] xen-netback: skip IPv4 and IPv6 interfaces Luis R. Rodriguez
2014-02-17 14:36   ` [Xen-devel] " Zoltan Kiss
2014-02-18 20:16     ` Luis R. Rodriguez
2014-02-19  9:47       ` Ian Campbell
2014-02-17 10:27 ` [Xen-devel] [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends David Vrabel
2014-02-18 19:43   ` Luis R. Rodriguez
2014-02-19  9:48     ` Ian Campbell
2014-02-19 17:10       ` 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=53074E69.4060206@citrix.com \
    --to=zoltan.kiss@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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;
as well as URLs for NNTP newsgroup(s).