On 5/23/25 9:19 AM, Akihiko Odaki wrote: > On 2025/05/21 20:33, Paolo Abeni wrote: >> Some virtualized deployments use UDP tunnel pervasively and are impacted >> negatively by the lack of GSO support for such kind of traffic in the >> virtual NIC driver. >> >> The virtio_net specification recently introduced support for GSO over >> UDP tunnel, this series updates the virtio implementation to support >> such a feature. >> >> One of the reasons for the RFC tag is that the kernel-side >> implementation has just been shared upstream and is not merged yet, but >> there are also other relevant reasons, see below. >> >> Currently, the kernel virtio support limits the feature space to 64 bits, >> while the virtio specification allows for a larger number of features. >> Specifically, the GSO-over-UDP-tunnel-related virtio features use bits >> 65-69; the larger part of this series (patches 2-11) actually deals with >> the extended feature space. >> >> I tried to minimize the otherwise very large code churn by limiting the >> extended features support to arches with native 128 integer support and >> introducing the extended features space support only in virtio/vhost >> core and in the relevant device driver. > > What about adding another 64-bit integer to hold the high bits? It makes > adding the 128-bit integer type to VMState and properties and > CONFIG_INT128 checks unnecessary.
I did a few others implementation attempts before the current one. The closes to the above proposal I tried was to implement virtio_features_t as fixed size array of u64. A problem a found with that approach is that it requires a very large code churn, as ~ every line touching a feature related variable should be modified. Let me think a little bit on this other option (I hope to avoid discarding a lot of work here). >> The actual offload implementation is in patches 12-16 and boils down to >> propagating the new offload to the tun devices and the vhost backend. >> >> Tested with basic stream transfer with all the possible permutations of >> host kernel/qemu/guest kernel with/without GSO over UDP tunnel support >> and vs snapshots creation and restore. >> >> Notably this does not include (yet) any additional tests. Some guidance >> on such matter would be really appreciated, and any feedback about the >> features extension strategy would be more than welcome! > > My proposal to add a feature to tap devices[1] simply omitted tests and > I wrote simple testing scripts for my personal usage. As you can see, > there is no testing code that covers tap devices, unfortunately, and I > think adding one takes significant effort. > > [1] https://patchew.org/QEMU/20250313-hash-v4-0-c75c494b4...@daynix.com/ Thanks for the pointer Paolo
