DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Alex Markuze <alex@weka.io>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Huge Pages.
Date: Wed, 1 Oct 2014 10:30:26 +0100	[thread overview]
Message-ID: <20141001093026.GA2540@BRICHA3-MOBL> (raw)
In-Reply-To: <CAKfHP0Um4AOxqYfZTAATmFhwzZbzcq+Nag7_ovXXbkmPwHuLWQ@mail.gmail.com>

On Wed, Oct 01, 2014 at 12:21:05PM +0300, Alex Markuze wrote:
> Hi,
> How well does DPDK play with other applications using huge pages?
> Looking at eal_init/eal_hugepage_info_init it seems that DPDK will try to
> grab All available huge pages.
> 
> Is there an existing way to limit the number of huge pages taken ?
> My goal is to be able to run several applications each with its own dpdk
> instance and a possible 3rd party application all using huge pages. Is this
> possible under DPDKs current design?
> 
> Sharing the NICs is fairly simple if we specify the available lci functions
> per dpdk instance but at first glance sharing huge pages looks like a
> problem.
> 
> Thanks.

It should play well-enough, though not perfectly. There are a couple of 
things to take into account:
* If an app is already using hugepages when a DPDK app starts, the new app 
  should only be looking at using the free hugepages.
* By default, the app will look to use all the free hugepages on the system.  
  However, this can be overriden by specifying the "-m" or for numa systems 
  the "--socket-mem" options. The extra wrinkle here is that eal will try to 
  grab the best set of hugepages it can, so actually temporarily takes over 
  all free hugepages to analyse, then releases the ones it won't use back 
  once it has determined what a good page set would be.
* The hugepage files used by a DPDK app are not automatically deleted once 
  the app terminates. Instead, each time the app starts up it cleaups any 
  unused hugepages from any previous runs. It does this by looking for files 
  with the appropraite filename used by DPDK apps, and checking for a lock 
  being held on them.
* To have multiple apps running side by side, each with it's own hugepage 
  memory, use the --file-prefix EAL option (along with --socket-mem) to 
  force each app to use a different set of hugepage files. [In this 
  situation, you do need to use the -b flag to blacklist ports used by one 
  app from the other app]
 
Hope this helps.
/Bruce 

      parent reply	other threads:[~2014-10-01  9:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-01  9:21 Alex Markuze
2014-10-01  9:28 ` Choi, Sy Jong
2014-10-01  9:30 ` Bruce Richardson [this message]

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=20141001093026.GA2540@BRICHA3-MOBL \
    --to=bruce.richardson@intel.com \
    --cc=alex@weka.io \
    --cc=dev@dpdk.org \
    /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).