On 6/26/23 16:05, David Marchand wrote: > On Mon, Jun 26, 2023 at 3:19 PM Ilya Maximets <[email protected]> wrote: >>> - if the UFO feature is "restored" in the master branch, OVS can't >>> expose CSUM if the guest negotiated UFO. >> >> Yep. IIUC, that will require un-doing/re-wrking some of the changes Mike >> did in order to restore ability to disable advertising of checksum offload. > > We need to disable VIRTIO_NET_F_CSUM (as it was before Mike series) > and make sure ECN and UFO are enabled. > This is the common point for all versions of OVS until now. > > The rest of l4 checksum series should not be impacted. > > >>>> So, we can only safely upgrade/migrate: >>>> >>>> 1 --> a >>>> 2 --> c >>>> 3 --> c >>>> >>>> "Safe" configurations: >>>> >>>> a. CSUM + TSO + ___ + ___ >>>> c. ____ + TSO + ECN + UFO >>>> >>>> Configurations we actually want: >>>> >>>> x. CSUM + TSO + ___ + ___ >>>> y. CSUM + ___ + ___ + ___ >>>> >>>> >>>> Logic can be: >>>> >>>> 1. Try 'a/x' if userspace-tso=true >>>> 2. Try 'y' if userspace-tso=false >>>> 3. Try 'c' if above failed >>>> >>>> As far as I understand we can advertise new features, but we can't remove >>>> already acked ones. So, the configuration 'c' is a catch-all for broken >>>> cases. 'y' will only be possible for new/restarted VMs. >>>> >>>> Does that make sense? >>> >>> I think you covered all cases. > > I have been thinking about it again. > > From a guest pov, is it important to support checksum offloading if > TSO is not working? > I am not sure anymore what was the reason to have only a part of these > offloading features available. > > If not, a all or nothing approach is simpler: > - try 'a/x' when userspace tso is enabled, > - go with 'c' for all other cases,
It is simpler. And I don't think checksum offload alone is actually beneficial. It even seems to degrade performance in some cases. However, it might be better to advertise clean set of features if we want to phase out incorrect ones eventually. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
