[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28285.1454103900@famine>
Date: Fri, 29 Jan 2016 13:45:00 -0800
From: Jay Vosburgh <jay.vosburgh@...onical.com>
To: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
cc: =?UTF-8?Q?Bj=c3=b8rnar_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>
Subject: Re: bonding (IEEE 802.3ad) not working with qemu/virtio
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.
-J
---
-Jay Vosburgh, jay.vosburgh@...onical.com
Powered by blists - more mailing lists