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-c75c494b495e@daynix.com/
Thanks for the pointer