From: Ilya Maximets <i.maximets@samsung.com>
To: dev@dpdk.org, Asaf Sinai <AsafSi@Radware.com>,
Anatoly Burakov <anatoly.burakov@intel.com>
Subject: Re: [dpdk-dev] CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES: no difference in memory pool allocations
Date: Mon, 26 Nov 2018 15:23:16 +0300 [thread overview]
Message-ID: <f8ba5d4f-0675-ee3c-adba-e816298e32f1@samsung.com> (raw)
In-Reply-To: <DB7PR01MB46354E3319774CC0EF16ED51CCD70@DB7PR01MB4635.eurprd01.prod.exchangelabs.com>
> Hi,
>
> We have 2 NUMAs in our system, and we try to allocate a single DPDK memory pool on each NUMA.
> However, we see no difference when enabling/disabling "CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES" configuration.
> We expected that disabling it will allocate pools only on one NUMA (probably NUMA0), but it actually allocates pools on both NUMAs, according to "socket_id" parameter passed to "rte_mempool_create" API.
> We have 192GB memory, so NUMA1 memory starts from address: 0x1800000000.
> As you can see below, "undDpdkPoolNameSocket_1" was indeed allocated on NUMA1, as we wanted, although "CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES" is disabled:
>
> CONFIG_RTE_LIBRTE_VHOST_NUMA=n
> CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
>
> created poolName=undDpdkPoolNameSocket_0, nbufs=887808, bufferSize=2432, total=2059MB
> (memZone: name=MP_undDpdkPoolNameSocket_0, socket_id=0, vaddr=0x1f2c0427d00-0x1f2c05abe00, paddr=0x178e627d00-0x178e7abe00, len=1589504, hugepage_sz=2MB)
> created poolName=undDpdkPoolNameSocket_1, nbufs=887808, bufferSize=2432, total=2059MB
> (memZone: name=MP_undDpdkPoolNameSocket_1, socket_id=1, vaddr=0x1f57fa7be40-0x1f57fbfff40, paddr=0x2f8247be40-0x2f825fff40, len=1589504, hugepage_sz=2MB)
>
> Does anyone know what is "CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES" configuration used for?
>
This config option was introduced to force DPDK to allocate memory
from NUMA nodes that was requested by 'socket_id'. That is exactly
what you're observing.
Look at the commit 1b72605d2416 ("mem: balanced allocation of hugepages")
for the original issue fixed by this option.
----
> Hi Asaf,
>
> I cannot reproduce this behavior. Just tried running testpmd with DPDK
> 18.08 as well as latest master [1], and DPDK could not successfully
> allocate a mempool on socket 1.
I think that this is a bug. Because, if option enabled, you should successfully
allocate the memory from the requested NUMA if it's available.
If option disabled, we just requesting pages from the kernel and it could
return them from any NUMA node. With option enabled, we're trying to
force kernel to allocate from the nodes we need.
Best regards, Ilya Maximets.
next prev parent reply other threads:[~2018-11-26 12:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-26 9:15 [dpdk-dev] CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES: no difference in memory pool allocations, when enabling/disabling this configuration Asaf Sinai
2018-11-26 11:09 ` Burakov, Anatoly
2018-11-26 11:33 ` Asaf Sinai
2018-11-26 11:43 ` Burakov, Anatoly
2018-11-26 12:50 ` Burakov, Anatoly
2018-11-26 13:16 ` Ilya Maximets
2018-11-26 13:20 ` Ilya Maximets
2018-11-26 13:42 ` Burakov, Anatoly
2018-11-26 14:10 ` Ilya Maximets
2018-11-26 14:21 ` Burakov, Anatoly
2018-11-26 14:32 ` Ilya Maximets
2018-11-26 14:57 ` Burakov, Anatoly
2018-11-26 15:25 ` Asaf Sinai
2018-11-27 10:26 ` Hemant Agrawal
2018-11-27 10:33 ` Burakov, Anatoly
2018-11-27 16:49 ` Ilya Maximets
2018-12-09 8:14 ` Asaf Sinai
2018-12-10 10:09 ` Burakov, Anatoly
2018-12-16 9:44 ` Asaf Sinai
[not found] ` <CGME20181126122321eucas1p1c8bfe7e1b74fc5cd71eec3a3c8929f5d@eucas1p1.samsung.com>
2018-11-26 12:23 ` Ilya Maximets [this message]
2018-11-26 12:46 ` [dpdk-dev] CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES: no difference in memory pool allocations Ilya Maximets
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=f8ba5d4f-0675-ee3c-adba-e816298e32f1@samsung.com \
--to=i.maximets@samsung.com \
--cc=AsafSi@Radware.com \
--cc=anatoly.burakov@intel.com \
--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).