Message ID | 1392433180-16052-1-git-send-email-mcgrof@do-not-panic.com |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
On 15/02/14 02:59, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > This v2 series changes the approach from my original virtualization > multicast patch series [0] by abandoning completely the multicast > issues and instead generalizing an approach for virtualization > backends. There are two things in common with virtualization > backends: > > 0) they should not become the root bridge > 1) they don't need ipv4 / ipv6 interfaces Why? There's no real difference between a backend network device and a physical device (from the point of view of the backend domain). I do not think these are intrinsic properties of backend devices. I can see these being useful knobs for administrators (or management toolstacks) to turn on, on a per-device basis. David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 17, 2014 at 2:27 AM, David Vrabel <david.vrabel@citrix.com> wrote: > On 15/02/14 02:59, Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" <mcgrof@suse.com> >> >> This v2 series changes the approach from my original virtualization >> multicast patch series [0] by abandoning completely the multicast >> issues and instead generalizing an approach for virtualization >> backends. There are two things in common with virtualization >> backends: >> >> 0) they should not become the root bridge >> 1) they don't need ipv4 / ipv6 interfaces > > Why? There's no real difference between a backend network device and a > physical device (from the point of view of the backend domain). I do > not think these are intrinsic properties of backend devices. Let me clarify the original motivation as that can likely help explain how I ended up with this patch series. SUSE has had reports of xen backend interfaces ending up with duplicate address notification filling up logs on systems with a series of guests, these reports go back to 2006. This was root caused to DAD on IPv6 interfaces, and a work around implemented to disable DAD [0] on multicast links. Even though this patch as a work around should not be applicable anymore given that since the xen-netback upstreaming since 2.6.39 ether_setup is used and that enables the multicast flag, we should try ensure the issue doesn't creep up anymore. As per the IPv6 RFCs and Linux IPv6 implementation -- DAD should be triggered even in the case of manual IP configuration and when the link goes up, as such SLAAC will always take place on IPv6 interfaces. Although not documented upon my review I determined the original issue could also be attributed to the corner case documented on Appendix A of RFC 4862 [1] and this could be more prevalent for xen-netback given we stuck to the same MAC address for all xen-netback interfaces. I first tried to generalize the work around and address the multicast case requirement for IPv6 [2], and explicitly disabling multicast on xen-netback. Although this approach could likely be generalized further by taking into account for NBMA links by checking dev->type I determined we didn't need IPv6 interfaces at all on the xent-netback interfaces. This lead me to further review if we even needed IPv4 interfaces as well, and it turns out we do not. New motivation: removing IPv4 and IPv6 from the backend interfaces can save up a lot of boiler plate run time code, triggers from ever taking place, and simplifying the backend interaces. If there is no use for IPv4 and IPv6 interfaces why do we have them? Note: I have yet to test the NAT case. > I can see these being useful knobs for administrators (or management > toolstacks) to turn on, on a per-device basis. Agreed but these knobs don't even exist for drivers yet, let alone for system administrators. I certainly can shoot for another series to let administrators configure this as a preference but -- if we know a driver won't need IPv4 and IPv6 interfaces why not just allow drivers to disable them all together? Consider the simplification of the interfaces on the host. [0] https://gitorious.org/opensuse/kernel-source/source/8e16582178a29b03e850468004a47e7be5ed3005:patches.xen/ipv6-no-autoconf [1] http://tools.ietf.org/html/rfc4862 [2] http://marc.info/?l=linux-netdev&m=139207142110536&w=2 Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2014-02-18 at 11:43 -0800, Luis R. Rodriguez wrote: > > New motivation: removing IPv4 and IPv6 from the backend interfaces can > save up a lot of boiler plate run time code, triggers from ever taking > place, and simplifying the backend interaces. If there is no use for > IPv4 and IPv6 interfaces why do we have them? Note: I have yet to test > the NAT case. I think you need to do that test that before you can unequivocally state that there is no use for IPv4/6 interfaces here. Ian. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 19, 2014 at 1:48 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2014-02-18 at 11:43 -0800, Luis R. Rodriguez wrote: >> >> New motivation: removing IPv4 and IPv6 from the backend interfaces can >> save up a lot of boiler plate run time code, triggers from ever taking >> place, and simplifying the backend interaces. If there is no use for >> IPv4 and IPv6 interfaces why do we have them? Note: I have yet to test >> the NAT case. > > I think you need to do that test that before you can unequivocally state > that there is no use for IPv4/6 interfaces here. Agreed but note that Zoltan stated that in the routing case IPv4 or IPv6 addresses can be used on the backends, so that already rules that out. Unless of course we want to enable this by default (for simplicity) and have userpace poke to get out IPv4 / IPv6 if by default no interfaces were enabled. Even though backend interfaces would stand to gain on the average situation from this simplicity I don't think the userspace requirements are worth it. Someone with hundreds of guests (that don't do routing on the backend as clarified by Zoltan) may want to test my patch though to see if there's any reasonable cuts on getting these guests up and running. Anyone itching for the above? Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 44c4db8..19b967e 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -940,6 +940,7 @@ static void tun_net_init(struct net_device *dev) ether_setup(dev); dev->priv_flags &= ~IFF_TX_SKB_SHARING; dev->priv_flags |= IFF_LIVE_ADDR_CHANGE; + dev->priv_flags |= IFF_BRIDGE_NON_ROOT | IFF_SKIP_IP; eth_hw_addr_random(dev);
From: "Luis R. Rodriguez" <mcgrof@suse.com> This v2 series changes the approach from my original virtualization multicast patch series [0] by abandoning completely the multicast issues and instead generalizing an approach for virtualization backends. There are two things in common with virtualization backends: 0) they should not become the root bridge 1) they don't need ipv4 / ipv6 interfaces Both qemu's usage of TAP interfaces and xen-netback's driver avoid getting their interfaces added to the root bridge by using a high MAC address. Lets just generalize the solution by making this a flag. The skipping of IPv4 / IPv6 interfaces is an optimization I observed possible while studying the xen-netback in a shared physical bridge environment. I haven't been able to test the NAT environment so I appreciate it if someone can test these patches for that case if I don't get to it eventually. The same flags can be embraced by TAP interfaces when needed, I tested this as a temporary patch as follows: a proper followup would be to specify the flags during open() or any way prior, just to register_netdevice(). Before that is done we'd need to evaluate all qemu use cases of the TAP interfaces both for the xen HVM case (which tests fine for me) and for KVM's use cases on both shared physical and in the NAT case. That is, test the above patch and this series for all KVM / xen use cases. [0] http://marc.info/?l=linux-netdev&m=139207142110536&w=2 Luis R. Rodriguez (4): bridge: enable interfaces to opt out from becoming the root bridge net: enables interface option to skip IP xen-netback: use a random MAC address xen-netback: skip IPv4 and IPv6 interfaces drivers/net/xen-netback/interface.c | 14 +++++--------- include/uapi/linux/if.h | 2 ++ net/bridge/br_if.c | 2 ++ net/bridge/br_private.h | 1 + net/bridge/br_stp_if.c | 2 ++ net/ipv4/devinet.c | 3 +++ net/ipv6/addrconf.c | 6 ++++++ 7 files changed, 21 insertions(+), 9 deletions(-)