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

[Andrew Lunn <andrew@lunn.ch>]

> 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.

     Andrew