From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>, pabeni@redhat.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
linux-kselftest@vger.kernel.org,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next] selftests/net: calibrate txtimestamp
Date: Wed, 31 Jan 2024 10:29:32 -0800 [thread overview]
Message-ID: <20240131102932.6caac1e2@kernel.org> (raw)
In-Reply-To: <65ba61ea978b4_1699fd294eb@willemb.c.googlers.com.notmuch>
On Wed, 31 Jan 2024 10:06:18 -0500 Willem de Bruijn wrote:
> > Willem, do you still want us to apply this as is or should we do
> > the 10x only if [ x$KSFT_MACHINE_SLOW != x ] ?
>
> If the test passes on all platforms with this change, I think that's
> still preferable.
>
> The only downside is that it will take 10x runtime. But that will
> continue on debug and virtualized builds anyway.
>
> On the upside, the awesome dash does indicate that it passes as is on
> non-debug metal instances:
>
> https://netdev.bots.linux.dev/contest.html?test=txtimestamp-sh
>
> Let me know if you want me to use this as a testcase for
> $KSFT_MACHINE_SLOW.
Ah, all good, I thought your increasing the acceptance criteria.
> Otherwise I'll start with the gro and so-txtime tests. They may not
> be so easily calibrated. As we cannot control the gro timeout, nor
> the FQ max horizon.
Paolo also mentioned working on GRO, maybe we need a spreadsheet
for people to "reserve" broken tests to avoid duplicating work? :S
> In such cases we can use the environment variable to either skip the
> test entirely or --my preference-- run it to get code coverage, but
> suppress a failure if due to timing (only). Sounds good?
+1 I also think we should run and ignore failure. I was wondering if we
can swap FAIL for XFAIL in those cases:
tools/testing/selftests/kselftest.h
#define KSFT_XFAIL 2
Documentation/dev-tools/ktap.rst
- "XFAIL", which indicates that a test is expected to fail. This
is similar to "TODO", above, and is used by some kselftest tests.
IDK if that's a stretch or not. Or we can just return PASS with
a comment?
next prev parent reply other threads:[~2024-01-31 18:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-27 2:31 [PATCH net-next] selftests/net: calibrate txtimestamp Willem de Bruijn
2024-01-30 14:54 ` Simon Horman
2024-01-31 1:47 ` Jakub Kicinski
2024-01-31 15:06 ` Willem de Bruijn
2024-01-31 18:29 ` Jakub Kicinski [this message]
2024-01-31 20:27 ` Willem de Bruijn
2024-01-31 20:58 ` Jakub Kicinski
2024-01-31 21:20 ` Willem de Bruijn
2024-01-31 18:39 ` Paolo Abeni
2024-01-31 18: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=20240131102932.6caac1e2@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.