Hi, Some updates.
The final merged version of that code: https://github.com/openvswitch/ovs/commit/a5669fd51c9b1276ca03d54a5f069b5221915325 is not possible to backport, because it relays on a series of patches of TSO. Just tried to backport it with some code refactor, no success, all VM ports went down. Again with the mail list initial version: https://mail.openvswitch.org/pipermail/ovs-dev/2022-September/397581.html some VMs ports are UP, some still not work: status : {mode=client, status=disconnected} After looking at the mail list, it seems the initial version has some compatibility issues mentioned by Flavio Leitner. Regards, LIU Yulong On Wed, Oct 16, 2024 at 9:00 AM LIU Yulong <liuyulong...@gmail.com> wrote: > > 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
