On Sat, Nov 05, 2022 at 02:19:13PM +0100, Morten Brørup wrote: > Zero-copy access to the mempool cache is beneficial for PMD performance, and > must be provided by the mempool library to fix [Bug 1052] without a > performance regression. > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052 > > > This RFC offers two conceptual variants of zero-copy get: > 1. A simple version. > 2. A version where existing (hot) objects in the cache are moved to the top > of the cache before new objects from the backend driver are pulled in. > > I would like some early feedback. Also, which variant do you prefer? > > Notes: > * Allowing the 'cache' parameter to be NULL, and getting it from the mempool > instead, was inspired by rte_mempool_cache_flush(). > * Asserting that the 'mp' parameter is not NULL is not done by other > functions, so I omitted it here too. > > NB: Please ignore formatting. Also, this code has not even been compile > tested. > > > PS: No promises, but I expect to offer an RFC for zero-copy put too. :-) >
Thanks for this work, I think it's good to have. The existing functions could probably be reworked to use this new code too, right, since the copy at the end would be all that is needed to complete the implementation? Only real comment I have on this version is that I am not sure about the naming. I think having "cache_get_bulk" doesn't really make it very clear what the function does, that is removes items from the cache without copying them elsewhere. How about: - rte_mempool_cache_pop? - rte_mempool_cache_reserve? I would tend to prefer the former, since the latter implies that there needs to be a follow-up call to clear the reservation. On the other hand, reserve does give the correct impression that the elements are still there in the mempool cache. Others may have better suggestions, since, as we know, naming things is hard! :) Overall, though, I think this is very good to have. /Bruce
