All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
@ 2014-02-15  2:59 Luis R. Rodriguez
  0 siblings, 0 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2014-02-15  2:59 UTC (permalink / raw)
  To: netdev; +Cc: xen-devel, Luis R. Rodriguez, linux-kernel, kvm

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:

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);
 

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(-)

-- 
1.8.5.2

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
  2014-02-19  9:48     ` Ian Campbell
@ 2014-02-19 17:10       ` Luis R. Rodriguez
  0 siblings, 0 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2014-02-19 17:10 UTC (permalink / raw)
  To: Ian Campbell; +Cc: netdev, xen-devel, David Vrabel, kvm, linux-kernel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
  2014-02-18 19:43   ` [Xen-devel] " Luis R. Rodriguez
  2014-02-19  9:48     ` Ian Campbell
@ 2014-02-19  9:48     ` Ian Campbell
  1 sibling, 0 replies; 6+ messages in thread
From: Ian Campbell @ 2014-02-19  9:48 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: netdev, xen-devel, David Vrabel, kvm, linux-kernel

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
  2014-02-17 10:27 ` [Xen-devel] " David Vrabel
@ 2014-02-18 19:43   ` Luis R. Rodriguez
  2014-02-18 19:43   ` [Xen-devel] " Luis R. Rodriguez
  1 sibling, 0 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2014-02-18 19:43 UTC (permalink / raw)
  To: David Vrabel; +Cc: netdev, linux-kernel, kvm, xen-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
  2014-02-15  2:59 Luis R. Rodriguez
  2014-02-17 10:27 ` [Xen-devel] " David Vrabel
@ 2014-02-17 10:27 ` David Vrabel
  1 sibling, 0 replies; 6+ messages in thread
From: David Vrabel @ 2014-02-17 10:27 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: netdev, Luis R. Rodriguez, linux-kernel, kvm, xen-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends
@ 2014-02-15  2:59 Luis R. Rodriguez
  2014-02-17 10:27 ` [Xen-devel] " David Vrabel
  2014-02-17 10:27 ` David Vrabel
  0 siblings, 2 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2014-02-15  2:59 UTC (permalink / raw)
  To: netdev; +Cc: xen-devel, kvm, linux-kernel, Luis R. Rodriguez

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:

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);
 

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(-)

-- 
1.8.5.2


^ permalink raw reply related	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-02-19 17:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-15  2:59 [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends Luis R. Rodriguez
  -- strict thread matches above, loose matches on Subject: below --
2014-02-15  2:59 Luis R. Rodriguez
2014-02-17 10:27 ` [Xen-devel] " David Vrabel
2014-02-18 19:43   ` Luis R. Rodriguez
2014-02-18 19:43   ` [Xen-devel] " Luis R. Rodriguez
2014-02-19  9:48     ` Ian Campbell
2014-02-19 17:10       ` Luis R. Rodriguez
2014-02-19  9:48     ` Ian Campbell
2014-02-17 10:27 ` David Vrabel

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.