mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anton Danilov <littlesmilingcloud@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, David Ahern <dsahern@kernel.org>,
	Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next 03/11] selftests: net: add a test for the tunnel RX drop reasons
Date: Sun, 13 Sep 2026 06:31:51 +0300	[thread overview]
Message-ID: <20260913033213.873609-1-littlesmilingcloud@gmail.com> (raw)
In-Reply-To: <20260902184549.63f37d04@kernel.org>

On Wed, 2 Sep 2026 18:45:49 -0700 Jakub Kicinski wrote:
> Completely unclear to me what the value of the tests you're adding is.
> Please look judiciously at the generated code

Dropped all three selftest patches in v2.

What they did: bring up two namespaces joined by veth, build a tunnel
pair that disagrees in one specific way, send traffic and read the
reason back from the skb:kfree_skb tracepoint.  It is how I check that
each path I convert reports what its commit message claims, and it is
what caught six paths in an earlier revision of this series that still
freed the skb with SKB_NOT_DROPPED_YET.  That value is in writing the
series, though, and does not by itself justify 346 lines in
selftests/net.

If such a test is wanted at all, I would rather come back to it
separately, once the conversion has landed, and in a smaller form:

 - perf record -e skb:kfree_skb and perf script, the way
   openvswitch.sh already does it, instead of driving a trace instance
   by hand;
 - only the cases that are not evident from reading the code: a peer
   that reboots and restarts its sequence number, two ends configured
   with different options, plus a control case where nothing is
   dropped;
 - every case tied to the function the drop has to come from, so that
   the same reason reported by unrelated code cannot make it pass.

Is that worth having, or do you consider drop reason coverage out of
scope for selftests/net?

  reply	other threads:[~2026-09-13  3:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 21:51 [PATCH net-next 00/11] tunnels: add core and gre " Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 01/11] ip_tunnel: add drop reasons to the generic RX path Anton Danilov
2026-09-03  1:47   ` Jakub Kicinski
2026-09-13  3:31     ` Anton Danilov
2026-09-03  1:47   ` Jakub Kicinski
2026-09-13  3:31     ` Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 02/11] ip6_tunnel: " Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 03/11] selftests: net: add a test for the tunnel RX drop reasons Anton Danilov
2026-09-03  1:45   ` Jakub Kicinski
2026-09-13  3:31     ` Anton Danilov [this message]
2026-08-31 21:51 ` [PATCH net-next 04/11] gre: make gre_parse_header() report a drop reason Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 05/11] ip_gre: add drop reasons to the RX path Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 06/11] ip6_gre: " Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 07/11] selftests: net: cover the GRE specific drop reasons Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 08/11] ip_tunnel: add drop reasons to the transmit path Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 09/11] ip_gre: " Anton Danilov
2026-08-31 21:51 ` [PATCH net-next 10/11] ip6_tunnel: " Anton Danilov
2026-09-03  1:43   ` Jakub Kicinski
2026-08-31 21:51 ` [PATCH net-next 11/11] selftests: net: cover the tunnel transmit drop reasons Anton Danilov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260913033213.873609-1-littlesmilingcloud@gmail.com \
    --to=littlesmilingcloud@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®