> From: Thomas Monjalon [mailto:[email protected]] > Sent: Monday, 1 June 2026 15.36 > > 26/05/2026 18:00, Morten Brørup: > > > From: Morten Brørup [mailto:[email protected]] > > > Sent: Tuesday, 26 May 2026 16.00 > > > > > > This patch refactors the mempool cache to eliminate some unexpected > > > behaviour and reduce the mempool cache miss rate. > > > > > > 1. > > > The actual cache size was 1.5 times the cache size specified at > run- > > > time > > > mempool creation. > > > This was obviously not expected by application developers. > > > > > > 2. > > > In get operations, the check for when to use the cache as bounce > buffer > > > did not respect the run-time configured cache size, > > > but compared to the build time maximum possible cache size > > > (RTE_MEMPOOL_CACHE_MAX_SIZE, default 512). > > > E.g. with a configured cache size of 32 objects, getting 256 > objects > > > would first fetch 32 + 256 = 288 objects into the cache, > > > and then move the 256 objects from the cache to the destination > memory, > > > instead of fetching the 256 objects directly to the destination > memory. > > > This had a performance cost. > > > However, this is unlikely to occur in real applications, so it is > not > > > important in itself. > > > > > > 3. > > > When putting objects into a mempool, and the mempool cache did not > have > > > free space for so many objects, > > > the cache was flushed completely, and the new objects were then put > > > into > > > the cache. > > > I.e. the cache drain level was zero. > > > This (complete cache flush) meant that a subsequent get operation > (with > > > the same number of objects) completely emptied the cache, > > > so another subsequent get operation required replenishing the > cache. > > > > > > Similarly, > > > When getting objects from a mempool, and the mempool cache did not > hold > > > so > > > many objects, > > > the cache was replenished to cache->size + remaining objects, > > > and then (the remaining part of) the requested objects were fetched > via > > > the cache, > > > which left the cache filled (to cache->size) at completion. > > > I.e. the cache refill level was cache->size (plus some, depending > on > > > request size). > > > > > > (1) was improved by generally comparing to cache->size instead of > > > cache->flushthresh, when considering the capacity of the cache. > > > The cache->flushthresh field is kept for API/ABI compatibility > > > purposes, > > > and initialized to cache->size instead of cache->size * 1.5. > > > > > > (2) was improved by generally comparing to cache->size / 2 instead > of > > > RTE_MEMPOOL_CACHE_MAX_SIZE, when checking the bounce buffer limit. > > > > > > (3) was improved by flushing and replenishing the cache by half its > > > size, > > > so a flush/refill can be followed randomly by get or put requests. > > > This also reduced the number of objects in each flush/refill > operation. > > > > > > As a consequence of these changes, the size of the array holding > the > > > objects in the cache (cache->objs[]) no longer needs to be > > > 2 * RTE_MEMPOOL_CACHE_MAX_SIZE, and can be reduced to > > > RTE_MEMPOOL_CACHE_MAX_SIZE at an API/ABI breaking release. > > I'm not sure why waiting?
Because the rte_mempool_cache structure holding the array is part of the public API: https://elixir.bootlin.com/dpdk/v26.03/source/lib/mempool/rte_mempool.h#L113 abidiff complained about it in v1, so I reverted the array size reduction in v2. > > > > > Performance data: > > > With a real WAN Optimization application, where the number of > allocated > > > packets varies (as they are held in e.g. shaper queues), the > mempool > > > cache miss rate dropped from ca. 1/20 objects to ca. 1/48 objects. > > > This was deployed in production at an ISP, and using an effective > cache > > > size of 384 objects. > > > > > > Bugzilla ID: 1027 > > > Fixes: ea5dd2744b90 ("mempool: cache optimisations") > > > Signed-off-by: Morten Brørup <[email protected]> > > > > Forgot carrying an Ack over from v5: > > Acked-by: Andrew Rybchenko <[email protected]> > > > > > --- > > > Depends-on: patch-163181 ("net/intel: do not bypass mbuf lib for > mbuf > > > fast-free") > > > > This dependency seems to cause CI apply failures. > > The dependency is based on an older snapshot of main, > > and this patch is based on a new snapshot of main. > > The dependency should be resolved now. > Please could you send a v7? > I'm not 100 % sure, but I think the problem is CI only... This patch is based on main, so it should apply as-is. Bruce has already applied the other patch (that this one depends on) to the intel-next-net tree. The other patch is based on an older snapshot of main, so when using "Depends-on", I guess the CI bases its series on the other patch; and then the CI fails to apply this patch (because it's based on a newer snapshot of main).
