DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Ravi1.Kumar@amd.com,
	jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
	yskoh@mellanox.com, arybchenko@solarflare.com,
	damarion@cisco.com, ktraynor@redhat.com,
	stephen@networkplumber.org, olivier.matz@6wind.com,
	christian.ehrhardt@canonical.com, bluca@debian.org
Subject: Re: [dpdk-dev] [PATCH] config: reduce memory requirements for DPDK
Date: Tue, 24 Jul 2018 14:03:08 +0200	[thread overview]
Message-ID: <6155181.arAJIN2bNs@xps> (raw)
In-Reply-To: <fcbe6554-10f0-96ec-6003-fdaf78e09b2d@intel.com>

24/07/2018 13:04, Burakov, Anatoly:
> On 24-Jul-18 11:23 AM, Thomas Monjalon wrote:
> > 24/07/2018 12:03, Anatoly Burakov:
> >> It has been reported that current memory limitations do not work
> >> well on an 8-socket machines in default configuration when big
> >> page sizes are used [1].
> >>
> >> Fix it by reducing memory amount reserved by DPDK by default to
> >> 32G per page size per NUMA node. This translates to allowing us
> >> to reserve 32G per page size per NUMA node on 8 nodes with 2
> >> page sizes.
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2018-July/108071.html
> >>
> >> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >> ---
> >>
> >> Notes:
> >>      We could have increased CONFIG_RTE_MAX_MEM_MB but this would've
> >>      brought other potential problems due to increased memory
> >>      preallocation, and secondary process initialization is flaky
> >>      enough as it is. I am willing to bet that 32G per page size is
> >>      more than enough for the majority of use cases, and any
> >>      application with bigger requirements could adjust config options
> >>      itself.
> > [...]
> >> -CONFIG_RTE_MAX_MEMSEG_PER_TYPE=32768
> >> -CONFIG_RTE_MAX_MEM_MB_PER_TYPE=131072
> >> +CONFIG_RTE_MAX_MEMSEG_PER_TYPE=16384
> >> +CONFIG_RTE_MAX_MEM_MB_PER_TYPE=32768
> > 
> > Ideally, it should be a run-time option.
> > 
> 
> It can be, yes, and this can be worked on for next release. However, we 
> also need to have good default values that work across all supported 
> platforms.

Yes sure, we can wait the next release for a run-time option.

How can we be sure these default values are good enough?
It would be good to have several acks from various projects or companies.

  reply	other threads:[~2018-07-24 12:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-24 10:03 Anatoly Burakov
2018-07-24 10:23 ` Thomas Monjalon
2018-07-24 11:04   ` Burakov, Anatoly
2018-07-24 12:03     ` Thomas Monjalon [this message]
2018-07-25 17:43       ` Kevin Traynor
2018-07-26  9:51         ` Burakov, Anatoly

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=6155181.arAJIN2bNs@xps \
    --to=thomas@monjalon.net \
    --cc=Ravi1.Kumar@amd.com \
    --cc=anatoly.burakov@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=damarion@cisco.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=ktraynor@redhat.com \
    --cc=olivier.matz@6wind.com \
    --cc=stephen@networkplumber.org \
    --cc=yskoh@mellanox.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).