Maxime Coquelin <maxime.coque...@redhat.com> writes: > On 11/18/2016 07:15 PM, Aaron Conole wrote: >> Maxime Coquelin <maxime.coque...@redhat.com> 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
