On Thu, Jun 25, 2026 at 09:36:16AM +0000, Ciara Loftus wrote: > 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 > Series applied to dpdk-next-net-intel. I was tempted to squash into one patch, but kept them as three because the fix is not identical in all cases (iavf being different).
Thanks, /Bruce
