[dpdk-dev] Question about cache_size in rte_mempool_create

[Bruce Richardson]

On Fri, Nov 24, 2017 at 01:01:08PM +0200, Roy Shterman wrote:
> 
> 
> נשלח מה-iPhone שלי
> 
> ‫ב-24 בנוב׳ 2017, בשעה 12:03, ‏‏Bruce Richardson ‏<bruce.richardson at intel.com> כתב/ה:‬
> 
> >> On Fri, Nov 24, 2017 at 11:39:54AM +0200, roy wrote:
> >> Thanks for your answer, but I cannot understand the dimension of the ring
> >> and it is affected by the cache size.
> >> 
> >>> On 24/11/17 11:30, Bruce Richardson wrote:
> >>>> On Thu, Nov 23, 2017 at 11:05:11PM +0200, Roy Shterman wrote:
> >>>> Hi,
> >>>> 
> >>>> In the documentation it says that:
> >>>> 
> >>>>  * @param cache_size
> >>>>  *   If cache_size is non-zero, the rte_mempool library will try to
> >>>>  *   limit the accesses to the common lockless pool, by maintaining a
> >>>>  *   per-lcore object cache. This argument must be lower or equal to
> >>>>  *   CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE and n / 1.5.* It is advised to
> >>>> choose*
> >>>> * *   cache_size to have "n modulo cache_size == 0": if this is*
> >>>> * *   not the case, some elements will always stay in the pool and will*
> >>>> * *   never be used.* The access to the per-lcore table is of course
> >>>>  *   faster than the multi-producer/consumer pool. The cache can be
> >>>>  *   disabled if the cache_size argument is set to 0; it can be useful to
> >>>>  *   avoid losing objects in cache.
> >>>> 
> >>>> I wonder if someone can please explain the high-lightened sentence, how the
> >>>> cache size affects the objects inside the ring.
> >>> It has no effects upon the objects themselves. Having a cache is
> >>> strongly recommended for performance reasons. Accessing a shared ring
> >>> for a mempool is very slow compared to pulling packets from a per-core
> >>> cache. To test this you can run testpmd using different --mbcache
> >>> parameters.
> >> Still, I didn't understand the sentence from above:
> >> 
> >> *It is advised to choose cache_size to have "n modulo cache_size == 0": if
> >> this is* not the case, some elements will always stay in the pool and will*
> >> never be used.*
> >> 
> > 
> > This would be an artifact of the way in which the elements are taken
> > from the pool ring. If a full cache-size burst of elements is not
> > available in the ring, no elements from the ring are put in the cache.
> > It just means that the pool can never fully be emptied. However, in most
> > cases, even having the pool nearly empty indicates a problem, so
> > practically I wouldn't be worried about this.
> > 
> 
> But in case we tried to get cache size from pool and failed we will try to get the number on objects defined in rte_mempool_get_bulk, so in case rte_mempool_get() usage we will try to get one object out of the pool (ring) so also if there isn't cache size in the ring itself each core can get 1 object in each rte_memoool_get until the pool is empty, am I wrong?
> 

If there is no cache, you can always get all elements out of the ring by
getting one at a time, yes.