From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8rNF-0008Li-4w for qemu-devel@nongnu.org; Mon, 21 Nov 2016 11:23:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8rNB-0003ms-6G for qemu-devel@nongnu.org; Mon, 21 Nov 2016 11:23:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46270) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8rNA-0003mV-T1 for qemu-devel@nongnu.org; Mon, 21 Nov 2016 11:23:13 -0500 Date: Mon, 21 Nov 2016 18:23:10 +0200 From: "Michael S. Tsirkin" Message-ID: <20161121182040-mutt-send-email-mst@kernel.org> References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <0105e7e3-6003-04c8-483d-30ed1208e5fc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Aaron Conole Cc: Maxime Coquelin , pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote: > 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 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