All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: Petr Machata <me@pmachata.org>, Petr Machata <petrm@nvidia.com>,
	netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
	Simon Horman <horms@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next 5/5] selftests: drivers: hw: add tests for the ethtool standard counters
Date: Mon, 2 Mar 2026 16:07:43 -0800	[thread overview]
Message-ID: <20260302160743.124531f8@kernel.org> (raw)
In-Reply-To: <7hct7o4rzgygef536al6if2jl45p32ad3tdswyqf25uu5wy5re@2ltu2ems47q7>

On Mon, 2 Mar 2026 14:11:21 +0200 Ioana Ciornei wrote:
> > I agree that adherence to the drivers/net/README protocol is valuable to
> > some users and would be good to uphold if reasonable in a given tests.
> > If that's what you have in mind.
> > 
> > There are going to be tests where it's not a great fit, but I think that
> > of those NUM_NETIFS=2 tests that we currently have, maybe
> > ethtool_extended_state has a good reason to be obstinate, because it
> > sets up negotiations and needs an extra unplugged netdevice.  
> 
> I would add here even ethtool_rmon.sh and this new test that I

I think I already told you that ethool_rmon predates the NIC tests
and bringing it up in this discussion is irrelevant.

> submitted. If you are running with a traffic generator on another board
> then you can no longer check that the counter's value is as expected
> (with a 1% tolerance), you can only check the lower bound.

1% tolerance is impractical for any CI with high test count.
The test will be flaky. And I really doubt that the 1% tolerance
is really necessary to catch most bugs. We're not trying to validate
silicon here.

> Additionally, if you are using the same single port also for control
> traffic towards the remote traffic generator, then you surely cannot
> reliably check that counters that should not be incremented are indeed
> not incremented.

I both told you in this conversation how to check the counters,
and written some existing tests for counters.

  reply	other threads:[~2026-03-03  0:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25 15:06 [PATCH net-next 0/5] net: dpaa2-mac: export standard statistics Ioana Ciornei
2026-02-25 15:06 ` [PATCH net-next 1/5] net: dpaa2-mac: extend APIs related to statistics Ioana Ciornei
2026-02-25 15:06 ` [PATCH net-next 2/5] net: dpaa2-mac: retrieve MAC statistics in one firmware command Ioana Ciornei
2026-02-27  2:26   ` [net-next,2/5] " Jakub Kicinski
2026-02-27 10:37     ` Ioana Ciornei
2026-03-01 16:09   ` [PATCH net-next 2/5] " Simon Horman
2026-03-02 12:51     ` Ioana Ciornei
2026-02-25 15:06 ` [PATCH net-next 3/5] net: dpaa2-mac: export standard statistics Ioana Ciornei
2026-02-25 15:06 ` [PATCH net-next 4/5] selftests: forwarding: extend ethtool_std_stats_get with pause statistics Ioana Ciornei
2026-02-27 16:38   ` Petr Machata
2026-03-02 13:57     ` Ioana Ciornei
2026-03-03 13:06       ` Petr Machata
2026-02-25 15:06 ` [PATCH net-next 5/5] selftests: drivers: hw: add tests for the ethtool standard counters Ioana Ciornei
2026-02-25 23:38   ` Andrew Lunn
2026-02-26  7:03     ` Ioana Ciornei
2026-02-26 12:19       ` Ioana Ciornei
2026-02-26 13:31         ` Andrew Lunn
2026-02-26 14:18           ` Ioana Ciornei
2026-02-27  2:25             ` Jakub Kicinski
2026-02-27  7:34               ` Ioana Ciornei
2026-02-27 14:17                 ` Andrew Lunn
2026-02-28  0:24                   ` Jakub Kicinski
2026-02-28  0:23                 ` Jakub Kicinski
2026-02-27  2:22   ` Jakub Kicinski
2026-02-27 13:53     ` Petr Machata
2026-02-28  0:43       ` Jakub Kicinski
2026-02-28  9:11         ` Petr Machata
2026-03-02 12:11           ` Ioana Ciornei
2026-03-03  0:07             ` Jakub Kicinski [this message]
2026-03-03 13:53               ` Ioana Ciornei
2026-03-03 16:43                 ` Jakub Kicinski
2026-02-27 15:45   ` Petr Machata
2026-03-02 14:15     ` Ioana Ciornei
2026-03-03 13:30       ` Petr Machata

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=20260302160743.124531f8@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=ioana.ciornei@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=me@pmachata.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=shuah@kernel.org \
    /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.