On Fri, Feb 27, 2026 at 09:34:28AM +0200, Ioana Ciornei wrote:

On Thu, Feb 26, 2026 at 06:25:11PM -0800, Jakub Kicinski wrote:

quoted

On Thu, 26 Feb 2026 16:18:21 +0200 Ioana Ciornei wrote:

quoted

quoted

How about, fail the test if any are greater than 1% of the number of
packets transmitted/received? My _guess_ is, if you have 1% packet
loss, networking is not going to be happy anyway. It probably means
you have one end doing Half duplex and the other Full. That is a
typical configuration error you see causing collisions. Not that i've
actually seen this for maybe a decade!

Failing the test, with a comment about checking duplex configuration,
seems sensible.  

Seems reasonable. Thanks for the help!

FWIW the expectation is that the test should be able to run even on
systems / boards with a single interface. So the control traffic
(communicating with the traffic generator) will run over the same
interface as the test. 1% error is unachievable. I'd only check the
lower bound, and use some sanity value for the upper bound (2^30 ?)
if at all

Really? I didn't know of that expectation at all.

I did take ethtool_rmon.sh as an example and that selftest as well
takes NUM_NETIFS=2 and does check for both a lower bound and upper bound
that takes into account a 1% deviance from the target.

How would the test even work with only a single interface?

Just to add to this, for the 1% i was referring to counters for
collisions. If the control traffic is causing collisions the system it
just as wrongly configured as generated traffic causing collisions.

For 'everyday' systems, i doubt Half Duplex is ever used, but
automotive with a T1 PHY might. So we might need to review this 1%
once somebody runs this test on such a system.

     Andrew