On 2025/05/23 18:43, Paolo Abeni wrote:
> 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
By the way, I did write selftests for the kernel-side change, which you
can find at:
https://lore.kernel.org/r/20250530-rss-v12-0-95d8b348de91@daynix.com/
Perhaps you may be able to steal and tweak it for the UDP tunnel feature.
Regards,
Akihiko Odaki