Re: [PATCH net-next 5/5] selftests: drivers: hw: add tests for the ethtool standard counters

[Ioana Ciornei]

On Thu, Feb 26, 2026 at 02:31:26PM +0100, Andrew Lunn wrote:
> > I am back with a bit more information. The counters which were not
> > checked in this version can be grouped in two categories:
> > 
> > - Error counters such as:
> > 
> > 	u64 FrameCheckSequenceErrors;
> > 	u64 AlignmentErrors;
> > 	u64 FramesLostDueToIntMACXmitError;
> > 	u64 CarrierSenseErrors;
> > 	u64 FramesLostDueToIntMACRcvError;
> > 	u64 InRangeLengthErrors;
> > 	u64 OutOfRangeLengthField;
> > 	u64 FrameTooLongErrors;
> > 	u64 FramesAbortedDueToXSColls;
> > 
> >   I did extend the selftest with these ones so that we check them
> >   against zero. I ran the test hundreds of times and I did not see any
> >   problems.
> 
> Great.
> 
> > 
> > - Collision related counters (not really errors):
> > 
> > 	u64 SingleCollisionFrames;
> > 	u64 MultipleCollisionFrames;
> > 	u64 FramesWithDeferredXmissions;
> > 	u64 LateCollisions;
> > 	u64 FramesWithExcessiveDeferral;
> > 
> >   With these I don't know what to do. Theoretically, they could be
> >   non-zero in half-duplex circumstances which means that checking for
> >   zero would not be entirely accurate.
> 
> 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!