Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote: Ah yes, I assume you meant when multiple devices can report different thing even if with the same frontend / device type. QOM should work, or anything that can identify a device, e.g. with id / instance_id attached along with the device class. One thing that I still don't know how it works is how it interacts with new hosts being added. This idea is based on the fact that the cluster is known before starting any VM. However in reality I think it can happen when VMs started with a small cluster but then cluster extended, when the -merge-platform has been done on the smaller set. Personally I don't worry too much on other offload bits besides USO* so far if we have them ON for longer time. My wish was that they're old good kernel features mostly supported everywhere who runs QEMU, then we're good. And I definitely worry about future offload features, or any feature that may probe host like this and auto-OFF: I hope we can do them on the safe side starting from day1. So I don't know whether we should do that to USO* only or all. But I agree with you that'll definitely be cleaner. On the details of how to turn them off properly.. Taking an example if we want to turn off all the offload features by default (or simply we replace that with USO-only).. Upstream machine type is flexible to all kinds of kernels, so we may not want to regress anyone using an existing machine type even on perf, especially if we want to turn off all. In that case we may need one more knob (I'm assuming this is virtio-net specific issue, but maybe not; using it as an example) to make sure the old machine types perfs as well, with: - x-virtio-net-offload-enforce When set, the offload features with value ON are enforced, so when the host doesn't support a offload feature it will fail to boot, showing the error that specific offload feature is not supported by the virtio backend. When clear, the offload features with value ON are not enforced, so these features can be automatically turned OFF when it's detected the backend doesn't support them. This may bring best perf but has the risk of breaking migration. With that, - On old machine types (compat properties): - set "x-virtio-net-offload-enforce" OFF - set all offload features ON - On new machine types (the default values): - set "x-virtio-net-offload-enforce" ON - set all offload features OFF And yes, we can do that until 9.2, but with above even 9.1 should be safe to do. 9.2 might be still easier just to think everything through again, after all at least USO was introduced in 8.2 so not a regress in 9.1. If it'll become a device property, there's still the trick / concern where no-cross-migrate could conflict with the other offload feature that was selected explicilty by an user (e.g. no-cross-migrate=ON + uso=OFF). Thanks, -- Peter Xu