RE: [RFC] mempool: cache preparation

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> 
> Some drivers bypass the mbuf/mempool library functions, to manipulate the mempool cache directly for improved performance.
> 
> Specifically, the AVX512 implementation of some of the Intel PMDs copy an array of objects from the cache to a field in an array of some
> structure, i.e. it is not a 1:1 memcpy. This method avoids having to copy the array of pointers into a temporary array before copying them
> into the fields of the target array, and thus improves performance and reduces CPU cache pollution.
> 
> For such purposes, the mempool API could provide functions to prepare the mempool cache for a direct access operation, and commit the
> transaction:
> 1. Prepare the cache for getting N objects directly from the objs array. This function returns the address of the position in the cache array,
> from where the objects can be read, or NULL if failed.
> 2. Commit after getting the N objects.
> 3. Prepare the cache for putting N objects directly into the objs array. This function returns the address of the position in the cache array, to
> where the objects can be written, or NULL if failed.
> 4. Commit after putting the N objects.
> 
> The functions only need to support getting/putting exactly N objects; i.e. the "prepare" functions do not need return a value indicating
> some number less than N is available. Likewise, the "commit" functions do not need to support any N other than the N in the preceding
> "prepare" function.
> 
> This API extension would provide a clean interface to directly access the mempool cache with high performance, so copy-pasting the
> mempool's cache handling logic can be avoided, and bugs like [1] would not survive.
> 
> Would this be useful?
> 
> [1]: https://bugs.dpdk.org/show_bug.cgi?id=923
> 

I think it is a very good idea, definitely worth to try.
I am also a bit worried that we have some PMD code that bypasses existing mempool cache functions,
so if we can close the gap here while keeping the perf we have - would be great.
Thanks
Konstantin