From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9HqP-0005Il-Lj for qemu-devel@nongnu.org; Tue, 22 Nov 2016 15:39:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9HqL-0000rw-LV for qemu-devel@nongnu.org; Tue, 22 Nov 2016 15:39:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37086) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9Hq8-0000pN-Ny for qemu-devel@nongnu.org; Tue, 22 Nov 2016 15:39:05 -0500 Date: Tue, 22 Nov 2016 22:38:49 +0200 From: "Michael S. Tsirkin" Message-ID: <20161122223744-mutt-send-email-mst@kernel.org> References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <0105e7e3-6003-04c8-483d-30ed1208e5fc@redhat.com> <20161121182040-mutt-send-email-mst@kernel.org> <38ee6d4c-ff87-d8cc-1a1d-f45b948dcdb3@redhat.com> <796ff318-c3e9-e885-f345-7f6e48d3bb8b@redhat.com> <20161122163413-mutt-send-email-mst@kernel.org> <2d971a18-4253-1bac-4098-6879c9ccc01f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2d971a18-4253-1bac-4098-6879c9ccc01f@redhat.com> Content-Transfer-Encoding: quoted-printable 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: Aaron Conole , Jason Wang , pbonzini@redhat.com, qemu-devel@nongnu.org, yuanhan.liu@linux.intel.com On Tue, Nov 22, 2016 at 06:56:43PM +0100, Maxime Coquelin wrote: >=20 >=20 > On 11/22/2016 03:41 PM, Michael S. Tsirkin wrote: > > On Tue, Nov 22, 2016 at 09:32:01AM -0500, Aaron Conole wrote: > > > Maxime Coquelin writes: > > >=20 > > > > On 11/22/2016 05:07 AM, Jason Wang wrote: > > > > >=20 > > > > >=20 > > > > > On 2016=E5=B9=B411=E6=9C=8822=E6=97=A5 00:23, Michael S. Tsirki= n wrote: > > > > > > On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote: > > > > > > > Maxime Coquelin writes: > > > > > > >=20 > > > > > > > > On 11/18/2016 07:15 PM, Aaron Conole wrote: > > > > > > > > > Maxime Coquelin writes: > > > > > > > > >=20 > > > > > > > > > > This series implements Virtio spec update from Aaron = Conole which > > > > > > > > > > defines a way for the host to expose its max MTU to t= he guest. > > > > > > > > > >=20 > > > > > > > > > > Changes since RFC v1: > > > > > > > > > > --------------------- > > > > > > > > > > - Rebased on top of v2.8.0-rc0 (2.7.90) > > > > > > > > > > - Write MTU unconditionnaly in netcfg to avoid memo= ry leak (Paolo) > > > > > > > > > > - Add host_mtu property to be able to disable the f= eature from QEMU > > > > > > > > > >=20 > > > > > > > > > > Maxime Coquelin (3): > > > > > > > > > > vhost-user: Add new protocol feature MTU > > > > > > > > > > vhost-net: Add new MTU feature support > > > > > > > > > > virtio-net: Add MTU feature support > > > > > > > > > >=20 > > > > > > > > > > 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 chan= ge the offered > > > > > > > > > value? Sorry, I'm not as familiar with QEMU/libvirt si= de of the > > > > > > > > > world. > > > > > > > > They way I implemented it, the MTU value is to be provide= d by > > > > > > > > vhost-user process (e.g. OVS/DPDK). I added a Vhost proto= col > > > > > > > > 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 > > > > > > > >=20 > > > > > > > > Does that make sense? > > > > > > > In the case of a vhost-user backed port, yes (so for instan= ce, if I use > > > > > > > ovs+dpdk vhost-user in client or server mode). However, wh= at about the > > > > > > > non-dpdk case, where I still use a virtio-net driver in ker= nel and want > > > > > > > to have it backed with, say, a tap device in the host attac= hed to > > > > > > > virbr0 (or some other bridge). It should still pull the mt= u from that > > > > > > > device and offer it, I think. > > > > > > >=20 > > > > > > > > Another possibility would be that we could directly pass = the MTU value > > > > > > > > to Qemu. It may be easier to implement, and to handle mig= ration. > > > > > > > > Problem is that if we do this, this is not the vSwitch th= at decides the > > > > > > > > MTU to set. > > > > > > > Might be better to determined the mtu by looking at what ac= tually > > > > > > > provides the back-end for the networking. > > > > > > >=20 > > > > > > > > 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. > > > > >=20 > > > > > Or vice-versa? E.g qemu need to be notified if the MTU of tap o= r macvtap > > > > > were changed? > > >=20 > > > I think qemu should just query the MTU at start time and then > > > provide that as the value to the VM. Why specify with command line > > > option? > >=20 > > Passing it on command line is an easy way to make sure we can migrate > > the VM correctly. Also, if we get it from the backend, this requires > > backend changes. In particular, tun/macvtap will need new ioctls. S= o > > generally that's more work. >=20 > I agree this is easier for migration. >=20 > > > Seems to me like an easy way to get out of sync. > >=20 > > If we send it to the backend, that has a chance to check > > mtu and disconnect on error. >=20 > For vhost-user backend, we can send it the MTU value with a > vhost-user protocol feature. >=20 > For tun/macvtap, how do you do without adding a new ioctl ? Have management configure same mtu on the backend and in qemu. > >=20 > > > > The spec says the MTU must not be modified by the device once it = has > > > > been set. > > >=20 > > > +1 - we don't have an exchange or negotiation mechanism for this. = That > > > would require additional bits and communication, and it seems like = it > > > isn't worth it. > > >=20 > > > > I think it would require a device reset if MTU came to change. > > >=20 > > > It's just too much work for not enough gain. Guest can change MTU = all > > > it wants. Host should just know what it will limit to the guest fr= om > > > the beginning. Maybe I'm too simple, though. > > >=20 > > > -Aaron > >=20 > > I agree it's a good start. >=20 > Thanks, > Maxime