Nikolay Aleksandrov
2016-Jan-29 21:48 UTC
bonding (IEEE 802.3ad) not working with qemu/virtio
On 01/29/2016 10:45 PM, Jay Vosburgh wrote:> Nikolay Aleksandrov <nikolay at cumulusnetworks.com> wrote: > >> On 01/25/2016 05:24 PM, Bj?rnar Ness wrote: >>> As subject says, 802.3ad bonding is not working with virtio network model. >>> >>> The only errors I see is: >>> >>> No 802.3ad response from the link partner for any adapters in the bond. >>> >>> Dumping the network traffic shows that no LACP packets are sent from the >>> host running with virtio driver, changing to for example e1000 solves >>> this problem >>> with no configuration changes. >>> >>> Is this a known problem? >>> >> [Including bonding maintainers for comments] >> >> Hi, >> Here's a workaround patch for virtio_net devices that "cheats" the >> duplex test (which is the actual problem). I've tested this locally >> and it works for me. >> I'd let the others comment on the implementation, there're other signs >> that can be used to distinguish a virtio_net device so I'm open to suggestions. >> Also feedback if this is at all acceptable would be appreciated. > > Should virtio instead provide an arbitrary speed and full duplex > to ethtool, as veth does? > > Creating a magic whitelist of devices deep inside the 802.3ad > implementation seems less desirable. >TBH, I absolutely agree. In fact here's what we've been doing: add set_settings which allows the user to set any speed/duplex and get_settings of course to retrieve that. This is also useful for testing other stuff that requires speed and duplex, not only for the bonding case. I'll add the virtio_net maintainers to the discussion, see if it's okay with everyone and I'll move to send patches once net-next opens up. Thanks!> -J > > --- > -Jay Vosburgh, jay.vosburgh at canonical.com >
From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com> Date: Fri, 29 Jan 2016 22:48:26 +0100> On 01/29/2016 10:45 PM, Jay Vosburgh wrote: >> Nikolay Aleksandrov <nikolay at cumulusnetworks.com> wrote: >> >>> On 01/25/2016 05:24 PM, Bj?rnar Ness wrote: >>>> As subject says, 802.3ad bonding is not working with virtio network model. >>>> >>>> The only errors I see is: >>>> >>>> No 802.3ad response from the link partner for any adapters in the bond. >>>> >>>> Dumping the network traffic shows that no LACP packets are sent from the >>>> host running with virtio driver, changing to for example e1000 solves >>>> this problem >>>> with no configuration changes. >>>> >>>> Is this a known problem? >>>> >>> [Including bonding maintainers for comments] >>> >>> Hi, >>> Here's a workaround patch for virtio_net devices that "cheats" the >>> duplex test (which is the actual problem). I've tested this locally >>> and it works for me. >>> I'd let the others comment on the implementation, there're other signs >>> that can be used to distinguish a virtio_net device so I'm open to suggestions. >>> Also feedback if this is at all acceptable would be appreciated. >> >> Should virtio instead provide an arbitrary speed and full duplex >> to ethtool, as veth does? >> >> Creating a magic whitelist of devices deep inside the 802.3ad >> implementation seems less desirable. >> > TBH, I absolutely agree. In fact here's what we've been doing: > add set_settings which allows the user to set any speed/duplex > and get_settings of course to retrieve that. This is also useful > for testing other stuff that requires speed and duplex, not only > for the bonding case.I also agree. Having a whitelist is just rediculous. There should be a default speed/duplex setting for such devices as well. We can pick one that will be use universally for these kinds of devices.
Sat, Jan 30, 2016 at 07:59:24AM CET, davem at davemloft.net wrote:>From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com> >Date: Fri, 29 Jan 2016 22:48:26 +0100 > >> On 01/29/2016 10:45 PM, Jay Vosburgh wrote: >>> Nikolay Aleksandrov <nikolay at cumulusnetworks.com> wrote: >>> >>>> On 01/25/2016 05:24 PM, Bj?rnar Ness wrote: >>>>> As subject says, 802.3ad bonding is not working with virtio network model. >>>>> >>>>> The only errors I see is: >>>>> >>>>> No 802.3ad response from the link partner for any adapters in the bond. >>>>> >>>>> Dumping the network traffic shows that no LACP packets are sent from the >>>>> host running with virtio driver, changing to for example e1000 solves >>>>> this problem >>>>> with no configuration changes. >>>>> >>>>> Is this a known problem? >>>>> >>>> [Including bonding maintainers for comments] >>>> >>>> Hi, >>>> Here's a workaround patch for virtio_net devices that "cheats" the >>>> duplex test (which is the actual problem). I've tested this locally >>>> and it works for me. >>>> I'd let the others comment on the implementation, there're other signs >>>> that can be used to distinguish a virtio_net device so I'm open to suggestions. >>>> Also feedback if this is at all acceptable would be appreciated. >>> >>> Should virtio instead provide an arbitrary speed and full duplex >>> to ethtool, as veth does? >>> >>> Creating a magic whitelist of devices deep inside the 802.3ad >>> implementation seems less desirable. >>> >> TBH, I absolutely agree. In fact here's what we've been doing: >> add set_settings which allows the user to set any speed/duplex >> and get_settings of course to retrieve that. This is also useful >> for testing other stuff that requires speed and duplex, not only >> for the bonding case. > >I also agree. Having a whitelist is just rediculous. > >There should be a default speed/duplex setting for such devices as well. >We can pick one that will be use universally for these kinds of devices.Exposing made up speed for veth and virtio_net sounds odd to me. User see 10000Mb/s but it makes no sense at all. It is just confusing. I believe this is bonding bug and should be fixed in there. Team works fine with virtio_net device and lacp runner.
Nikolay Aleksandrov
2016-Jan-30 11:41 UTC
bonding (IEEE 802.3ad) not working with qemu/virtio
On 01/30/2016 07:59 AM, David Miller wrote:> From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com> > Date: Fri, 29 Jan 2016 22:48:26 +0100 > >> On 01/29/2016 10:45 PM, Jay Vosburgh wrote: >>> Nikolay Aleksandrov <nikolay at cumulusnetworks.com> wrote: >>> >>>> On 01/25/2016 05:24 PM, Bj?rnar Ness wrote: >>>>> As subject says, 802.3ad bonding is not working with virtio network model. >>>>> >>>>> The only errors I see is: >>>>> >>>>> No 802.3ad response from the link partner for any adapters in the bond. >>>>> >>>>> Dumping the network traffic shows that no LACP packets are sent from the >>>>> host running with virtio driver, changing to for example e1000 solves >>>>> this problem >>>>> with no configuration changes. >>>>> >>>>> Is this a known problem? >>>>> >>>> [Including bonding maintainers for comments] >>>> >>>> Hi, >>>> Here's a workaround patch for virtio_net devices that "cheats" the >>>> duplex test (which is the actual problem). I've tested this locally >>>> and it works for me. >>>> I'd let the others comment on the implementation, there're other signs >>>> that can be used to distinguish a virtio_net device so I'm open to suggestions. >>>> Also feedback if this is at all acceptable would be appreciated. >>> >>> Should virtio instead provide an arbitrary speed and full duplex >>> to ethtool, as veth does? >>> >>> Creating a magic whitelist of devices deep inside the 802.3ad >>> implementation seems less desirable. >>> >> TBH, I absolutely agree. In fact here's what we've been doing: >> add set_settings which allows the user to set any speed/duplex >> and get_settings of course to retrieve that. This is also useful >> for testing other stuff that requires speed and duplex, not only >> for the bonding case. > > I also agree. Having a whitelist is just rediculous. > > There should be a default speed/duplex setting for such devices as well. > We can pick one that will be use universally for these kinds of devices. >Yes, that's the other thing - the default setting, from a brief grepping I see that veth uses 10Gbps, tun uses 10Mbps and batman-adv uses 10Mbps. If we add a default get_settings that can be used by virtual devices in ethtool that returns 10Gbps with the settings set like veth does sounds good to me. What do you think ? In fact they all set the same settings (apart from speed) so we can consolidate them in a single default setting init function and for the ones using different speed do something like: __ethtool_init_settings(); <- sets everything like veth would with 10Mbps speed __ethtool_cmd_speed_set(cmd, SPEED_10000); And we're done.
Michael S. Tsirkin
2016-Jan-31 14:58 UTC
bonding (IEEE 802.3ad) not working with qemu/virtio
On Fri, Jan 29, 2016 at 10:48:26PM +0100, Nikolay Aleksandrov wrote:> On 01/29/2016 10:45 PM, Jay Vosburgh wrote: > > Nikolay Aleksandrov <nikolay at cumulusnetworks.com> wrote: > > > >> On 01/25/2016 05:24 PM, Bj?rnar Ness wrote: > >>> As subject says, 802.3ad bonding is not working with virtio network model. > >>> > >>> The only errors I see is: > >>> > >>> No 802.3ad response from the link partner for any adapters in the bond. > >>> > >>> Dumping the network traffic shows that no LACP packets are sent from the > >>> host running with virtio driver, changing to for example e1000 solves > >>> this problem > >>> with no configuration changes. > >>> > >>> Is this a known problem? > >>> > >> [Including bonding maintainers for comments] > >> > >> Hi, > >> Here's a workaround patch for virtio_net devices that "cheats" the > >> duplex test (which is the actual problem). I've tested this locally > >> and it works for me. > >> I'd let the others comment on the implementation, there're other signs > >> that can be used to distinguish a virtio_net device so I'm open to suggestions. > >> Also feedback if this is at all acceptable would be appreciated. > > > > Should virtio instead provide an arbitrary speed and full duplex > > to ethtool, as veth does? > > > > Creating a magic whitelist of devices deep inside the 802.3ad > > implementation seems less desirable. > > > TBH, I absolutely agree. In fact here's what we've been doing: > add set_settings which allows the user to set any speed/duplex > and get_settings of course to retrieve that. This is also useful > for testing other stuff that requires speed and duplex, not only > for the bonding case.This looks like a very reasonable thing to do: user might have knowledge of the actual speed through some side-channel. We might also propagate it to hypervisor in the future. And this sound useful even if bonding is changed to allow DUPLEX_UNKNOWN. So please post this patch.> I'll add the virtio_net maintainers to the discussion, see if it's > okay with everyone and I'll move to send patches once net-next opens up. > > Thanks! > > > > -J > > > > --- > > -Jay Vosburgh, jay.vosburgh at canonical.com > >
On 01/29/2016 10:59 PM, David Miller wrote:> There should be a default speed/duplex setting for such devices as well. > We can pick one that will be use universally for these kinds of devices.There is at least one monitoring tool - collectl - which gets a trifle upset when the actual speed through an interface is significantly greater than the reported link speed. I have to wonder how unique it is in that regard. Doesn't mean there can't be a default, but does suggest it should be rather high. rick jones
Possibly Parallel Threads
- bonding (IEEE 802.3ad) not working with qemu/virtio
- bonding (IEEE 802.3ad) not working with qemu/virtio
- bonding (IEEE 802.3ad) not working with qemu/virtio
- bonding (IEEE 802.3ad) not working with qemu/virtio
- [PATCH net-next] virtio_net: add ethtool support for set and get of settings