> From: Morten Brørup [mailto:[email protected]] > Sent: Tuesday, 26 May 2026 12.37 > > > From: Bruce Richardson [mailto:[email protected]] > > Sent: Tuesday, 26 May 2026 11.40 > >
[...] > > [In all this, I am making the assumption that burst size is well less > > than > > cache size. Also, similar logic would be applicable for the inverse > > scenario, e.g. flush to empty (and fill burst) and fill to 75%] > > I'm not so sure about this assumption. > With a cache size of 512 and a bursts of 64, the cache only holds 8 > bursts. > 50% is 4 bursts, and 25% is only 2 bursts. > > Using a replenish/drain level in the middle requires 5 bursts in either > direction to pass the edge (and trigger replenish/flush). > Using a replenish/drain level 25% from the edge requires only 3 bursts > in the wrong direction to pass the edge (and trigger replenish/flush). > Much higher probability with random get/put. > > > > > Now, all said, I tend to agree that we want to leave space for a > decent > > size burst after a fill. That is why I think that filling to 75% is > > reasonable. After an alloc that triggers a fill, I don't want the > cache > > less than 50% full, but not completely full so there is room for a > free > > without a flush, and similarly for a free that triggers a flush, the > > cache > > should not be empty, but also should not be more than half full. > > > > One suggestion - we could always add a simple tunable that specifies > > the > > margin, or reserved entries for alloc and free. We can then guide in > > the > > docs that the value should be e.g. "zero for apps where alloc and > free > > take > > place on different cores. 20%-50% of cache is recommended where alloc > > and > > free take place on the same core" > > Yes, a simple tunable is a really good idea. > > At this point, I think we should optimize for use case #1, and go for > the 50% fill level. > Then we can add a tunable to optimize for use case #2 later. I will try > to come up with a draft for such a follow-up patch within the next few > days. Adding a tunable is not so simple... The choice of mempool cache algorithm (drain/replenish to 50% vs. drain/replenish completely) should be passed via the "flags" parameter in rte_mempool_create(), but rte_pktmbuf_pool_create() is missing the "flags" parameter. We can add it at the next ABI breaking release. WDYT? We should use that addition as an opportunity to move the case where the objects are not entirely handled by the cache into non-inlined functions, so the inlined functions don't grow too much in size, when they need to handle two different algorithms. > > The 50% fill level in this patch is not as bad for use case #2 (roughly > doubling the burst miss rate from 1/8 to 1/4), compared to how bad the > original algorithm is for use case #1 (very high miss probability - > only two ops in the wrong direction - after drain/replenish). > > -Morten
