DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Andrew Rybchenko <arybchenko@solarflare.com>, dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] rte_mempool_get_bulk uses either cache or common pool
Date: Wed, 16 Oct 2019 09:22:42 +0200	[thread overview]
Message-ID: <20191016072242.3dr7i7xmdokztjd4@platinum> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60B78@smartserver.smartshare.dk>

Hi Morten,

On Fri, Oct 11, 2019 at 01:24:00PM +0200, Morten Brørup wrote:
> The rte_mempool_get_bulk() documentation says:
> 
> "If cache is enabled, objects will be retrieved first from cache, subsequently from the common pool."
> 
> But __mempool_generic_get() only uses the cache if the request is smaller than the cache size. If not, objects will be retrieved from the common pool only.
> 
> Either the documentation should be corrected, or the implementation should behave as described, i.e. retrieve the first of the objects from the cache and the remaining objects from the common pool.

That's correct. I think the documentation could be updated.
Maybe something like this:

 * If cache is enabled, objects will be retrieved first from cache,
 * subsequently from the common pool. If the number of requested objects
 * is higher than the cache size, the objects are directly retrieved
 * from the common pool.

The put() suffers from the same problem, but the actual behavior is
not easy to describe. We could add this:

 * The objects are added in the cache if it is enabled, and if
 * the number of objects is smaller than RTE_MEMPOOL_CACHE_MAX_SIZE.
 * After the operation,	if the cache length is above 1.5 * size,
 * some	objects	are also returned to the common	pool.

But I feel the comment is just a duplication of the code, but in
english... and there's a risk that they become unsynchronized in the
future (especially because the comment is above
rte_mempool_generic_put() and the code is in
__rte_mempool_generic_put()).



> PS: I stumbled into this while writing the unit test for mbuf bulk alloc/free.
> 
> PPS: It seems unit tests for mempool bulk alloc/free are missing. :-)
> 
> 
> Med venlig hilsen / kind regards
> - Morten Brørup
> 
> 

  reply	other threads:[~2019-10-16  7:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 11:24 Morten Brørup
2019-10-16  7:22 ` Olivier Matz [this message]
2019-10-17  9:46   ` Morten Brørup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191016072242.3dr7i7xmdokztjd4@platinum \
    --to=olivier.matz@6wind.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).