On Tue, Dec 13, 2016 at 02:17:11PM +0100, Maxime Coquelin wrote: > > > On 12/13/2016 02:07 PM, Daniel P. Berrange wrote: > > 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() > > Thanks. > For QEMU part, this series adds host_mtu parameter to virtio-net device, > not to vhost netdev. Should it be reworked? > > Maxime
I applied as is for now, we can rework as necessary but people want to be able to test this.