Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932601AbaBUP7r (ORCPT ); Fri, 21 Feb 2014 10:59:47 -0500 Received: from mail-lb0-f176.google.com ([209.85.217.176]:64948 "EHLO mail-lb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932244AbaBUP7n (ORCPT ); Fri, 21 Feb 2014 10:59:43 -0500 MIME-Version: 1.0 In-Reply-To: <53074E69.4060206@citrix.com> References: <1392433180-16052-1-git-send-email-mcgrof@do-not-panic.com> <1392433180-16052-2-git-send-email-mcgrof@do-not-panic.com> <20140216105754.63738163@nehalam.linuxnetplumber.net> <1392803559.23084.99.camel@kazak.uk.xensource.com> <5304C13F.3030802@citrix.com> <530600C5.3070107@citrix.com> <53074E69.4060206@citrix.com> From: "Luis R. Rodriguez" Date: Fri, 21 Feb 2014 07:59:20 -0800 X-Google-Sender-Auth: nyC9iEkqBouGXG4SEmKLeD9xVBo Message-ID: Subject: Re: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge To: Zoltan Kiss Cc: Stephen Hemminger , Ian Campbell , kvm@vger.kernel.org, "netdev@vger.kernel.org" , bridge@lists.linux-foundation.org, "linux-kernel@vger.kernel.org" , xen-devel@lists.xenproject.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote: > On 20/02/14 20:01, Luis R. Rodriguez wrote: >> >> On Thu, Feb 20, 2014 at 5:19 AM, Zoltan Kiss >> 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. Unless I'm missing something the root_block flag is a bridge port primitive. This means we can't set it *until* the interface gets added to a bridge, and even then, its a knob that would be available only to the bridge. > 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. This is a good reason then to actually have an interface general specific knob to annotate to the bridge that we'd prefer to root_block by default, the alternative as you point out below is to have the xen / kvm utils to set the bridge MAC address statically, but that'll requires a userspace upgrade. I'm looking for a kernel solution that is backwards compatible with old userspace. > 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. That will certainly work for new xen / kvm util userspace. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/