All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: pabeni@redhat.com, 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 12:58:19 -0800	[thread overview]
Message-ID: <20240131125819.25c7c372@kernel.org> (raw)
In-Reply-To: <65baad3627cef_1b52d2294bc@willemb.c.googlers.com.notmuch>

On Wed, 31 Jan 2024 15:27:34 -0500 Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > +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?  
> 
> Flaky tests will then report both pass and expected fail. That might
> add noise to https://netdev.bots.linux.dev/flakes.html?
> 
> I initially considered returning skipped on timing failure. But that
> has the same issue.
> 
> So perhaps just return pass?
> 
> 
> Especially for flaky tests sometimes returning pass and sometimes
> returning expected to fa red/green
> dash such as 

Right, we only have pass / fail / skip. (I put the "warn" result in for
tests migrated from patchwork so ignore its existence for tests.)

We already treat XFAIL in KTAP as "pass". TCP-AO's key-managemeent_ipv6
test for example already reports XFAIL:

# ok 15 # XFAIL listen() after current/rnext keys set: the socket has current/rn
ext keys: 100:200

Skips look somewhat similar in KTAP, "ok $number # SKIP" but we fish
those out specifically to catch skips. Any other "ok .... # comment"
KTAP result is treated as a "pass" right now.

  reply	other threads:[~2024-01-31 20:58 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
2024-01-31 20:27       ` Willem de Bruijn
2024-01-31 20:58         ` Jakub Kicinski [this message]
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=20240131125819.25c7c372@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.