[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: VIRTIO_NET_F_MTU not negotiated
From: |
Eli Cohen |
Subject: |
RE: VIRTIO_NET_F_MTU not negotiated |
Date: |
Wed, 27 Jul 2022 06:51:56 +0000 |
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.
- RE: VIRTIO_NET_F_MTU not negotiated,
Eli Cohen <=
- Re: VIRTIO_NET_F_MTU not negotiated, Michael S. Tsirkin, 2022/07/27
- RE: VIRTIO_NET_F_MTU not negotiated, Eli Cohen, 2022/07/27
- Re: VIRTIO_NET_F_MTU not negotiated, Michael S. Tsirkin, 2022/07/27
- RE: VIRTIO_NET_F_MTU not negotiated, Eli Cohen, 2022/07/27
- Re: VIRTIO_NET_F_MTU not negotiated, Michael S. Tsirkin, 2022/07/27
- RE: VIRTIO_NET_F_MTU not negotiated, Eli Cohen, 2022/07/28
- Re: VIRTIO_NET_F_MTU not negotiated, Michael S. Tsirkin, 2022/07/28
Re: VIRTIO_NET_F_MTU not negotiated, Jason Wang, 2022/07/27