> From: Andrew Rybchenko [mailto:[email protected]] > Sent: Tuesday, 24 February 2026 07.29 > > On 2/23/26 1:20 PM, Morten Brørup wrote: > > Populating a mempool with objects is accounted for in the statistics. > > When analyzing mempool cache statistics, this may distort the data. > > In order to simplify mempool cache statistics analysis, a mempool > > statistics reset function was added. > > > > Furthermore, details about average burst sizes and mempool cache miss > > rates were added to the statistics shown when dumping a mempool. > > > > Signed-off-by: Morten Brørup <[email protected]> > > I'd like to see thoughts about consistency after reset taking into > account that reset will likely to be done from control core whereas > stats are updated from data cores. Results could be very interesting. > I guess it is not the reason to introduce locking or any other kind > of synchronization, but user should be warned as the bare minimum.
When used for cache statistics analysis, the reset function will be called once only: After everything has been initialized (mempool created and populated, and ethdev Rx queues preloaded with mbufs), but before the data plane is started. I don't think the end user should be warned; this may be normal behavior for an application. In addition to the trace event, I'll add a DEBUG level log message in the function. And a warning about potential inconsistency in the function description. Good feedback, Andrew!
