> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > Sent: Thursday, 25 April 2024 11.26 > > On 2024-04-25 01:55, Stephen Hemminger wrote: > > On Thu, 25 Apr 2024 00:27:36 +0200 > > Mattias Rönnblom <hof...@lysator.liu.se> wrote: > > > >> On 2024-04-24 21:13, Stephen Hemminger wrote: > >>> On Wed, 24 Apr 2024 18:50:50 +0100 > >>> Ferruh Yigit <ferruh.yi...@amd.com> wrote: > >>> > >>>>> I don't know how slow af_packet is, but if you care about performance, > >>>>> you don't want to use atomic add for statistics. > >>>>> > >>>> > >>>> There are a few soft drivers already using atomics adds for updating > stats. > >>>> If we document expectations from 'rte_eth_stats_reset()', we can update > >>>> those usages. > >>> > >>> Using atomic add is lots of extra overhead. The statistics are not > guaranteed > >>> to be perfect. If nothing else, the bytes and packets can be skewed. > >>> > >> > >> The sad thing here is that in case the counters are reset within the > >> load-modify-store cycle of the lcore counter update, the reset may end > >> up being a nop. So, it's not like you missed a packet or two, or suffer > >> some transient inconsistency, but you completed and permanently ignored > >> the reset request. > > > > That is one of the many reasons the Linux kernel intentionally did not > > implement a reset statistics operation. > > DPDK should deprecate statistics reset, it seems to me.
+1 > > The current API is broken anyway, if you care about correctness. A reset > function must return the current state of the counters, at the point > them being reset. Otherwise, a higher layer may miss counter updates. > > The af_packet PMD should return -ENOTSUP on reset (which is allowed by > the API). > > Maintaining an offset-since-last-reset for counters is a control plane > thing, and shouldn't be in PMDs. (If MT-safe reset for SW-managed > counters are to be expected from the PMDs, we should have some helper > API to facilitate its efficient & correct-enough implementation.)
