From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGmnf-0000ye-DO for qemu-devel@nongnu.org; Tue, 13 Dec 2016 08:07:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cGmnb-0005gk-J3 for qemu-devel@nongnu.org; Tue, 13 Dec 2016 08:07:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60228) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cGmnb-0005gX-BQ for qemu-devel@nongnu.org; Tue, 13 Dec 2016 08:07:15 -0500 Date: Tue, 13 Dec 2016 13:07:07 +0000 From: "Daniel P. Berrange" Message-ID: <20161213130707.GH28416@redhat.com> Reply-To: "Daniel P. Berrange" References: <20161210153038.9184-1-maxime.coquelin@redhat.com> <20161212100236.GA15611@redhat.com> <20161212103432.GH15611@redhat.com> <9523b995-33a6-80a5-9e6e-e0dc1942578f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9523b995-33a6-80a5-9e6e-e0dc1942578f@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 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, aconole@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com, fbl@redhat.com, mlureau@redhat.com, ktraynor@redhat.com On Tue, Dec 13, 2016 at 02:04:52PM +0100, Maxime Coquelin wrote: > > > On 12/12/2016 11:34 AM, Daniel P. Berrange wrote: > > On Mon, Dec 12, 2016 at 11:12:56AM +0100, Maxime Coquelin wrote: > > > Hi Daniel, > > > > > > On 12/12/2016 11:02 AM, Daniel P. Berrange wrote: > > > > On Sat, Dec 10, 2016 at 04:30:35PM +0100, Maxime Coquelin wrote: > > > > > Thanks for the reviews, > > > > > > > > > > This series implements Virtio spec update from Aaron Conole which > > > > > defines a way for the host to expose its max MTU to the guest. > > > > > > > > > > "host_mtu" parameter is added to provide QEMU with the MTU value, > > > > > and the backend, if supported, gets notified of the MTU value when the > > > > > MTU feature neogotiation succeeds. > > > > > > > > > > Only user backend currently supports MTU notification. A new protocol > > > > > feature has been implemented for sending MTU value to the backend. > > > > > > > > > > For kernel backend, it is expected the management tool also configures > > > > > the tap/macvtap interface with same MTU value. > > > > > Daniel, I would be interrested about your feedback on this implementation > > > > > from management tool point of view. > > > > > > > > I can't give real feedback yet, as I'm not seeing clear information on > > > > what problem this series is designed to solve.... > > > > > > Right, I agree it is missing a bit of context here, I'll add more about > > > the background in next revision. > > > > > > The goal of this series is to address two things: > > > 1. Providing a way for the guests to use the same MTU as the host, > > > in order to have a consistent MTU value across the infrastructure. > > > > Ok, currently libvirt sets the MTU of the tap device based on the MTU > > of the device it will be attached to. This change means we need to pass > > that MTU value into QEMU via the -netdev command line so it can inform > > the guest what the MTU is. > Nice, do you have a pointer on where this is done in QEMU? Its in libvirt code via virNetDevSetMTUFromDevice() Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|