>
> 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
