tools/testing/selftests/net/tap.c | 281 +----- tools/testing/selftests/net/tun.c | 919 ++++++++++++++++++- tools/testing/selftests/net/tuntap_helpers.h | 602 ++++++++++++ 3 files changed, 1526 insertions(+), 276 deletions(-) create mode 100644 tools/testing/selftests/net/tuntap_helpers.h
The primary goal is to add test validation for GSO when operating over UDP tunnels, a scenario which is not currently covered. The design strategy is to extend the existing tun/tap testing infrastructure to support this new use-case, rather than introducing a new or parallel framework. This allows for better integration and re-use of existing test logic. --- v3 -> v4: - Rebase onto the latest net-next tree to resolve merge conflicts. v3: https://lore.kernel.org/netdev/cover.1767580224.git.xudu@redhat.com/ - Re-send the patch series becasue Patchwork don't update them. v2: https://lore.kernel.org/netdev/cover.1767074545.git.xudu@redhat.com/ - Addresse sporadic failures due to too early send. - Refactor environment address assign helper function. - Fix incorrect argument passing in build packet functions. v1: https://lore.kernel.org/netdev/cover.1763345426.git.xudu@redhat.com/ Xu Du (8): selftest: tun: Format tun.c existing code selftest: tun: Introduce tuntap_helpers.h header for TUN/TAP testing selftest: tun: Refactor tun_delete to use tuntap_helpers selftest: tap: Refactor tap test to use tuntap_helpers selftest: tun: Add helpers for GSO over UDP tunnel selftest: tun: Add test for sending gso packet into tun selftest: tun: Add test for receiving gso packet from tun selftest: tun: Add test data for success and failure paths tools/testing/selftests/net/tap.c | 281 +----- tools/testing/selftests/net/tun.c | 919 ++++++++++++++++++- tools/testing/selftests/net/tuntap_helpers.h | 602 ++++++++++++ 3 files changed, 1526 insertions(+), 276 deletions(-) create mode 100644 tools/testing/selftests/net/tuntap_helpers.h base-commit: c303e8b86d9dbd6868f5216272973292f7f3b7f1 -- 2.49.0
Xu Du wrote: > The primary goal is to add test validation for GSO when operating over > UDP tunnels, a scenario which is not currently covered. > > The design strategy is to extend the existing tun/tap testing infrastructure > to support this new use-case, rather than introducing a new or parallel framework. > This allows for better integration and re-use of existing test logic. > > --- > v3 -> v4: > - Rebase onto the latest net-next tree to resolve merge conflicts. > > v3: https://lore.kernel.org/netdev/cover.1767580224.git.xudu@redhat.com/ > - Re-send the patch series becasue Patchwork don't update them. > > v2: https://lore.kernel.org/netdev/cover.1767074545.git.xudu@redhat.com/ > - Addresse sporadic failures due to too early send. > - Refactor environment address assign helper function. > - Fix incorrect argument passing in build packet functions. > > v1: https://lore.kernel.org/netdev/cover.1763345426.git.xudu@redhat.com/ > > Xu Du (8): > selftest: tun: Format tun.c existing code We generally don't do such refactoring changes. But in this case for a test and when the changes are minimal, it's ok. Thanks for pulling then into a separate commit. > selftest: tun: Introduce tuntap_helpers.h header for TUN/TAP testing > selftest: tun: Refactor tun_delete to use tuntap_helpers > selftest: tap: Refactor tap test to use tuntap_helpers > selftest: tun: Add helpers for GSO over UDP tunnel > selftest: tun: Add test for sending gso packet into tun > selftest: tun: Add test for receiving gso packet from tun > selftest: tun: Add test data for success and failure paths > > tools/testing/selftests/net/tap.c | 281 +----- > tools/testing/selftests/net/tun.c | 919 ++++++++++++++++++- > tools/testing/selftests/net/tuntap_helpers.h | 602 ++++++++++++ > 3 files changed, 1526 insertions(+), 276 deletions(-) > create mode 100644 tools/testing/selftests/net/tuntap_helpers.h That's a lot of code, also to maintain long term. Is there an alternative that has less code churn? For instance, can the new netlink code be replaced by YNL, whether in C or called from a script? For instance patch 5 which sets up an env, is probably more concisely written as a script. That may or may not work with the existing KUnit framework. Iff not, it would be better if the code moved out of existing files into tuntap_helpers.h is moved in a separate NOOP move patch. Such as netlink (e.g., rtattr_add) and the build_.. functions.
On Tue, 06 Jan 2026 17:14:05 -0500 Willem de Bruijn wrote: > For instance, can the new netlink code be replaced by YNL, whether in > C or called from a script? +1 looks like YNL is already used in net/ tests, and it supports the operations in question, so that's a much better direction. Please let us (YNL maintainers) know if there's anything missing or not working, IDK how much use the rtnetlink support in YNL is getting.
On Wed, Jan 7, 2026 at 6:58 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Tue, 06 Jan 2026 17:14:05 -0500 Willem de Bruijn wrote: > > For instance, can the new netlink code be replaced by YNL, whether in > > C or called from a script? > > +1 looks like YNL is already used in net/ tests, and it supports > the operations in question, so that's a much better direction. > Please let us (YNL maintainers) know if there's anything missing > or not working, IDK how much use the rtnetlink support in YNL is > getting. > Thank you for the suggestion. I am looking into replacing the netlink with YNL to reduce code. But after reviewing rt-link.rst, I found that rt-link currently lacks support for VXLAN. Would more significant changes to the patch be acceptable if I switch to Geneve to leverage YNL? -- Regards, Xu -- Xu Du Quality Engineer, RHEL Network QE Raycom, Beijing, China
Xu Du wrote: > On Wed, Jan 7, 2026 at 6:58 AM Jakub Kicinski <kuba@kernel.org> wrote: > > > > On Tue, 06 Jan 2026 17:14:05 -0500 Willem de Bruijn wrote: > > > For instance, can the new netlink code be replaced by YNL, whether in > > > C or called from a script? > > > > +1 looks like YNL is already used in net/ tests, and it supports > > the operations in question, so that's a much better direction. > > Please let us (YNL maintainers) know if there's anything missing > > or not working, IDK how much use the rtnetlink support in YNL is > > getting. > > > > Thank you for the suggestion. I am looking into replacing the netlink > with YNL to reduce code. But after reviewing rt-link.rst, I found that > rt-link currently lacks support for VXLAN. Would more significant changes > to the patch be acceptable if I switch to Geneve to leverage YNL? These are only changes to the new code in your series. SGTM. I assume it is not a significant burden as the two are fairly similar. Is that correct? Eventually it may be nice to have VXLAN support in YNL akin to Geneve support. But sounds like a separate goal.
On Tue, 6 Jan 2026 09:35:13 +0800 Xu Du wrote: > v3 -> v4: > - Rebase onto the latest net-next tree to resolve merge conflicts. I just told you not to repost in less than 24h. As a punishment if there's a v5 please wait until the next week with posting it.
Hi Jakub, I'm sorry for the trouble. I actually resent the patch before receiving your email. I will carefully review the maintainer-netdev documentation you provided and ensure that I adopt better practices moving forward. Thank you for your guidance. On Tue, Jan 6, 2026 at 9:57 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Tue, 6 Jan 2026 09:35:13 +0800 Xu Du wrote: > > v3 -> v4: > > - Rebase onto the latest net-next tree to resolve merge conflicts. > > I just told you not to repost in less than 24h. > As a punishment if there's a v5 please wait until the next week > with posting it. > -- Regards, Xu -- Xu Du Quality Engineer, RHEL Network QE Raycom, Beijing, China
© 2016 - 2026 Red Hat, Inc.