Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Aaron Conole]

Maxime Coquelin <address@hidden> writes:

> On 11/18/2016 07:15 PM, Aaron Conole wrote:
>> Maxime Coquelin <address@hidden> writes:
>>
>>> This series implements Virtio spec update from Aaron Conole which
>>> defines a way for the host to expose its max MTU to the guest.
>>>
>>> Changes since RFC v1:
>>> ---------------------
>>>  - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>  - Add host_mtu property to be able to disable the feature from QEMU
>>>
>>> Maxime Coquelin (3):
>>>   vhost-user: Add new protocol feature MTU
>>>   vhost-net: Add new MTU feature support
>>>   virtio-net: Add MTU feature support
>>>
>>>  hw/net/vhost_net.c             | 11 +++++++++++
>>>  hw/net/virtio-net.c            | 14 ++++++++++++++
>>>  hw/virtio/vhost-user.c         | 11 +++++++++++
>>>  include/hw/virtio/vhost.h      |  1 +
>>>  include/hw/virtio/virtio-net.h |  1 +
>>>  include/net/vhost_net.h        |  2 ++
>>>  6 files changed, 40 insertions(+)
>>
>> I ran this with a VM, but it seems the offered maximum MTU was of value
>> 0 - is this expected with this version?  How can I change the offered
>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the world.
>
> They way I implemented it, the MTU value is to be provided by
> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
> feature for this. The sequence is:
> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
> 2. DPDK replies with providing supported features
> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>    VHOST_USER_GET_MTU resuest
> 4. DPDK replies with MTU value
>
> Does that make sense?

In the case of a vhost-user backed port, yes (so for instance, if I use
ovs+dpdk vhost-user in client or server mode).  However, what about the
non-dpdk case, where I still use a virtio-net driver in kernel and want
to have it backed with, say, a tap device in the host attached to
virbr0 (or some other bridge).  It should still pull the mtu from that
device and offer it, I think.

> Another possibility would be that we could directly pass the MTU value
> to Qemu. It may be easier to implement, and to handle migration.
> Problem is that if we do this, this is not the vSwitch that decides the
> MTU to set.

Might be better to determined the mtu by looking at what actually
provides the back-end for the networking.

> Regards,
> Maxime