From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, shuah@kernel.org, willemb@google.com,
petrm@nvidia.com, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next] selftests: drv-net: assume stats refresh is 0 if no ethtool -c support
Date: Fri, 20 Dec 2024 06:22:14 -0800 [thread overview]
Message-ID: <20241220062214.3e8823ac@kernel.org> (raw)
In-Reply-To: <e933e67f-66f2-422b-b00e-09ae788ed51d@lunn.ch>
On Fri, 20 Dec 2024 10:09:06 +0100 Andrew Lunn wrote:
> > @@ -234,7 +234,12 @@ from .remote import Remote
> > Good drivers will tell us via ethtool what their sync period is.
> > """
> > if self._stats_settle_time is None:
> > - data = ethtool("-c " + self.ifname, json=True)[0]
> > + data = {}
> > + try:
> > + data = ethtool("-c " + self.ifname, json=True)[0]
> > + except CmdExitFailure as e:
> > + if "Operation not supported" not in e.cmd.stderr:
> > + raise
>
> How important is this time to the test itself?
Just to be clear (because unfortunately git doesn't do a good job of
calling out Python method names in the diff :() this is part of a
method called wait_hw_stats_settle() within the test env class.
It's used by various tests which use/check device stats.
> If it is not available,
> can the test just default to 50ms and keep going? I would of thought
> we find more issues by running the test too slowly, than not running
> it at all, unless having the wrong timer makes it more flaky.
We already use zero for majority of driver which don't report stat
refresh:
data.get('stats-block-usecs', 0) / 1000 / 1000
^^^
this patch just does the same thing not only if the driver doesn't
report 'stats-block-usecs' but also if it doesn't support -c at all.
next prev parent reply other threads:[~2024-12-20 14:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 0:31 [PATCH net-next] selftests: drv-net: assume stats refresh is 0 if no ethtool -c support Jakub Kicinski
2024-12-20 9:09 ` Andrew Lunn
2024-12-20 14:22 ` Jakub Kicinski [this message]
2024-12-20 15:03 ` Andrew Lunn
2024-12-21 4:05 ` Willem de Bruijn
2024-12-23 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=20241220062214.3e8823ac@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=shuah@kernel.org \
--cc=willemb@google.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.