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 Med venlig hilsen / Kind regards, -Morten Brørup
