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: Aaron Conole
Subject: Re: [Qemu-devel] [RFC v3 0/3] virtio-net: Add support to MTU feature
Date: Mon, 05 Dec 2016 11:11:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> writes:

> 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.

Sorry for late reply - I agree, this is fine.



reply via email to

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