On 2/24/26 9:38 AM, Morten Brørup wrote:
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.
Thanks I see now. May be these assumptions should be mentioned in the
function description? Or is it too much?
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.
Sounds good.
Good feedback, Andrew!
