qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v3 0/3] virtio-net: Add support to MTU feature


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC v3 0/3] virtio-net: Add support to MTU feature
Date: Wed, 30 Nov 2016 15:42:32 +0200

On Wed, Nov 30, 2016 at 01:16:59PM +0100, Maxime Coquelin wrote:
> 
> 
> On 11/30/2016 12:23 PM, Jason Wang wrote:
> > 
> > 
> > On 2016年11月30日 18:10, Maxime Coquelin wrote:
> > > This series implements Virtio spec update from Aaron Conole which
> > > defines a way for the host to expose its max MTU to the guest.
> > > 
> > > This third version re-desings how MTU value is provided to QEMU.
> > > Now, 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.
> > > Aaron, Kevin, Flavio, do you confirm this works for OVS if DPDK vhost lib
> > > adds needed API to get the MTU value?
> > > 
> > > 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 believe we want management tool to configure both kernel and user
> > backends.
> 
> Yes, I think you are right.
> 
> The vhost-user protocol feature would in this case be used to ensure
> consistency.
> 
> Does that make sense, or we should just drop VHOST_USER_SET_MTU?
> 
> Thanks,
> Maxime


It doesn't hurt to have a feature and if set send mtu to backend,
to verify that it can support that mtu.
But we don't need to require that feature, if not supported
we can just assume mtu is correct.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]