qemu-devel
[Top][All Lists]
Advanced

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

Re: VIRTIO_NET_F_MTU not negotiated


From: Michael S. Tsirkin
Subject: Re: VIRTIO_NET_F_MTU not negotiated
Date: Wed, 27 Jul 2022 03:25:01 -0400

On Wed, Jul 27, 2022 at 06:51:56AM +0000, Eli Cohen wrote:
> I found out that the reason why I could not enforce the mtu stems from the 
> fact that I did not configure max mtu for the net device (e.g. through 
> libvirt <mtu size="9000"/>).
> Libvirt does not allow this configuration for vdpa devices and probably for a 
> reason. The vdpa backend driver has the freedom to do it using its copy of 
> virtio_net_config.
> 
> The code in qemu that is responsible to allow to consider the device MTU 
> restriction is here:
> 
> static void virtio_net_device_realize(DeviceState *dev, Error **errp)
> {
>     VirtIODevice *vdev = VIRTIO_DEVICE(dev);
>     VirtIONet *n = VIRTIO_NET(dev);
>     NetClientState *nc;
>     int i;
> 
>     if (n->net_conf.mtu) {
>         n->host_features |= (1ULL << VIRTIO_NET_F_MTU);
>     }
> 
> The above code can be interpreted as follows:
> if the command line arguments of qemu indicates that mtu should be limited, 
> then we would read this mtu limitation from the device (that actual value is 
> ignored).
> 
> I worked around this limitation by unconditionally setting VIRTIO_NET_F_MTU 
> in the host features. As said, it only indicates that we should read the 
> actual limitation for the device.
> 
> If this makes sense I can send a patch to fix this.

Well it will then either have to be for vdpa only, or have
compat machinery to avoid breaking migration.

-- 
MST




reply via email to

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