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/[email protected]/ > - Re-send the patch series becasue Patchwork don't update them. > > v2: https://lore.kernel.org/netdev/[email protected]/ > - 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/[email protected]/ > > 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.
