lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20160131165501-mutt-send-email-mst@redhat.com> Date: Sun, 31 Jan 2016 16:58:42 +0200 From: "Michael S. Tsirkin" <mst@...hat.com> To: Nikolay Aleksandrov <nikolay@...ulusnetworks.com> Cc: Jay Vosburgh <jay.vosburgh@...onical.com>, Bjørnar Ness <bjornar.ness@...il.com>, netdev <netdev@...r.kernel.org>, Veaceslav Falico <vfalico@...il.com>, Andy Gospodarek <gospo@...ulusnetworks.com>, Jiri Pirko <jiri@...nulli.us>, virtualization@...ts.linux-foundation.org Subject: Re: 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@...ulusnetworks.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@...onical.com > >
Powered by blists - more mailing lists