On Thu, Aug 28, 2025 at 9:47 AM Akihiko Odaki <od...@rsg.ci.i.u-tokyo.ac.jp> wrote: > > 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 >
Acked-by: Jason Wang <jasow...@redhat.com> Thanks
