On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote: > 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
Right. So in case it's not vhost-user, I would say it has to be specified from QEMU command line. It's probably easier to do the same everywhere, and just send the MTU from qemu to backend. -- MST
