From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7oja-0007Rc-Us for qemu-devel@nongnu.org; Fri, 18 Nov 2016 14:22:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7ojW-0002nW-E8 for qemu-devel@nongnu.org; Fri, 18 Nov 2016 14:22:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40688) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7ojW-0002mk-8A for qemu-devel@nongnu.org; Fri, 18 Nov 2016 14:21:58 -0500 From: Aaron Conole References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <0105e7e3-6003-04c8-483d-30ed1208e5fc@redhat.com> Date: Fri, 18 Nov 2016 14:21:54 -0500 In-Reply-To: <0105e7e3-6003-04c8-483d-30ed1208e5fc@redhat.com> (Maxime Coquelin's message of "Fri, 18 Nov 2016 19:52:30 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Maxime Coquelin Cc: mst@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com Maxime Coquelin writes: > On 11/18/2016 07:15 PM, Aaron Conole wrote: >> Maxime Coquelin 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