From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F66830F546 for ; Tue, 6 Jan 2026 22:14:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767737651; cv=none; b=b8MPk4igV9CZzB5PXQ9ZoCYo6hamJ4kNuAlt/ukqAIKI1D5Fe7uzRdy48CPxcoWRocabtXYhq4dI1NYByiI43614Dq8wm+4QJcSlkrmTH27M/Z+YP5Kua87QUT2YkkaQuSt3IL7IdCGVVZJrBQ57lE5OrdcWxl1Q4oboJBQr8MM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767737651; c=relaxed/simple; bh=BKVgYfecIlwaEfG2yIYO31DYcPw5TzZyRT9d/OzC59g=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=emtZBLAaN0kqUgxNn3rhi8oZ4QW+2vxl3LtrS4hJ+yOk2lZaxQPqpxQo9imztO6cUBHaG+fc7dPKNRbPBroRQVSfaDoEPvF5b9sjNy1gW3vqb1K4qSSwZv5G+4E6uok+OP7ZyhNgj229WnwNCYa5bLGPWT001pW0jvK1gjCBmgI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jjobh6QU; arc=none smtp.client-ip=209.85.128.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jjobh6QU" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-78fba1a1b1eso5031357b3.1 for ; Tue, 06 Jan 2026 14:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767737647; x=1768342447; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=bXTAUGOjyeJOlTuz196szGLfvzOOt7OotlkuHVJJ76k=; b=jjobh6QUB9YiJCKjS5JSiCLsJeXUFqsG5JMYxzEkuQjNwWWcaTAu24fGx4DI+boXha MCRvD4W06vqO3EE2woQuV4/R88qWeswUeBnzhn1QbHJ5CP+/DfrUt5lq/X3tPTAerqIX xbK+FGeJoWay9Xa8B5xjlD8hkhXUSpDDxskTeog0qT0q2A2lf4VLfHn0myaZYvb0lYII fARBHrFCmhnIIMOCxTw1DO5OeIxeSpciRqPLl6iwPhHpmHuT2fsYKHkQ853RtCzIq2by E0C6fm1SP/36xxR4JYbx+gVPME+2qyHcjE9QsnIwPN+YZOgfvwgvB/1eqaJW8COpCwKw 8/1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767737647; x=1768342447; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bXTAUGOjyeJOlTuz196szGLfvzOOt7OotlkuHVJJ76k=; b=hb5VVGO6uLi8AvXj8aTE/13MNhxT3nSkh5oJD54GMQzIBhBBbRWi/n1QpoSMYXdZDW BxHGk+ppZxDRgnMUvxTtvDhImH+kqaT+mFs7u5yMPmPUbNiZbcBwElSDsEinkgJ+lBEj Cu4SSE4RkQh5GQ2Rk7/+8TmNVQl2uN/LKU9cvIVLMQUlKhj5dAzpGIhsKJudXrM1qFWB 3z84giEb/3qsQu06KpgjPV9e8CxAVEq73MKvMVxPaYnVD4JY0GK1KIYzCtDC5KOBU8u7 q2Qcs3XnTyrtaWsluttUhhlvflZ5ylZJYcC8JfUZQSsSkjvbcS1lnDCLapTHwn90EuOT f/Uw== X-Forwarded-Encrypted: i=1; AJvYcCXtm8xo6NsZ8xTrOvYyYu9CjQOYpb+r39MiifNNLecT30GHSSASL+EU7GvutCp7k1EucvhJImkA451M9BY=@vger.kernel.org X-Gm-Message-State: AOJu0YybLW3NT2l2rKr3IeOvaFkSqcGdevkmVybqPb5174GuyrcCEd80 Hs04wf5iG/iJtiPJiketVIp7v2sDq1rIoa+MydH9fktpRWq1587Bj/R3 X-Gm-Gg: AY/fxX68PoSv/2hP2OHAGBCjKWnokVWXBJunFKZSj2+C2rwR9iJXQO+uisnLf38JewL Zhj/uSky8IZql0t+GrIoDttWevIzr1pu1rLNuwRzmBhADeGYdbkFFuWOnOcPr3hdGS2P2gIKs7f r6RY8Hz25jChn7+W+5fXeYXlOwF3mHhfQSV1HrDpZjpb1LeVVEgfRF49K4Nx/s2AonO8eSXmV2E X+B0BzlK2b3klSb3zhxHp1Q32tCY/rZ4Q5B60+t1/xThT2mj/9zGN0pFggcBUdkCO0vE0lAl3tq 1kDVTsKmzHAVqnN/NDK6PXObXS8fcbQ71gX00/VFxbDJ3sBm9W6BJSoShnPPb7VPxPqcrdxwplh u6DQavJnCWE/P5+yiZILyy7Hzfn5LlH3DGr1lIewPFlOS6dBW+fy7gILnZfJOnDtTr8W4e5c222 Lkrf/3/HFi8SbkcEYgBQlp357vNSx25CakD0XsciA7/iJTJEtpp/tfW9SkEJU= X-Google-Smtp-Source: AGHT+IFVw2/A2IyvOueA9fhhC+wh3ph13++iKFZyzR0whc4WRr2nxsaHNxNq0kyCG35wbd92xWDOPQ== X-Received: by 2002:a05:690e:d8a:b0:644:6c19:8a26 with SMTP id 956f58d0204a3-647166aa310mr513038d50.19.1767737646993; Tue, 06 Jan 2026 14:14:06 -0800 (PST) Received: from gmail.com (250.4.48.34.bc.googleusercontent.com. [34.48.4.250]) by smtp.gmail.com with UTF8SMTPSA id 956f58d0204a3-6470d89d607sm1338464d50.12.2026.01.06.14.14.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 14:14:06 -0800 (PST) Date: Tue, 06 Jan 2026 17:14:05 -0500 From: Willem de Bruijn To: Xu Du , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, shuah@kernel.org Cc: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: In-Reply-To: References: Subject: Re: [PATCH net-next v4 0/8] selftest: Extend tun/virtio coverage for GSO over UDP tunnel Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.