Re: [PATCH RFC 00/16] virtio: introduce support for GSO over UDP tunnel

[Paolo Abeni <pabeni@redhat.com>]

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

Paolo