On 2025/08/13 19:28, 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, and the kernel side of the implementation has been merged
into the net-next tree; this series updates the virtio implementation to
support such a feature.
Currently the qemu 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 4-12) actually deals with
extending the features space.
The extended features are carried by fixed size uint64_t arrays,
bringing the current maximum features number to 128.
The patches use some syntactic sugar to try to minimize the otherwise
very large code churn. Specifically the extended features are boundled
in an union with 'legacy' features definition, allowing no changes in
the virtio devices not needing the extended features set.
The actual offload implementation is in patches 13 and 14 and boils down
to propagating the new offload to the tun devices and the vhost backend.
Patch 1 is a small pre-req refactor that ideally could enter the
tree separately; it's presented here in the same series to help
reviewers more easily getting the full picture, patch 2 updates to
linux headers update script to deal with annotations recently introduce
in the kernel and patch 3 is a needed linux headers update.
Tested with basic stream transfer with all the possible permutations of
host kernel/qemu/guest kernel with/without GSO over UDP tunnel support,
vs snapshots creation and restore and vs migration.
The new features are disabled by default to avoid compatibilty issues.
They could be enabled after that hw_compat_10_1 will be added, together
with the related compatiblity entries.
Based-on:
9d71108d7de139dd4f4e6efe6837cabb32bf5616.1755078918.git.pab...@redhat.com
Now everything looks good to me. For the whole series:
Reviewed-by: Akihiko Odaki <od...@rsg.ci.i.u-tokyo.ac.jp>
Regards,
Akihiko Odaki
