DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz@6wind.com>
To: "Schumm, Ken" <ken.schumm@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] When are mbufs released back to the mempool?
Date: Wed, 18 Dec 2013 10:02:35 +0100	[thread overview]
Message-ID: <52B164AB.9000002@6wind.com> (raw)
In-Reply-To: <B35F7300EA51774C974164D11E30E3E42DFA11EB@ORSMSX103.amr.corp.intel.com>

Hello Ken,

On 12/17/2013 07:13 PM, Schumm, Ken wrote:
 > When running l2fwd the number of available mbufs returned by
 > rte_mempool_count() starts at 7680 on an idle system.
 >
 > As traffic commences the count declines from 7680 to
 > 5632 (expected).

You are right, some mbufs are kept at 2 places:

- in mempool per-core cache: as you noticed, each lcore has
   a cache to avoid a (more) costly access to the common pool.

- also, the mbufs stay in the hardware transmission ring of the
   NIC. Let's say the size of your hw ring is 512, it means that
   when transmitting the 513th mbuf, you will free the first mbuf
   given to your NIC. Therefore, (hw-tx-ring-size * nb-tx-queue)
   mbufs can be stored in tx hw rings.
   Of course, the same applies to rx rings, but it's easier to see
   it as they are filled when initializing the driver.

When choosing the number of mbufs, you need to take a value
greater than (hw-rx-ring-size * nb-rx-queue) + (hw-tx-ring-size *
nb-tx-queue) + (nb-lcores * mbuf-pool-cache-size)

 > Is this also true of ring buffers?

No, if you talk about rte_ring, there is no cache in this
structure.

Regards,
Olivier

  reply	other threads:[~2013-12-18  9:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17 18:13 Schumm, Ken
2013-12-18  9:02 ` Olivier MATZ [this message]
2013-12-19 19:09   ` Schumm, Ken
2013-12-19 19:35     ` Stephen Hemminger
2013-12-19 23:56       ` Schumm, Ken

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=52B164AB.9000002@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ken.schumm@intel.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).