Hi Mike, thank you for the information. 1) The ovs had no settings of "userspace-tso-enable" ever, the default value should be false. I've tried to set the userspace-tso-enable="false", but without any improvements. 2) In the guest VM, all VMs had the settings of "generic-receive-offload: on" and "other-offload-features-* off". The only difference is the bit setting of VIRTIO_NET_F_HOST_UFO. 3) I will try to backport that patch to see if we can overcome this.
Regards, LIU Yulong On Wed, Oct 16, 2024 at 12:00 AM Mike Pattrick <m...@redhat.com> wrote: > > On Tue, Oct 15, 2024 at 5:13 AM LIU Yulong <liuyulong...@gmail.com> wrote: > > > > Hi community and experts, > > > > We have recently attempted to upgrade OVS 2.12+DPDK 18.11 to OVS > > 2.13.11+DPDK 19.11.14. And then we encountered a state where some > > virtual machine network cards are down, and users were not able to > > start the network cards inside the guest VM. > > After investigating, we found that qemu reported errors (many many > > times) , which means virtIO feature negotiation failed: > > 2024-10-15T06:25:16.986398Z qemu-kvm: failed to init vhost_net for queue 0 > > vhost lacks feature mask 16384 for backend > > > > Which means the backend of virtIO, aka vhostuser, does not support > > 16384 (the 14th in feature bits). > > Source code definition bit: > > #define VIRTIO_NET_F_HOST_UFO 14 /* Host can handle UFO in. */ > > > > In the same host, if the HOST_UFO bit of some virtual machines is set > > to 1, the network card cannot start. While some are 0, it can be > > started. > > > > We found some useful series of links: > > https://mail.openvswitch.org/pipermail/ovs-dev/2023-June/405829.html > > https://bugzilla.redhat.com/show_bug.cgi?id=1845488#c5 > > > > The conclusion seems to be that such hot upgrade is impossible to > > achieve. If the guest VM is not restarted or the network card is not > > redo hot unplug and plug, the user's network card will not be able to > > work properly. This situation is unacceptable for a cloud environment > > because we cannot require all user VMs to be restarted. > > > > Therefore, I'm asking here if there is a possible work around to > > achieve such an upgrade? > > Hello Liu, > > 2.13 is a very old version of OVS and is not receiving updates > anymore. There was a 2023 patch that might address this issue, but it > was never backported to 2.13: > https://mail.openvswitch.org/pipermail/ovs-dev/2022-September/397581.html > > Looking at the 2.13 source code, it looks like UFO is only set as an > unsupported feature if userspace TSO is enabled. Do you have userspace > TSO enabled? If so, disabling it for the upgrade may improve your > results. > > > Cheers, > M > > > > > Regards, > > LIU Yulong > > > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
