The Rx packet count reported by ice, ice DCF and iavf can momentarily jump to an enormous invalid value under load. ipackets is derived by subtracting the discarded packet count from the sum of the unicast, multicast and broadcast counters. That sum already includes the discarded packets, so the result is the number actually delivered. The inputs are sampled from separate sources at slightly different instants, so the discard count can briefly exceed the measured sum. Because the arithmetic is unsigned, the subtraction wraps to a huge value and is reported as a hugely incorrect packet count and rate.
All three share the bug but not the fix, because they differ in how much control they have over the sampling. The ice PF reads its counters directly from hardware registers, so the order is under the driver's control. Reading the discard register before the other three, combined with the fact that the counters only ever increase and the delivered-packet sum always includes the discards, makes it impossible for the discard count to exceed the later sum. No clamping is needed and the subtraction can never underflow. ice DCF and iavf receive their counters from the PF in a single virtchnl message and cannot influence the order in which the PF sampled them. There a reorder is not available, so the subtraction is made saturating: when the discard count exceeds the sum, essentially nothing was delivered, so zero is reported instead of underflowing. Ciara Loftus (3): net/ice: fix Rx packets statistics underflow net/ice: fix DCF Rx packets statistics underflow net/iavf: fix Rx packets statistics underflow drivers/net/intel/iavf/iavf_ethdev.c | 12 ++++++++++-- drivers/net/intel/ice/ice_dcf_ethdev.c | 12 ++++++++++-- drivers/net/intel/ice/ice_ethdev.c | 11 +++++++++-- 3 files changed, 29 insertions(+), 6 deletions(-) -- 2.43.0
