From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Matthieu Baerts <matttbe@kernel.org>,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, ncardwell@google.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org, fw@strlen.de,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next v2 2/2] selftests/net: integrate packetdrill with ksft
Date: Fri, 6 Sep 2024 17:04:56 -0700 [thread overview]
Message-ID: <20240906170456.5a113628@kernel.org> (raw)
In-Reply-To: <66db9008e0b4e_2a33ef29428@willemb.c.googlers.com.notmuch>
On Fri, 06 Sep 2024 19:28:08 -0400 Willem de Bruijn wrote:
> > > No, we opted for this design exactly to use existing kselftest infra,
> > > rather than reimplementing that in our wrapper, as I did in the RFC.
> >
> > OK, I understood from the discussions from the RFC that by using the
> > kselftest infra, the tests would be automatically executed in dedicated
> > netns, and it could also help running tests in parallel. That sounded
> > great to me, but that's not the case by default from what I see.
>
> Perhaps that's something to change in the defaults for run_tests.
>
> Since the infra exist, that is preferable over reimplementing it for
> one particular subset of tests.
>
> Or if not all kselftests can run in netns (quite likely), this needs
> to be opt-in. Then a variable defined in the Makefile perhaps. To
> tell kselftest to enable the feature for this target.
Indeed, I was thinking along the same lines.
We're closing net-next in a week, it'd be great to have the baseline
ksft interpreter mechanism in place in the next couple of days.
The exact implementation of packetdrill/ksft_runner.sh can be changed
later as needed, and the current one works fine for NIPA.
Hopefully we can also discuss at LPC/netconf what to do about libraries
(where setup / cleanup code could live). Looking at MPTCP tests - do
they work out of tree? I see mptcp_lib.sh does:
. "$(dirname "${0}")/../lib.sh"
. "$(dirname "${0}")/../net_helper.sh"
but lib/sh and net_helper.sh are not listed in the Makefile. So they
won't get packaged...
We should make sure we support running the tests with make run_tests
and in installed mode.
If we agree that the current situation with support for library code is
far from ideal, I think we have three(ish) directions to explore:
1 build netns handling into runner.sh
+ already mostly there
+ simpler tests, no need to worry about netns, it just happens
- not all tests need netns (HW-adjacent tests especially)
- netns setup is the main thing we need but not the only thing,
wait helpers, python code, etc. also need to be handled
2a improve library bundling at the ksft level
+ we already have a net/lib "meta-target", it kinda works
+ hopefully in a way that lets us Python
- no idea how
2b put all the code in kselftest/, like ktap_helpers.sh ?
+ easy to do
+ helps other subsystems
- could cause git conflicts
- won't help Python?
3 give up on target proliferation; on a quick count we have 15 targets
in ksft for various bits of networking, faaar more than anyone else
+ fewer targets limits the need for libraries, libraries local to
the target are trivial to handle
- ksft has no other form of "grouping" tests, if we collapse into
a small number of targets it will be hard to run a group of tests
next prev parent reply other threads:[~2024-09-07 0:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 23:15 [PATCH net-next v2 0/2] selftests/net: add packetdrill Willem de Bruijn
2024-09-05 23:15 ` [PATCH net-next v2 1/2] selftests: support interpreted scripts with ksft_runner.sh Willem de Bruijn
2024-09-05 23:15 ` [PATCH net-next v2 2/2] selftests/net: integrate packetdrill with ksft Willem de Bruijn
2024-09-06 11:43 ` Matthieu Baerts
2024-09-06 15:36 ` Willem de Bruijn
2024-09-06 16:26 ` Matthieu Baerts
2024-09-06 23:28 ` Willem de Bruijn
2024-09-07 0:04 ` Jakub Kicinski [this message]
2024-09-09 7:42 ` Matthieu Baerts
2024-09-09 13:15 ` Willem de Bruijn
2024-09-09 14:14 ` Matthieu Baerts
2024-09-09 17:21 ` [PATCH net-next v2 0/2] selftests/net: add packetdrill Jakub Kicinski
2024-09-10 17:45 ` Willem de Bruijn
2024-09-10 22:26 ` Jakub Kicinski
2024-09-10 0:40 ` patchwork-bot+netdevbpf
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=20240906170456.5a113628@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=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).