[PATCH] ethdev: document that stats reset APIs are not thread-safe

[Stephen Hemminger]

On Fri, 26 Apr 2024 17:17:25 +0200
Morten Brørup <mb at smartsharesystems.com> wrote:

> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Friday, 26 April 2024 17.14
> > 
> > On Fri, 26 Apr 2024 14:20:01 +0200
> > Morten Brørup <mb at smartsharesystems.com> wrote:
> >   
> > > > From: Ferruh Yigit [mailto:ferruh.yigit at amd.com]
> > > > Sent: Thursday, 25 April 2024 18.53
> > > >
> > > > Making 'rte_eth_stats_reset()' and 'rte_eth_xstats_reset()' APIs thread
> > > > safe has performance impact on datapath.
> > > >
> > > > Instead document APIs as not thread safe and add condition for reliable
> > > > stats reset functionality, forwarding should be stopped.  
> > >
> > > I'm not sure stopping forwarding suffices.
> > > NIC hardware counters will keep progressing unless RX and TX is stopped at  
> > NIC level.  
> > >
> > > I don't have any suggestions for a better wording, though. :-(
> > >
> > > Anyway, better with the patch than without...
> > > Acked-by: Morten Brørup <mb at smartsharesystems.com>
> > >  
> > 
> > The safest option would be:
> > 	rte_eth_dev_stop
> > 	rte_eth_stats_reset
> > 	rte_eth_dev_start  
> 
> Yes, but this will cause packet loss.
> Network admins should be able to clear the counters without causing packet loss.
> 

Another alternative would be to a "reset zero" approach.

When reset is done, capture the current state of all the relevant counters.
Record that, and subtract those on next request. Never modify the
underlying counters.

To make it MT safe, use lock on reset and something super lightweight
like seqlock on the stats request side.  Might be hard with the size and variable
length nature of xstats thoug.