netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
	ncardwell@google.com, shuah@kernel.org,
	linux-kselftest@vger.kernel.org, fw@strlen.de,
	Willem de Bruijn <willemb@google.com>,
	"Matthieu Baerts (NGI0)" <matttbe@kernel.org>,
	martineau@kernel.org
Subject: Re: [PATCH net-next RFC] selftests/net: integrate packetdrill with ksft
Date: Wed, 28 Aug 2024 14:00:35 -0700	[thread overview]
Message-ID: <20240828140035.4554142f@kernel.org> (raw)
In-Reply-To: <66cf7b8d1c480_36509229439@willemb.c.googlers.com.notmuch>

On Wed, 28 Aug 2024 15:33:33 -0400 Willem de Bruijn wrote:
> That could work.
> 
> Is reporting one KTAP and exitcode per directory vs per packetdrill
> invocation good/bad/neither?

To me "neither", hopefully and unhelpfully I won't tell you anything
that's not common sense :) The balance is between:

 - having test cases which don't take too long (assuming debug kernel):
     <15min is good, 
     >1h I will start complaining,
     >1h30m is bad because we can't retry and still make the 3h
            deadline that NIPA has,
     >3h the test can't run in NIPA at all.

vs

 - flip side is having so many cases it's hard to keep track and render
   in the UI. JSON is relatively slow to process. If you have 150 cases,
   that's 300 per branch (debug and non-debug kernels), times 8
   branches a day => 2.4k results / day
   I think that's still fine-ish, but on the larger side for sure. For
   reference net and forwarding have ~100 tests each. FWIW we do have
   the ability to collect and display nested KTAP so the information is
   not lost (but it makes queries slower so we don't fetch it by default).

> Three other issues if this is calling packetdrill directly is
> - passing the non-trivial IP specific flags
> - running twice, for IPv4 and IPv6
> - chdir into the directory of the pkt file
> 
> That can be addressed by instead calling a small wrapper shell script.
> 
> That would do the test_func_builder part of packetdrill_ksft.py.
> But without the need to handle netns, popen/cmd, etc, and thus the
> ksft dependencies.

Right!

  reply	other threads:[~2024-08-28 21:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 19:32 [PATCH net-next RFC] selftests/net: integrate packetdrill with ksft Willem de Bruijn
2024-08-28  0:39 ` Jakub Kicinski
2024-08-28 13:58   ` Willem de Bruijn
2024-08-28  8:20 ` Paolo Abeni
2024-08-28 14:03   ` Willem de Bruijn
2024-08-28 16:01     ` Jakub Kicinski
2024-08-28 19:33       ` Willem de Bruijn
2024-08-28 21:00         ` Jakub Kicinski [this message]
2024-08-30 15:20           ` Willem de Bruijn
2024-08-30 17:33             ` Jakub Kicinski
2024-08-30 18:47               ` Willem de Bruijn
2024-08-30 21:44                 ` Jakub Kicinski
2024-08-30 21:52                   ` Willem de Bruijn
2024-09-01 21:15                     ` Willem de Bruijn
2024-09-02 16:46                       ` Jakub Kicinski
2024-09-02 16:56                         ` Jakub Kicinski
2024-09-02 20:50                           ` Willem de Bruijn
2024-09-05  3:27                   ` Willem de Bruijn
2024-08-30 21:46                 ` Willem de Bruijn
2024-08-28 16:26     ` Matthieu Baerts
2024-08-28 15:01 ` Stanislav Fomichev
2024-08-28 15:36   ` Jakub Kicinski
2024-08-28 15:43   ` Willem de Bruijn
2024-08-28 17:20     ` Stanislav Fomichev
2024-08-28 18:23       ` Jakub Kicinski
2024-08-28 18:36         ` Stanislav Fomichev
2024-08-28 18:26 ` Mina Almasry
2024-08-28 18:39   ` Jakub Kicinski

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=20240828140035.4554142f@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).