[dpdk-dev,v2] mem: balanced allocation of hugepages
Checks
Commit Message
Currently EAL allocates hugepages one by one not paying
attention from which NUMA node allocation was done.
Such behaviour leads to allocation failure if number of
available hugepages for application limited by cgroups
or hugetlbfs and memory requested not only from the first
socket.
Example:
# 90 x 1GB hugepages availavle in a system
cgcreate -g hugetlb:/test
# Limit to 32GB of hugepages
cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test
# Request 4GB from each of 2 sockets
cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ...
EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
EAL: 32 not 90 hugepages of size 1024 MB allocated
EAL: Not enough memory available on socket 1!
Requested: 4096MB, available: 0MB
PANIC in rte_eal_init():
Cannot init memory
This happens beacause all allocated pages are
on socket 0.
Fix this issue by setting mempolicy MPOL_PREFERRED for each
hugepage to one of requested nodes in a round-robin fashion.
In this case all allocated pages will be fairly distributed
between all requested nodes.
New config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
introduced and disabled by default because of external
dependency from libnuma.
Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages")
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
---
Version 2:
* rebased (fuzz in Makefile)
config/common_base | 1 +
lib/librte_eal/Makefile | 4 ++
lib/librte_eal/linuxapp/eal/eal_memory.c | 65 ++++++++++++++++++++++++++++++++
mk/rte.app.mk | 3 ++
4 files changed, 73 insertions(+)
Comments
2017-04-10 11:04, Ilya Maximets:
> Currently EAL allocates hugepages one by one not paying
> attention from which NUMA node allocation was done.
>
> Such behaviour leads to allocation failure if number of
> available hugepages for application limited by cgroups
> or hugetlbfs and memory requested not only from the first
> socket.
>
> Example:
> # 90 x 1GB hugepages availavle in a system
>
> cgcreate -g hugetlb:/test
> # Limit to 32GB of hugepages
> cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test
> # Request 4GB from each of 2 sockets
> cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ...
>
> EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
> EAL: 32 not 90 hugepages of size 1024 MB allocated
> EAL: Not enough memory available on socket 1!
> Requested: 4096MB, available: 0MB
> PANIC in rte_eal_init():
> Cannot init memory
>
> This happens beacause all allocated pages are
> on socket 0.
>
> Fix this issue by setting mempolicy MPOL_PREFERRED for each
> hugepage to one of requested nodes in a round-robin fashion.
> In this case all allocated pages will be fairly distributed
> between all requested nodes.
>
> New config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> introduced and disabled by default because of external
> dependency from libnuma.
>
> Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages")
>
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Status: Changes Requested
per Sergio advice: "I would be inclined towards v3 targeting v17.08."
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 2 +-
lib/librte_eal/Makefile | 2 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 87 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 1 +
4 files changed, 87 insertions(+), 5 deletions(-)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 2 +-
lib/librte_eal/Makefile | 2 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 94 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 1 +
4 files changed, 94 insertions(+), 5 deletions(-)
Sorry for so frequent respinning of the series.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 94 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
4 files changed, 95 insertions(+), 5 deletions(-)
Hi everyone,
I just want to clarify current status of these patches.
As I understand, moving to the new build system (for example,
meson+ninja as proposed[1] by Bruce) is a very long process.
But we have issues with imbalanced memory allocation now, and
IMHO it's better to fix them in a near future.
Latest version (v5) of balanced allocation patches adds linbuma
as general unconditional dependency which conflicts with the
current DPDK policies.
So, there are 2 option:
1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and disable it by default.
2. Keep patch as it is now and make everyone install libnuma
for successful build.
I have no preferences about above options. I'm asking your opinions.
Bruce, Sergio, Thomas, what do you think?
[1] http://dpdk.org/ml/archives/dev/2017-June/067428.html
Best regards, Ilya Maximets.
On 06.06.2017 16:33, Ilya Maximets wrote:
> Sorry for so frequent respinning of the series.
>
> Version 5:
> * Fixed shared build. (Automated build test will fail
> anyway because libnuma-devel not installed on build servers)
>
> Version 4:
> * Fixed work on systems without NUMA by adding check for NUMA
> support in kernel.
>
> Version 3:
> * Implemented hybrid schema for allocation.
> * Fixed not needed mempolicy change while remapping. (orig = 0)
> * Added patch to enable VHOST_NUMA by default.
>
> Version 2:
> * rebased (fuzz in Makefile)
>
> Ilya Maximets (2):
> mem: balanced allocation of hugepages
> config: enable vhost numa awareness by default
>
> config/common_base | 2 +-
> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> lib/librte_eal/linuxapp/eal/eal_memory.c | 94 ++++++++++++++++++++++++++++++--
> mk/rte.app.mk | 3 +
> 4 files changed, 95 insertions(+), 5 deletions(-)
>
On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
> Hi everyone,
>
> I just want to clarify current status of these patches.
> As I understand, moving to the new build system (for example,
> meson+ninja as proposed[1] by Bruce) is a very long process.
> But we have issues with imbalanced memory allocation now, and
> IMHO it's better to fix them in a near future.
>
> Latest version (v5) of balanced allocation patches adds linbuma
> as general unconditional dependency which conflicts with the
> current DPDK policies.
>
> So, there are 2 option:
>
> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> from the first version of the patch and disable it by default.
>
> 2. Keep patch as it is now and make everyone install libnuma
> for successful build.
>
> I have no preferences about above options. I'm asking your opinions.
>
> Bruce, Sergio, Thomas, what do you think?
>
> [1] http://dpdk.org/ml/archives/dev/2017-June/067428.html
>
> Best regards, Ilya Maximets.
>
I would be ok with having libnuma as a dependency, so I think I'd prefer
option 2 to 1, assuming libnuma is available in all major Linux distros.
/Bruce
On 08/06/2017 13:14, Bruce Richardson wrote:
> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>> Hi everyone,
>>
>> I just want to clarify current status of these patches.
>> As I understand, moving to the new build system (for example,
>> meson+ninja as proposed[1] by Bruce) is a very long process.
>> But we have issues with imbalanced memory allocation now, and
>> IMHO it's better to fix them in a near future.
>>
>> Latest version (v5) of balanced allocation patches adds linbuma
>> as general unconditional dependency which conflicts with the
>> current DPDK policies.
>>
>> So, there are 2 option:
>>
>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>> from the first version of the patch and disable it by default.
>>
>> 2. Keep patch as it is now and make everyone install libnuma
>> for successful build.
>>
>> I have no preferences about above options. I'm asking your opinions.
>>
>> Bruce, Sergio, Thomas, what do you think?
>>
>> [1] http://dpdk.org/ml/archives/dev/2017-June/067428.html
>>
>> Best regards, Ilya Maximets.
>>
> I would be ok with having libnuma as a dependency, so I think I'd prefer
> option 2 to 1, assuming libnuma is available in all major Linux distros.
>
> /Bruce
+1 on option 2 (current patch and libnuma as DPDK dependency).
Sergio
On 08.06.2017 18:44, Sergio Gonzalez Monroy wrote:
> On 08/06/2017 13:14, Bruce Richardson wrote:
>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>> Hi everyone,
>>>
>>> I just want to clarify current status of these patches.
>>> As I understand, moving to the new build system (for example,
>>> meson+ninja as proposed[1] by Bruce) is a very long process.
>>> But we have issues with imbalanced memory allocation now, and
>>> IMHO it's better to fix them in a near future.
>>>
>>> Latest version (v5) of balanced allocation patches adds linbuma
>>> as general unconditional dependency which conflicts with the
>>> current DPDK policies.
>>>
>>> So, there are 2 option:
>>>
>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>> from the first version of the patch and disable it by default.
>>>
>>> 2. Keep patch as it is now and make everyone install libnuma
>>> for successful build.
>>>
>>> I have no preferences about above options. I'm asking your opinions.
>>>
>>> Bruce, Sergio, Thomas, what do you think?
>>>
>>> [1] http://dpdk.org/ml/archives/dev/2017-June/067428.html
>>>
>>> Best regards, Ilya Maximets.
>>>
>> I would be ok with having libnuma as a dependency, so I think I'd prefer
>> option 2 to 1, assuming libnuma is available in all major Linux distros.
>>
>> /Bruce
>
> +1 on option 2 (current patch and libnuma as DPDK dependency).
>
> Sergio
>
Ok. In this case I'm waiting for review.
And someone need to install libnuma development package in automatic
build test environment. Otherwise there will be constant compilation
test failures like this:
http://dpdk.org/ml/archives/test-report/2017-June/021437.html
Best regards, Ilya Maximets.
On 6/14/2017 11:41 AM, Ilya Maximets wrote:
> On 08.06.2017 18:44, Sergio Gonzalez Monroy wrote:
>> On 08/06/2017 13:14, Bruce Richardson wrote:
>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>> Hi everyone,
>>>>
>>>> I just want to clarify current status of these patches.
>>>> As I understand, moving to the new build system (for example,
>>>> meson+ninja as proposed[1] by Bruce) is a very long process.
>>>> But we have issues with imbalanced memory allocation now, and
>>>> IMHO it's better to fix them in a near future.
>>>>
>>>> Latest version (v5) of balanced allocation patches adds linbuma
>>>> as general unconditional dependency which conflicts with the
>>>> current DPDK policies.
>>>>
>>>> So, there are 2 option:
>>>>
>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>> from the first version of the patch and disable it by default.
>>>>
>>>> 2. Keep patch as it is now and make everyone install libnuma
>>>> for successful build.
>>>>
>>>> I have no preferences about above options. I'm asking your opinions.
>>>>
>>>> Bruce, Sergio, Thomas, what do you think?
>>>>
>>>> [1] http://dpdk.org/ml/archives/dev/2017-June/067428.html
>>>>
>>>> Best regards, Ilya Maximets.
>>>>
>>> I would be ok with having libnuma as a dependency, so I think I'd prefer
>>> option 2 to 1, assuming libnuma is available in all major Linux distros.
>>>
>>> /Bruce
>>
>> +1 on option 2 (current patch and libnuma as DPDK dependency).
>>
>> Sergio
>>
>
> Ok. In this case I'm waiting for review.
>
> And someone need to install libnuma development package in automatic
> build test environment. Otherwise there will be constant compilation
> test failures like this:
> http://dpdk.org/ml/archives/test-report/2017-June/021437.html
>
> Best regards, Ilya Maximets.
>
+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.
19/06/2017 13:10, Hemant Agrawal:
> >>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
> >>>> So, there are 2 option:
> >>>>
> >>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> >>>> from the first version of the patch and disable it by default.
> >>>>
> >>>> 2. Keep patch as it is now and make everyone install libnuma
> >>>> for successful build.
> >
> +1 for option 1
> It will be a issue and undesired dependency for SoCs, not supporting
> NUMA architecture.
>
> It can be added to the config, who desired to use it by default.
Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?
On 20.06.2017 16:07, Thomas Monjalon wrote:
> 19/06/2017 13:10, Hemant Agrawal:
>>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>>>> So, there are 2 option:
>>>>>>
>>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>> from the first version of the patch and disable it by default.
>>>>>>
>>>>>> 2. Keep patch as it is now and make everyone install libnuma
>>>>>> for successful build.
>>>
>> +1 for option 1
>> It will be a issue and undesired dependency for SoCs, not supporting
>> NUMA architecture.
>>
>> It can be added to the config, who desired to use it by default.
>
> Yes I agree, it cannot be a dependency for architectures which
> do not support NUMA.
> Please can we rework the patch so that only one node is assumed
> if NUMA is disabled for the architecture?
We're still don't have dynamic build time configuration system.
To make get/set_mempolicy work we need to include <numaif.h>
and have libnuma for successful linkage.
This means that the only option to not have libnuma as dependency
is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
as it was in the first version of the patch.
There is, actually, the third option (besides 2 already described):
3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and *enable* it by default.
In this case anyone who doesn't want to have libnuma as dependency
will be able to disable the config option manually.
Thomas, what do you think? Bruce? Sergio?
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.
20/06/2017 15:58, Ilya Maximets:
> On 20.06.2017 16:07, Thomas Monjalon wrote:
> > 19/06/2017 13:10, Hemant Agrawal:
> >>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
> >>>>>> So, there are 2 option:
> >>>>>>
> >>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> >>>>>> from the first version of the patch and disable it by default.
> >>>>>>
> >>>>>> 2. Keep patch as it is now and make everyone install libnuma
> >>>>>> for successful build.
> >>>
> >> +1 for option 1
> >> It will be a issue and undesired dependency for SoCs, not supporting
> >> NUMA architecture.
> >>
> >> It can be added to the config, who desired to use it by default.
> >
> > Yes I agree, it cannot be a dependency for architectures which
> > do not support NUMA.
> > Please can we rework the patch so that only one node is assumed
> > if NUMA is disabled for the architecture?
>
> We're still don't have dynamic build time configuration system.
> To make get/set_mempolicy work we need to include <numaif.h>
> and have libnuma for successful linkage.
> This means that the only option to not have libnuma as dependency
> is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> as it was in the first version of the patch.
>
> There is, actually, the third option (besides 2 already described):
>
> 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> from the first version of the patch and *enable* it by default.
> In this case anyone who doesn't want to have libnuma as dependency
> will be able to disable the config option manually.
>
> Thomas, what do you think? Bruce? Sergio?
It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).
> P.S. We're always able to implement syscall wrappers by hands without any
> external dependencies, but I don't think it's a good decision.
I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.
On 20/06/2017 15:35, Thomas Monjalon wrote:
> 20/06/2017 15:58, Ilya Maximets:
>> On 20.06.2017 16:07, Thomas Monjalon wrote:
>>> 19/06/2017 13:10, Hemant Agrawal:
>>>>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>>>>>> So, there are 2 option:
>>>>>>>>
>>>>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>>> from the first version of the patch and disable it by default.
>>>>>>>>
>>>>>>>> 2. Keep patch as it is now and make everyone install libnuma
>>>>>>>> for successful build.
>>>> +1 for option 1
>>>> It will be a issue and undesired dependency for SoCs, not supporting
>>>> NUMA architecture.
>>>>
>>>> It can be added to the config, who desired to use it by default.
>>> Yes I agree, it cannot be a dependency for architectures which
>>> do not support NUMA.
>>> Please can we rework the patch so that only one node is assumed
>>> if NUMA is disabled for the architecture?
Ilya, I missed that libnuma is not supported on ARM.
>> We're still don't have dynamic build time configuration system.
>> To make get/set_mempolicy work we need to include <numaif.h>
>> and have libnuma for successful linkage.
>> This means that the only option to not have libnuma as dependency
>> is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>> as it was in the first version of the patch.
>>
>> There is, actually, the third option (besides 2 already described):
>>
>> 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>> from the first version of the patch and *enable* it by default.
>> In this case anyone who doesn't want to have libnuma as dependency
>> will be able to disable the config option manually.
>>
>> Thomas, what do you think? Bruce? Sergio?
> It should be enabled on x86 and ppc, and disabled in other
> default configurations (ARM for now).
Agree.
>> P.S. We're always able to implement syscall wrappers by hands without any
>> external dependencies, but I don't think it's a good decision.
> I agree to use libnuma instead of re-inventing the wheel.
> Let's just make it optional at build time and fallback on one node
> if disabled.
That is the simple way out.
Sergio
-----Original Message-----
> Date: Tue, 20 Jun 2017 15:58:50 +0100
> From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> To: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
> <i.maximets@samsung.com>
> CC: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Bruce Richardson
> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
> Thunderbird/45.1.1
>
> On 20/06/2017 15:35, Thomas Monjalon wrote:
> > 20/06/2017 15:58, Ilya Maximets:
> > > On 20.06.2017 16:07, Thomas Monjalon wrote:
> > > > 19/06/2017 13:10, Hemant Agrawal:
> > > > > > > > On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
> > > > > > > > > So, there are 2 option:
> > > > > > > > >
> > > > > > > > > 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > > > > > > > from the first version of the patch and disable it by default.
> > > > > > > > >
> > > > > > > > > 2. Keep patch as it is now and make everyone install libnuma
> > > > > > > > > for successful build.
> > > > > +1 for option 1
> > > > > It will be a issue and undesired dependency for SoCs, not supporting
> > > > > NUMA architecture.
> > > > >
> > > > > It can be added to the config, who desired to use it by default.
> > > > Yes I agree, it cannot be a dependency for architectures which
> > > > do not support NUMA.
> > > > Please can we rework the patch so that only one node is assumed
> > > > if NUMA is disabled for the architecture?
>
> Ilya, I missed that libnuma is not supported on ARM.
It is supported on arm64 and arm64 has NUMA machines(thunderx, thunderx2) too.
[dpdk.org] $ dpkg-query -L libnuma-dev
/.
/usr
/usr/lib
/usr/lib/aarch64-linux-gnu
/usr/lib/aarch64-linux-gnu/libnuma.a
/usr/share
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/numa.3.gz
/usr/share/doc
/usr/share/doc/libnuma-dev
/usr/share/doc/libnuma-dev/copyright
/usr/include
/usr/include/numaif.h
/usr/include/numa.h
/usr/include/numacompat1.h
/usr/lib/aarch64-linux-gnu/libnuma.so
>
> > > We're still don't have dynamic build time configuration system.
> > > To make get/set_mempolicy work we need to include <numaif.h>
> > > and have libnuma for successful linkage.
> > > This means that the only option to not have libnuma as dependency
> > > is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > as it was in the first version of the patch.
> > >
> > > There is, actually, the third option (besides 2 already described):
> > >
> > > 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > from the first version of the patch and *enable* it by default.
> > > In this case anyone who doesn't want to have libnuma as dependency
> > > will be able to disable the config option manually.
> > >
> > > Thomas, what do you think? Bruce? Sergio?
> > It should be enabled on x86 and ppc, and disabled in other
> > default configurations (ARM for now).
>
> Agree.
>
> > > P.S. We're always able to implement syscall wrappers by hands without any
> > > external dependencies, but I don't think it's a good decision.
> > I agree to use libnuma instead of re-inventing the wheel.
> > Let's just make it optional at build time and fallback on one node
> > if disabled.
>
> That is the simple way out.
>
> Sergio
On 20/06/2017 16:41, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Tue, 20 Jun 2017 15:58:50 +0100
>> From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>> To: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
>> <i.maximets@samsung.com>
>> CC: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Bruce Richardson
>> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
>> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
>> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
>> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
>> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
>> Thunderbird/45.1.1
>>
>> On 20/06/2017 15:35, Thomas Monjalon wrote:
>>> 20/06/2017 15:58, Ilya Maximets:
>>>> On 20.06.2017 16:07, Thomas Monjalon wrote:
>>>>> 19/06/2017 13:10, Hemant Agrawal:
>>>>>>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>>>>>>>> So, there are 2 option:
>>>>>>>>>>
>>>>>>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>>>>> from the first version of the patch and disable it by default.
>>>>>>>>>>
>>>>>>>>>> 2. Keep patch as it is now and make everyone install libnuma
>>>>>>>>>> for successful build.
>>>>>> +1 for option 1
>>>>>> It will be a issue and undesired dependency for SoCs, not supporting
>>>>>> NUMA architecture.
>>>>>>
>>>>>> It can be added to the config, who desired to use it by default.
>>>>> Yes I agree, it cannot be a dependency for architectures which
>>>>> do not support NUMA.
>>>>> Please can we rework the patch so that only one node is assumed
>>>>> if NUMA is disabled for the architecture?
>> Ilya, I missed that libnuma is not supported on ARM.
> It is supported on arm64 and arm64 has NUMA machines(thunderx, thunderx2) too.
>
> [dpdk.org] $ dpkg-query -L libnuma-dev
> /.
> /usr
> /usr/lib
> /usr/lib/aarch64-linux-gnu
> /usr/lib/aarch64-linux-gnu/libnuma.a
> /usr/share
> /usr/share/man
> /usr/share/man/man3
> /usr/share/man/man3/numa.3.gz
> /usr/share/doc
> /usr/share/doc/libnuma-dev
> /usr/share/doc/libnuma-dev/copyright
> /usr/include
> /usr/include/numaif.h
> /usr/include/numa.h
> /usr/include/numacompat1.h
> /usr/lib/aarch64-linux-gnu/libnuma.so
>
Is it ARMv7 then the only supported arch missing libnuma support?
>>>> We're still don't have dynamic build time configuration system.
>>>> To make get/set_mempolicy work we need to include <numaif.h>
>>>> and have libnuma for successful linkage.
>>>> This means that the only option to not have libnuma as dependency
>>>> is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>> as it was in the first version of the patch.
>>>>
>>>> There is, actually, the third option (besides 2 already described):
>>>>
>>>> 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>> from the first version of the patch and *enable* it by default.
>>>> In this case anyone who doesn't want to have libnuma as dependency
>>>> will be able to disable the config option manually.
>>>>
>>>> Thomas, what do you think? Bruce? Sergio?
>>> It should be enabled on x86 and ppc, and disabled in other
>>> default configurations (ARM for now).
>> Agree.
>>
>>>> P.S. We're always able to implement syscall wrappers by hands without any
>>>> external dependencies, but I don't think it's a good decision.
>>> I agree to use libnuma instead of re-inventing the wheel.
>>> Let's just make it optional at build time and fallback on one node
>>> if disabled.
>> That is the simple way out.
>>
>> Sergio
Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
returned. Enabled by default for x86, ppc and thunderx.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 1 +
config/common_linuxapp | 3 +
config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
config/defconfig_arm64-armv8a-linuxapp-gcc | 4 +
config/defconfig_arm64-thunderx-linuxapp-gcc | 4 +
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++-
mk/rte.app.mk | 3 +
8 files changed, 123 insertions(+), 4 deletions(-)
On 6/20/2017 9:11 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Tue, 20 Jun 2017 15:58:50 +0100
>> From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>> To: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
>> <i.maximets@samsung.com>
>> CC: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Bruce Richardson
>> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
>> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
>> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
>> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
>> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
>> Thunderbird/45.1.1
>>
>> On 20/06/2017 15:35, Thomas Monjalon wrote:
>>> 20/06/2017 15:58, Ilya Maximets:
>>>> On 20.06.2017 16:07, Thomas Monjalon wrote:
>>>>> 19/06/2017 13:10, Hemant Agrawal:
>>>>>>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>>>>>>>> So, there are 2 option:
>>>>>>>>>>
>>>>>>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>>>>> from the first version of the patch and disable it by default.
>>>>>>>>>>
>>>>>>>>>> 2. Keep patch as it is now and make everyone install libnuma
>>>>>>>>>> for successful build.
>>>>>> +1 for option 1
>>>>>> It will be a issue and undesired dependency for SoCs, not supporting
>>>>>> NUMA architecture.
>>>>>>
>>>>>> It can be added to the config, who desired to use it by default.
>>>>> Yes I agree, it cannot be a dependency for architectures which
>>>>> do not support NUMA.
>>>>> Please can we rework the patch so that only one node is assumed
>>>>> if NUMA is disabled for the architecture?
>>
>> Ilya, I missed that libnuma is not supported on ARM.
>
> It is supported on arm64 and arm64 has NUMA machines(thunderx, thunderx2) too.
>
> [dpdk.org] $ dpkg-query -L libnuma-dev
> /.
> /usr
> /usr/lib
> /usr/lib/aarch64-linux-gnu
> /usr/lib/aarch64-linux-gnu/libnuma.a
> /usr/share
> /usr/share/man
> /usr/share/man/man3
> /usr/share/man/man3/numa.3.gz
> /usr/share/doc
> /usr/share/doc/libnuma-dev
> /usr/share/doc/libnuma-dev/copyright
> /usr/include
> /usr/include/numaif.h
> /usr/include/numa.h
> /usr/include/numacompat1.h
> /usr/lib/aarch64-linux-gnu/libnuma.so
>
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
2. I could not locate it by default in Linaro toolchains.
3. Since this is not a common across all platform. This option should
not be added to the common_base or common configs. It can be added to
any architecture configuration, which needs it.
Regards,
Hemant
>
>>
>>>> We're still don't have dynamic build time configuration system.
>>>> To make get/set_mempolicy work we need to include <numaif.h>
>>>> and have libnuma for successful linkage.
>>>> This means that the only option to not have libnuma as dependency
>>>> is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>> as it was in the first version of the patch.
>>>>
>>>> There is, actually, the third option (besides 2 already described):
>>>>
>>>> 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>> from the first version of the patch and *enable* it by default.
>>>> In this case anyone who doesn't want to have libnuma as dependency
>>>> will be able to disable the config option manually.
>>>>
>>>> Thomas, what do you think? Bruce? Sergio?
>>> It should be enabled on x86 and ppc, and disabled in other
>>> default configurations (ARM for now).
>>
>> Agree.
>>
>>>> P.S. We're always able to implement syscall wrappers by hands without any
>>>> external dependencies, but I don't think it's a good decision.
>>> I agree to use libnuma instead of re-inventing the wheel.
>>> Let's just make it optional at build time and fallback on one node
>>> if disabled.
>>
>> That is the simple way out.
>>
>> Sergio
>
On 21/06/2017 09:14, Hemant Agrawal wrote:
> On 6/20/2017 9:11 PM, Jerin Jacob wrote:
>> -----Original Message-----
>>> Date: Tue, 20 Jun 2017 15:58:50 +0100
>>> From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>>> To: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
>>> <i.maximets@samsung.com>
>>> CC: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Bruce
>>> Richardson
>>> <bruce.richardson@intel.com>, David Marchand
>>> <david.marchand@6wind.com>,
>>> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu
>>> <yliu@fridaylinux.org>,
>>> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
>>> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
>>> Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
>>> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
>>> Thunderbird/45.1.1
>>>
>>> On 20/06/2017 15:35, Thomas Monjalon wrote:
>>>> 20/06/2017 15:58, Ilya Maximets:
>>>>> On 20.06.2017 16:07, Thomas Monjalon wrote:
>>>>>> 19/06/2017 13:10, Hemant Agrawal:
>>>>>>>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>>>>>>>>> So, there are 2 option:
>>>>>>>>>>>
>>>>>>>>>>> 1. Return back config option
>>>>>>>>>>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>>>>>> from the first version of the patch and disable it
>>>>>>>>>>> by default.
>>>>>>>>>>>
>>>>>>>>>>> 2. Keep patch as it is now and make everyone install
>>>>>>>>>>> libnuma
>>>>>>>>>>> for successful build.
>>>>>>> +1 for option 1
>>>>>>> It will be a issue and undesired dependency for SoCs, not
>>>>>>> supporting
>>>>>>> NUMA architecture.
>>>>>>>
>>>>>>> It can be added to the config, who desired to use it by default.
>>>>>> Yes I agree, it cannot be a dependency for architectures which
>>>>>> do not support NUMA.
>>>>>> Please can we rework the patch so that only one node is assumed
>>>>>> if NUMA is disabled for the architecture?
>>>
>>> Ilya, I missed that libnuma is not supported on ARM.
>>
>> It is supported on arm64 and arm64 has NUMA machines(thunderx,
>> thunderx2) too.
>>
>> [dpdk.org] $ dpkg-query -L libnuma-dev
>> /.
>> /usr
>> /usr/lib
>> /usr/lib/aarch64-linux-gnu
>> /usr/lib/aarch64-linux-gnu/libnuma.a
>> /usr/share
>> /usr/share/man
>> /usr/share/man/man3
>> /usr/share/man/man3/numa.3.gz
>> /usr/share/doc
>> /usr/share/doc/libnuma-dev
>> /usr/share/doc/libnuma-dev/copyright
>> /usr/include
>> /usr/include/numaif.h
>> /usr/include/numa.h
>> /usr/include/numacompat1.h
>> /usr/lib/aarch64-linux-gnu/libnuma.so
>>
>
> 1. There are many machines (arm/ppc), which do not support NUMA.
>
> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
>
I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources,
but Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl
> 2. I could not locate it by default in Linaro toolchains.
>
> 3. Since this is not a common across all platform. This option should
> not be added to the common_base or common configs. It can be added to
> any architecture configuration, which needs it.
>
So is it thunderx the only arm64 to enable this feature by default?
I thought the dependency was the libnuma library support itself.
Thanks,
Sergio
> Regards,
> Hemant
>
>>
>>>
>>>>> We're still don't have dynamic build time configuration system.
>>>>> To make get/set_mempolicy work we need to include <numaif.h>
>>>>> and have libnuma for successful linkage.
>>>>> This means that the only option to not have libnuma as dependency
>>>>> is to return back configuration option
>>>>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>> as it was in the first version of the patch.
>>>>>
>>>>> There is, actually, the third option (besides 2 already described):
>>>>>
>>>>> 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>> from the first version of the patch and *enable* it by
>>>>> default.
>>>>> In this case anyone who doesn't want to have libnuma as
>>>>> dependency
>>>>> will be able to disable the config option manually.
>>>>>
>>>>> Thomas, what do you think? Bruce? Sergio?
>>>> It should be enabled on x86 and ppc, and disabled in other
>>>> default configurations (ARM for now).
>>>
>>> Agree.
>>>
>>>>> P.S. We're always able to implement syscall wrappers by hands
>>>>> without any
>>>>> external dependencies, but I don't think it's a good decision.
>>>> I agree to use libnuma instead of re-inventing the wheel.
>>>> Let's just make it optional at build time and fallback on one node
>>>> if disabled.
>>>
>>> That is the simple way out.
>>>
>>> Sergio
>>
>
>
On 21.06.2017 11:25, Sergio Gonzalez Monroy wrote:
> On 21/06/2017 09:14, Hemant Agrawal wrote:
>> On 6/20/2017 9:11 PM, Jerin Jacob wrote:
>>> -----Original Message-----
>>>> Date: Tue, 20 Jun 2017 15:58:50 +0100
>>>> From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>>>> To: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
>>>> <i.maximets@samsung.com>
>>>> CC: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Bruce Richardson
>>>> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
>>>> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
>>>> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
>>>> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
>>>> Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
>>>> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
>>>> Thunderbird/45.1.1
>>>>
>>>> On 20/06/2017 15:35, Thomas Monjalon wrote:
>>>>> 20/06/2017 15:58, Ilya Maximets:
>>>>>> On 20.06.2017 16:07, Thomas Monjalon wrote:
>>>>>>> 19/06/2017 13:10, Hemant Agrawal:
>>>>>>>>>>> On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
>>>>>>>>>>>> So, there are 2 option:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>>>>>>> from the first version of the patch and disable it by default.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Keep patch as it is now and make everyone install libnuma
>>>>>>>>>>>> for successful build.
>>>>>>>> +1 for option 1
>>>>>>>> It will be a issue and undesired dependency for SoCs, not supporting
>>>>>>>> NUMA architecture.
>>>>>>>>
>>>>>>>> It can be added to the config, who desired to use it by default.
>>>>>>> Yes I agree, it cannot be a dependency for architectures which
>>>>>>> do not support NUMA.
>>>>>>> Please can we rework the patch so that only one node is assumed
>>>>>>> if NUMA is disabled for the architecture?
>>>>
>>>> Ilya, I missed that libnuma is not supported on ARM.
>>>
>>> It is supported on arm64 and arm64 has NUMA machines(thunderx, thunderx2) too.
>>>
>>> [dpdk.org] $ dpkg-query -L libnuma-dev
>>> /.
>>> /usr
>>> /usr/lib
>>> /usr/lib/aarch64-linux-gnu
>>> /usr/lib/aarch64-linux-gnu/libnuma.a
>>> /usr/share
>>> /usr/share/man
>>> /usr/share/man/man3
>>> /usr/share/man/man3/numa.3.gz
>>> /usr/share/doc
>>> /usr/share/doc/libnuma-dev
>>> /usr/share/doc/libnuma-dev/copyright
>>> /usr/include
>>> /usr/include/numaif.h
>>> /usr/include/numa.h
>>> /usr/include/numacompat1.h
>>> /usr/lib/aarch64-linux-gnu/libnuma.so
>>>
>>
>> 1. There are many machines (arm/ppc), which do not support NUMA.
>>
>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
>>
>
> I did find that link too, last modified 4 years ago.
> Despite that, I could not find any ARM references in libnuma sources, but Jerin proved that there is support for it.
>
> http://oss.sgi.com/projects/libnuma/
> https://github.com/numactl/numactl
>
>> 2. I could not locate it by default in Linaro toolchains.
>>
>> 3. Since this is not a common across all platform. This option should not be added to the common_base or common configs. It can be added to any architecture configuration, which needs it.
>>
>
> So is it thunderx the only arm64 to enable this feature by default?
> I thought the dependency was the libnuma library support itself.
ARMv7 is the only architecture without libnuma package in common distros.
So, in v6 I enabled this feature by default for x86, ppc and thunderx.
I didn't enable it for the whole ARMv8 just because thunderx is the only
platform which supports NUMA and has special defconfig in DPDK repository.
Best regards, Ilya Maximets.
>>>>
>>>>>> We're still don't have dynamic build time configuration system.
>>>>>> To make get/set_mempolicy work we need to include <numaif.h>
>>>>>> and have libnuma for successful linkage.
>>>>>> This means that the only option to not have libnuma as dependency
>>>>>> is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>> as it was in the first version of the patch.
>>>>>>
>>>>>> There is, actually, the third option (besides 2 already described):
>>>>>>
>>>>>> 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>> from the first version of the patch and *enable* it by default.
>>>>>> In this case anyone who doesn't want to have libnuma as dependency
>>>>>> will be able to disable the config option manually.
>>>>>>
>>>>>> Thomas, what do you think? Bruce? Sergio?
>>>>> It should be enabled on x86 and ppc, and disabled in other
>>>>> default configurations (ARM for now).
>>>>
>>>> Agree.
>>>>
>>>>>> P.S. We're always able to implement syscall wrappers by hands without any
>>>>>> external dependencies, but I don't think it's a good decision.
>>>>> I agree to use libnuma instead of re-inventing the wheel.
>>>>> Let's just make it optional at build time and fallback on one node
>>>>> if disabled.
>>>>
>>>> That is the simple way out.
>>>>
>>>> Sergio
>>>
>>
>>
>
>
>
>
-----Original Message-----
> Date: Wed, 21 Jun 2017 09:25:25 +0100
> From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> To: Hemant Agrawal <hemant.agrawal@nxp.com>, Jerin Jacob
> <jerin.jacob@caviumnetworks.com>
> CC: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
> <i.maximets@samsung.com>, dev@dpdk.org, Bruce Richardson
> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
> Thunderbird/45.1.1
>
> On 21/06/2017 09:14, Hemant Agrawal wrote:
> > On 6/20/2017 9:11 PM, Jerin Jacob wrote:
> > > -----Original Message-----
> > > > Date: Tue, 20 Jun 2017 15:58:50 +0100
> > > > From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> > > > To: Thomas Monjalon <thomas@monjalon.net>, Ilya Maximets
> > > > <i.maximets@samsung.com>
> > > > CC: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Bruce
> > > > Richardson
> > > > <bruce.richardson@intel.com>, David Marchand
> > > > <david.marchand@6wind.com>,
> > > > Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu
> > > > <yliu@fridaylinux.org>,
> > > > Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
> > > > <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
> > > > Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
> > > > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
> > > > Thunderbird/45.1.1
> > > >
> > > > On 20/06/2017 15:35, Thomas Monjalon wrote:
> > > > > 20/06/2017 15:58, Ilya Maximets:
> > > > > > On 20.06.2017 16:07, Thomas Monjalon wrote:
> > > > > > > 19/06/2017 13:10, Hemant Agrawal:
> > > > > > > > > > > On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote:
> > > > > > > > > > > > So, there are 2 option:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. Return back config
> > > > > > > > > > > > option
> > > > > > > > > > > > RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > > > > > > > > > > from the first version
> > > > > > > > > > > > of the patch and disable it by
> > > > > > > > > > > > default.
> > > > > > > > > > > >
> > > > > > > > > > > > 2. Keep patch as it is now
> > > > > > > > > > > > and make everyone install
> > > > > > > > > > > > libnuma
> > > > > > > > > > > > for successful build.
> > > > > > > > +1 for option 1
> > > > > > > > It will be a issue and undesired dependency for
> > > > > > > > SoCs, not supporting
> > > > > > > > NUMA architecture.
> > > > > > > >
> > > > > > > > It can be added to the config, who desired to use it by default.
> > > > > > > Yes I agree, it cannot be a dependency for architectures which
> > > > > > > do not support NUMA.
> > > > > > > Please can we rework the patch so that only one node is assumed
> > > > > > > if NUMA is disabled for the architecture?
> > > >
> > > > Ilya, I missed that libnuma is not supported on ARM.
> > >
> > > It is supported on arm64 and arm64 has NUMA machines(thunderx,
> > > thunderx2) too.
> > >
> > > [dpdk.org] $ dpkg-query -L libnuma-dev
> > > /.
> > > /usr
> > > /usr/lib
> > > /usr/lib/aarch64-linux-gnu
> > > /usr/lib/aarch64-linux-gnu/libnuma.a
> > > /usr/share
> > > /usr/share/man
> > > /usr/share/man/man3
> > > /usr/share/man/man3/numa.3.gz
> > > /usr/share/doc
> > > /usr/share/doc/libnuma-dev
> > > /usr/share/doc/libnuma-dev/copyright
> > > /usr/include
> > > /usr/include/numaif.h
> > > /usr/include/numa.h
> > > /usr/include/numacompat1.h
> > > /usr/lib/aarch64-linux-gnu/libnuma.so
> > >
> >
> > 1. There are many machines (arm/ppc), which do not support NUMA.
> >
> > https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> >
>
> I did find that link too, last modified 4 years ago.
> Despite that, I could not find any ARM references in libnuma sources, but
> Jerin proved that there is support for it.
>
> http://oss.sgi.com/projects/libnuma/
> https://github.com/numactl/numactl
Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
Some example in linux kernel build system:
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
>
> > 2. I could not locate it by default in Linaro toolchains.
> >
> > 3. Since this is not a common across all platform. This option should
> > not be added to the common_base or common configs. It can be added to
> > any architecture configuration, which needs it.
> >
>
> So is it thunderx the only arm64 to enable this feature by default?
> I thought the dependency was the libnuma library support itself.
>
> Thanks,
> Sergio
>
> > Regards,
> > Hemant
> >
> > >
> > > >
> > > > > > We're still don't have dynamic build time configuration system.
> > > > > > To make get/set_mempolicy work we need to include <numaif.h>
> > > > > > and have libnuma for successful linkage.
> > > > > > This means that the only option to not have libnuma as dependency
> > > > > > is to return back configuration option
> > > > > > RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > > > > as it was in the first version of the patch.
> > > > > >
> > > > > > There is, actually, the third option (besides 2 already described):
> > > > > >
> > > > > > 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > > > > from the first version of the patch and *enable*
> > > > > > it by default.
> > > > > > In this case anyone who doesn't want to have
> > > > > > libnuma as dependency
> > > > > > will be able to disable the config option manually.
> > > > > >
> > > > > > Thomas, what do you think? Bruce? Sergio?
> > > > > It should be enabled on x86 and ppc, and disabled in other
> > > > > default configurations (ARM for now).
> > > >
> > > > Agree.
> > > >
> > > > > > P.S. We're always able to implement syscall wrappers by
> > > > > > hands without any
> > > > > > external dependencies, but I don't think it's a good decision.
> > > > > I agree to use libnuma instead of re-inventing the wheel.
> > > > > Let's just make it optional at build time and fallback on one node
> > > > > if disabled.
> > > >
> > > > That is the simple way out.
> > > >
> > > > Sergio
> > >
> >
> >
>
21/06/2017 10:41, Jerin Jacob:
> > > 1. There are many machines (arm/ppc), which do not support NUMA.
> > >
> > > https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> > >
> >
> > I did find that link too, last modified 4 years ago.
> > Despite that, I could not find any ARM references in libnuma sources, but
> > Jerin proved that there is support for it.
> >
> > http://oss.sgi.com/projects/libnuma/
> > https://github.com/numactl/numactl
>
> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> I guess we are talking about build time time dependency with libnuma here.
> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> libnuma if it is present in rootfs. Just that at runtime, it will return
> NUMA support not available. Correct?
>
> How hard is detect the presence of "numaif.h" if existing build system does not
> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> if build environment has "numaif.h".
>
> Some example in linux kernel build system:
> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.
If someone really wants to build DPDK without NUMA for x86, he should
disable it in the build config file.
-----Original Message-----
> Date: Wed, 21 Jun 2017 10:49:14 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
> Marchand <david.marchand@6wind.com>, Heetae Ahn
> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> Pei <yulong.pei@intel.com>
> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>
> 21/06/2017 10:41, Jerin Jacob:
> > > > 1. There are many machines (arm/ppc), which do not support NUMA.
> > > >
> > > > https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> > > >
> > >
> > > I did find that link too, last modified 4 years ago.
> > > Despite that, I could not find any ARM references in libnuma sources, but
> > > Jerin proved that there is support for it.
> > >
> > > http://oss.sgi.com/projects/libnuma/
> > > https://github.com/numactl/numactl
> >
> > Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> > I guess we are talking about build time time dependency with libnuma here.
> > Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> > libnuma if it is present in rootfs. Just that at runtime, it will return
> > NUMA support not available. Correct?
> >
> > How hard is detect the presence of "numaif.h" if existing build system does not
> > support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > if build environment has "numaif.h".
> >
> > Some example in linux kernel build system:
> > http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
>
> I think we should not try to detect numaif.h, because it should be
> an error on platform supporting NUMA.
I have installed libnuma on a NUMA and non NUMA machine.
Compiled and ran following code on those machine and it could detect
the numa availability. Could you add more details on the "error on
platform supporting NUMA".
➜ 83xx [ctest] $ cat main.c
#include <numaif.h>
#include <stdio.h>
#include <errno.h>
int main()
{
/* Check if kernel supports NUMA. */
if (get_mempolicy(NULL, NULL, 0, 0, 0) < 0 && errno == ENOSYS) {
printf("NUMA is not supported.\n");
} else {
printf("NUMA is supported.\n");
}
}
➜ 83xx [ctest] $ gcc -Wall main.c -lnuma
# On non numa system
➜ 83xx [ctest] $ ./a.out
NUMA is not supported
# On numa machine
➜ GB-2S [~] $ ./a.out
NUMA is supported.
> If someone really wants to build DPDK without NUMA for x86, he should
> disable it in the build config file.
21/06/2017 11:27, Jerin Jacob:
> -----Original Message-----
> > Date: Wed, 21 Jun 2017 10:49:14 +0200
> > From: Thomas Monjalon <thomas@monjalon.net>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> > Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
> > dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
> > Marchand <david.marchand@6wind.com>, Heetae Ahn
> > <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> > Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> > Pei <yulong.pei@intel.com>
> > Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
> >
> > 21/06/2017 10:41, Jerin Jacob:
> > > > > 1. There are many machines (arm/ppc), which do not support NUMA.
> > > > >
> > > > > https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> > > > >
> > > >
> > > > I did find that link too, last modified 4 years ago.
> > > > Despite that, I could not find any ARM references in libnuma sources, but
> > > > Jerin proved that there is support for it.
> > > >
> > > > http://oss.sgi.com/projects/libnuma/
> > > > https://github.com/numactl/numactl
> > >
> > > Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> > > I guess we are talking about build time time dependency with libnuma here.
> > > Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> > > libnuma if it is present in rootfs. Just that at runtime, it will return
> > > NUMA support not available. Correct?
> > >
> > > How hard is detect the presence of "numaif.h" if existing build system does not
> > > support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > if build environment has "numaif.h".
> > >
> > > Some example in linux kernel build system:
> > > http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
> >
> > I think we should not try to detect numaif.h, because it should be
> > an error on platform supporting NUMA.
>
> I have installed libnuma on a NUMA and non NUMA machine.
> Compiled and ran following code on those machine and it could detect
> the numa availability. Could you add more details on the "error on
> platform supporting NUMA".
I was saying that we do not need to detect NUMA.
If we are building DPDK for a NUMA architecture and libnuma is not
available, then it will be a problem that the user must catch.
The easiest way to catch it, is to fail on the include of numaif.h.
Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
returned. Enabled by default for x86, ppc and thunderx.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 1 +
config/common_linuxapp | 3 +
config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
config/defconfig_arm64-armv8a-linuxapp-gcc | 4 +
config/defconfig_arm64-thunderx-linuxapp-gcc | 4 +
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++-
mk/rte.app.mk | 3 +
8 files changed, 123 insertions(+), 4 deletions(-)
-----Original Message-----
> Date: Wed, 21 Jun 2017 11:58:12 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
> Marchand <david.marchand@6wind.com>, Heetae Ahn
> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> Pei <yulong.pei@intel.com>
> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>
> 21/06/2017 11:27, Jerin Jacob:
> > -----Original Message-----
> > > Date: Wed, 21 Jun 2017 10:49:14 +0200
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> > > Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
> > > dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
> > > Marchand <david.marchand@6wind.com>, Heetae Ahn
> > > <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> > > Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> > > Pei <yulong.pei@intel.com>
> > > Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
> > >
> > > 21/06/2017 10:41, Jerin Jacob:
> > > > > > 1. There are many machines (arm/ppc), which do not support NUMA.
> > > > > >
> > > > > > https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> > > > > >
> > > > >
> > > > > I did find that link too, last modified 4 years ago.
> > > > > Despite that, I could not find any ARM references in libnuma sources, but
> > > > > Jerin proved that there is support for it.
> > > > >
> > > > > http://oss.sgi.com/projects/libnuma/
> > > > > https://github.com/numactl/numactl
> > > >
> > > > Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> > > > I guess we are talking about build time time dependency with libnuma here.
> > > > Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> > > > libnuma if it is present in rootfs. Just that at runtime, it will return
> > > > NUMA support not available. Correct?
> > > >
> > > > How hard is detect the presence of "numaif.h" if existing build system does not
> > > > support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > > > if build environment has "numaif.h".
> > > >
> > > > Some example in linux kernel build system:
> > > > http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
> > >
> > > I think we should not try to detect numaif.h, because it should be
> > > an error on platform supporting NUMA.
> >
> > I have installed libnuma on a NUMA and non NUMA machine.
> > Compiled and ran following code on those machine and it could detect
> > the numa availability. Could you add more details on the "error on
> > platform supporting NUMA".
>
> I was saying that we do not need to detect NUMA.
> If we are building DPDK for a NUMA architecture and libnuma is not
> available, then it will be a problem that the user must catch.
> The easiest way to catch it, is to fail on the include of numaif.h.
libnuma is not really _architecture_ depended.
Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.
IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
No strong opinion on "failing the build" vs "printing a warning" in the
absence of numaif.h
On 21.06.2017 13:29, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Wed, 21 Jun 2017 11:58:12 +0200
>> From: Thomas Monjalon <thomas@monjalon.net>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
>> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
>> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
>> Marchand <david.marchand@6wind.com>, Heetae Ahn
>> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
>> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
>> Pei <yulong.pei@intel.com>
>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>>
>> 21/06/2017 11:27, Jerin Jacob:
>>> -----Original Message-----
>>>> Date: Wed, 21 Jun 2017 10:49:14 +0200
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
>>>> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
>>>> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
>>>> Marchand <david.marchand@6wind.com>, Heetae Ahn
>>>> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
>>>> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
>>>> Pei <yulong.pei@intel.com>
>>>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>>>>
>>>> 21/06/2017 10:41, Jerin Jacob:
>>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA.
>>>>>>>
>>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
>>>>>>>
>>>>>>
>>>>>> I did find that link too, last modified 4 years ago.
>>>>>> Despite that, I could not find any ARM references in libnuma sources, but
>>>>>> Jerin proved that there is support for it.
>>>>>>
>>>>>> http://oss.sgi.com/projects/libnuma/
>>>>>> https://github.com/numactl/numactl
>>>>>
>>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
>>>>> I guess we are talking about build time time dependency with libnuma here.
>>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
>>>>> libnuma if it is present in rootfs. Just that at runtime, it will return
>>>>> NUMA support not available. Correct?
>>>>>
>>>>> How hard is detect the presence of "numaif.h" if existing build system does not
>>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>> if build environment has "numaif.h".
>>>>>
>>>>> Some example in linux kernel build system:
>>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
>>>>
>>>> I think we should not try to detect numaif.h, because it should be
>>>> an error on platform supporting NUMA.
>>>
>>> I have installed libnuma on a NUMA and non NUMA machine.
>>> Compiled and ran following code on those machine and it could detect
>>> the numa availability. Could you add more details on the "error on
>>> platform supporting NUMA".
>>
>> I was saying that we do not need to detect NUMA.
>> If we are building DPDK for a NUMA architecture and libnuma is not
>> available, then it will be a problem that the user must catch.
>> The easiest way to catch it, is to fail on the include of numaif.h.
>
> libnuma is not really _architecture_ depended.
>
> Ilya Maximets patch disables NUMA support in common arm64 config.I
> think, It is not correct, We should not disable on any archs generic config.
>
> IMO, It should be enabled by default in common config and then we can
> detect the presence of numaif.h, if not available OR a target does not need it
> explicitly, proceed with disabling
> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.
> No strong opinion on "failing the build" vs "printing a warning" in the
> absence of numaif.h
-----Original Message-----
> Date: Wed, 21 Jun 2017 13:36:58 +0300
> From: Ilya Maximets <i.maximets@samsung.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Thomas Monjalon
> <thomas@monjalon.net>
> CC: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> Agrawal <hemant.agrawal@nxp.com>, dev@dpdk.org, Bruce Richardson
> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
> Thunderbird/45.8.0
>
> On 21.06.2017 13:29, Jerin Jacob wrote:
> > -----Original Message-----
> >> Date: Wed, 21 Jun 2017 11:58:12 +0200
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> >> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
> >> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
> >> Marchand <david.marchand@6wind.com>, Heetae Ahn
> >> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> >> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> >> Pei <yulong.pei@intel.com>
> >> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
> >>
> >> 21/06/2017 11:27, Jerin Jacob:
> >>> -----Original Message-----
> >>>> Date: Wed, 21 Jun 2017 10:49:14 +0200
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> >>>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> >>>> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
> >>>> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
> >>>> Marchand <david.marchand@6wind.com>, Heetae Ahn
> >>>> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> >>>> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> >>>> Pei <yulong.pei@intel.com>
> >>>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
> >>>>
> >>>> 21/06/2017 10:41, Jerin Jacob:
> >>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA.
> >>>>>>>
> >>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> >>>>>>>
> >>>>>>
> >>>>>> I did find that link too, last modified 4 years ago.
> >>>>>> Despite that, I could not find any ARM references in libnuma sources, but
> >>>>>> Jerin proved that there is support for it.
> >>>>>>
> >>>>>> http://oss.sgi.com/projects/libnuma/
> >>>>>> https://github.com/numactl/numactl
> >>>>>
> >>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> >>>>> I guess we are talking about build time time dependency with libnuma here.
> >>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> >>>>> libnuma if it is present in rootfs. Just that at runtime, it will return
> >>>>> NUMA support not available. Correct?
> >>>>>
> >>>>> How hard is detect the presence of "numaif.h" if existing build system does not
> >>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> >>>>> if build environment has "numaif.h".
> >>>>>
> >>>>> Some example in linux kernel build system:
> >>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
> >>>>
> >>>> I think we should not try to detect numaif.h, because it should be
> >>>> an error on platform supporting NUMA.
> >>>
> >>> I have installed libnuma on a NUMA and non NUMA machine.
> >>> Compiled and ran following code on those machine and it could detect
> >>> the numa availability. Could you add more details on the "error on
> >>> platform supporting NUMA".
> >>
> >> I was saying that we do not need to detect NUMA.
> >> If we are building DPDK for a NUMA architecture and libnuma is not
> >> available, then it will be a problem that the user must catch.
> >> The easiest way to catch it, is to fail on the include of numaif.h.
> >
> > libnuma is not really _architecture_ depended.
> >
> > Ilya Maximets patch disables NUMA support in common arm64 config.I
> > think, It is not correct, We should not disable on any archs generic config.
> >
> > IMO, It should be enabled by default in common config and then we can
> > detect the presence of numaif.h, if not available OR a target does not need it
> > explicitly, proceed with disabling
> > RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
>
> Detecting of headers is impossible until dpdk doesn't have dynamic build
> configuration system like autotools, CMake or meson.
> Right now we just can't do that.
I agree. Unless if we do something like linux kernel does it below
http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.
>
> > No strong opinion on "failing the build" vs "printing a warning" in the
> > absence of numaif.h
21/06/2017 13:22, Jerin Jacob:
> From: Ilya Maximets <i.maximets@samsung.com>
> > On 21.06.2017 13:29, Jerin Jacob wrote:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > >> 21/06/2017 11:27, Jerin Jacob:
> > >>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>> 21/06/2017 10:41, Jerin Jacob:
> > >>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA.
> > >>>>>>>
> > >>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> > >>>>>>>
> > >>>>>>
> > >>>>>> I did find that link too, last modified 4 years ago.
> > >>>>>> Despite that, I could not find any ARM references in libnuma sources, but
> > >>>>>> Jerin proved that there is support for it.
> > >>>>>>
> > >>>>>> http://oss.sgi.com/projects/libnuma/
> > >>>>>> https://github.com/numactl/numactl
> > >>>>>
> > >>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> > >>>>> I guess we are talking about build time time dependency with libnuma here.
> > >>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> > >>>>> libnuma if it is present in rootfs. Just that at runtime, it will return
> > >>>>> NUMA support not available. Correct?
> > >>>>>
> > >>>>> How hard is detect the presence of "numaif.h" if existing build system does not
> > >>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > >>>>> if build environment has "numaif.h".
> > >>>>>
> > >>>>> Some example in linux kernel build system:
> > >>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
> > >>>>
> > >>>> I think we should not try to detect numaif.h, because it should be
> > >>>> an error on platform supporting NUMA.
> > >>>
> > >>> I have installed libnuma on a NUMA and non NUMA machine.
> > >>> Compiled and ran following code on those machine and it could detect
> > >>> the numa availability. Could you add more details on the "error on
> > >>> platform supporting NUMA".
> > >>
> > >> I was saying that we do not need to detect NUMA.
> > >> If we are building DPDK for a NUMA architecture and libnuma is not
> > >> available, then it will be a problem that the user must catch.
> > >> The easiest way to catch it, is to fail on the include of numaif.h.
> > >
> > > libnuma is not really _architecture_ depended.
> > >
> > > Ilya Maximets patch disables NUMA support in common arm64 config.I
> > > think, It is not correct, We should not disable on any archs generic config.
> > >
> > > IMO, It should be enabled by default in common config and then we can
> > > detect the presence of numaif.h, if not available OR a target does not need it
> > > explicitly, proceed with disabling
> > > RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
> >
> > Detecting of headers is impossible until dpdk doesn't have dynamic build
> > configuration system like autotools, CMake or meson.
> > Right now we just can't do that.
>
> I agree. Unless if we do something like linux kernel does it below
> http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
>
> Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
> generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
> any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.
In this case, you can enable it in common_base and disable it only for
armv7 and dpaa2.
So, what do you think about this version?
Is it ready for merge or some additional changes needed?
Best regards, Ilya Maximets.
On 21.06.2017 13:08, Ilya Maximets wrote:
> Version 7:
> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>
> Version 6:
> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> returned. Enabled by default for x86, ppc and thunderx.
>
> Version 5:
> * Fixed shared build. (Automated build test will fail
> anyway because libnuma-devel not installed on build servers)
>
> Version 4:
> * Fixed work on systems without NUMA by adding check for NUMA
> support in kernel.
>
> Version 3:
> * Implemented hybrid schema for allocation.
> * Fixed not needed mempolicy change while remapping. (orig = 0)
> * Added patch to enable VHOST_NUMA by default.
>
> Version 2:
> * rebased (fuzz in Makefile)
>
> Ilya Maximets (2):
> mem: balanced allocation of hugepages
> config: enable vhost numa awareness by default
>
> config/common_base | 1 +
> config/common_linuxapp | 3 +
> config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
> config/defconfig_arm64-armv8a-linuxapp-gcc | 4 +
> config/defconfig_arm64-thunderx-linuxapp-gcc | 4 +
> lib/librte_eal/linuxapp/eal/Makefile | 3 +
> lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++-
> mk/rte.app.mk | 3 +
> 8 files changed, 123 insertions(+), 4 deletions(-)
>
-----Original Message-----
> Date: Mon, 26 Jun 2017 13:44:08 +0300
> From: Ilya Maximets <i.maximets@samsung.com>
> To: dev@dpdk.org, Sergio Gonzalez Monroy
> <sergio.gonzalez.monroy@intel.com>, Thomas Monjalon <thomas@monjalon.net>,
> Bruce Richardson <bruce.richardson@intel.com>
> CC: David Marchand <david.marchand@6wind.com>, Heetae Ahn
> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
> Pei <yulong.pei@intel.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Subject: Re: [PATCH v7 0/2] Balanced allocation of hugepages
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
> Thunderbird/45.8.0
>
> So, what do you think about this version?
> Is it ready for merge or some additional changes needed?
Looks like following comment is not addressed.
http://dpdk.org/ml/archives/dev/2017-June/068398.html
>
> Best regards, Ilya Maximets.
>
> On 21.06.2017 13:08, Ilya Maximets wrote:
> > Version 7:
> > * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
> >
> > Version 6:
> > * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> > returned. Enabled by default for x86, ppc and thunderx.
> >
> > Version 5:
> > * Fixed shared build. (Automated build test will fail
> > anyway because libnuma-devel not installed on build servers)
> >
> > Version 4:
> > * Fixed work on systems without NUMA by adding check for NUMA
> > support in kernel.
> >
> > Version 3:
> > * Implemented hybrid schema for allocation.
> > * Fixed not needed mempolicy change while remapping. (orig = 0)
> > * Added patch to enable VHOST_NUMA by default.
> >
> > Version 2:
> > * rebased (fuzz in Makefile)
> >
> > Ilya Maximets (2):
> > mem: balanced allocation of hugepages
> > config: enable vhost numa awareness by default
> >
> > config/common_base | 1 +
> > config/common_linuxapp | 3 +
> > config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
> > config/defconfig_arm64-armv8a-linuxapp-gcc | 4 +
> > config/defconfig_arm64-thunderx-linuxapp-gcc | 4 +
> > lib/librte_eal/linuxapp/eal/Makefile | 3 +
> > lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++-
> > mk/rte.app.mk | 3 +
> > 8 files changed, 123 insertions(+), 4 deletions(-)
> >
On 26/06/2017 11:44, Ilya Maximets wrote:
> So, what do you think about this version?
> Is it ready for merge or some additional changes needed?
I was just having another look at it and was wondering if we should
re-set the old policy instead of DEFAULT?
Also noticed that we probably should increase essential_memory by
hugepage_sz in case of SIGBUS? I think there is an issue if we have more
than one size.
Thanks,
Sergio
> Best regards, Ilya Maximets.
>
> On 21.06.2017 13:08, Ilya Maximets wrote:
>> Version 7:
>> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>>
>> Version 6:
>> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>> returned. Enabled by default for x86, ppc and thunderx.
>>
>> Version 5:
>> * Fixed shared build. (Automated build test will fail
>> anyway because libnuma-devel not installed on build servers)
>>
>> Version 4:
>> * Fixed work on systems without NUMA by adding check for NUMA
>> support in kernel.
>>
>> Version 3:
>> * Implemented hybrid schema for allocation.
>> * Fixed not needed mempolicy change while remapping. (orig = 0)
>> * Added patch to enable VHOST_NUMA by default.
>>
>> Version 2:
>> * rebased (fuzz in Makefile)
>>
>> Ilya Maximets (2):
>> mem: balanced allocation of hugepages
>> config: enable vhost numa awareness by default
>>
>> config/common_base | 1 +
>> config/common_linuxapp | 3 +
>> config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
>> config/defconfig_arm64-armv8a-linuxapp-gcc | 4 +
>> config/defconfig_arm64-thunderx-linuxapp-gcc | 4 +
>> lib/librte_eal/linuxapp/eal/Makefile | 3 +
>> lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++-
>> mk/rte.app.mk | 3 +
>> 8 files changed, 123 insertions(+), 4 deletions(-)
>>
On 26.06.2017 18:33, Sergio Gonzalez Monroy wrote:
> On 26/06/2017 11:44, Ilya Maximets wrote:
>> So, what do you think about this version?
>> Is it ready for merge or some additional changes needed?
>
> I was just having another look at it and was wondering if we should re-set the old policy instead of DEFAULT?
Yes. I tried to do that previously, but it requires some manipulations
get maximum nodemask size supported by kernel. So, I've implemented
this behaviour with help of libnuma which makes a lot of checks while
library initialisation (constructor). I'll send v8 with that soon.
> Also noticed that we probably should increase essential_memory by hugepage_sz in
> case of SIGBUS? I think there is an issue if we have more than one size.
Good catch. Also fixed in v8. Additionally I found that we need to restore
old mempolicy in case of any error. So I replaced all the 'return i' to
the out to proper termination point.
>
> Thanks,
> Sergio
>
>> Best regards, Ilya Maximets.
>>
>> On 21.06.2017 13:08, Ilya Maximets wrote:
>>> Version 7:
>>> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>>>
>>> Version 6:
>>> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>> returned. Enabled by default for x86, ppc and thunderx.
>>>
>>> Version 5:
>>> * Fixed shared build. (Automated build test will fail
>>> anyway because libnuma-devel not installed on build servers)
>>>
>>> Version 4:
>>> * Fixed work on systems without NUMA by adding check for NUMA
>>> support in kernel.
>>>
>>> Version 3:
>>> * Implemented hybrid schema for allocation.
>>> * Fixed not needed mempolicy change while remapping. (orig = 0)
>>> * Added patch to enable VHOST_NUMA by default.
>>>
>>> Version 2:
>>> * rebased (fuzz in Makefile)
>>>
>>> Ilya Maximets (2):
>>> mem: balanced allocation of hugepages
>>> config: enable vhost numa awareness by default
>>>
>>> config/common_base | 1 +
>>> config/common_linuxapp | 3 +
>>> config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
>>> config/defconfig_arm64-armv8a-linuxapp-gcc | 4 +
>>> config/defconfig_arm64-thunderx-linuxapp-gcc | 4 +
>>> lib/librte_eal/linuxapp/eal/Makefile | 3 +
>>> lib/librte_eal/linuxapp/eal/eal_memory.c | 105 ++++++++++++++++++++++++++-
>>> mk/rte.app.mk | 3 +
>>> 8 files changed, 123 insertions(+), 4 deletions(-)
>>>
>
>
>
>
Version 8:
* helper functions from libnuma used to set mempolicy and
work with cpu mask.
* Function now restores previous mempolicy instead of MPOL_DEFAULT.
* Fixed essential_memory on SIGBUS.
* Fixed restoring of mempolicy in case of errors (goto out).
* Enabled by default for all linuxapp except armv7 and dpaa2.
Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
returned. Enabled by default for x86, ppc and thunderx.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 1 +
config/common_linuxapp | 2 +
config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 4 +
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 117 ++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
7 files changed, 126 insertions(+), 8 deletions(-)
On 6/21/2017 4:52 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Wed, 21 Jun 2017 13:36:58 +0300
>> From: Ilya Maximets <i.maximets@samsung.com>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Thomas Monjalon
>> <thomas@monjalon.net>
>> CC: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
>> Agrawal <hemant.agrawal@nxp.com>, dev@dpdk.org, Bruce Richardson
>> <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>,
>> Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>,
>> Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
>> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>
>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
>> Thunderbird/45.8.0
>>
>> On 21.06.2017 13:29, Jerin Jacob wrote:
>>> -----Original Message-----
>>>> Date: Wed, 21 Jun 2017 11:58:12 +0200
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
>>>> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
>>>> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
>>>> Marchand <david.marchand@6wind.com>, Heetae Ahn
>>>> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
>>>> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
>>>> Pei <yulong.pei@intel.com>
>>>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>>>>
>>>> 21/06/2017 11:27, Jerin Jacob:
>>>>> -----Original Message-----
>>>>>> Date: Wed, 21 Jun 2017 10:49:14 +0200
>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>>>>>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
>>>>>> Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.com>,
>>>>>> dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David
>>>>>> Marchand <david.marchand@6wind.com>, Heetae Ahn
>>>>>> <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng
>>>>>> Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong
>>>>>> Pei <yulong.pei@intel.com>
>>>>>> Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
>>>>>>
>>>>>> 21/06/2017 10:41, Jerin Jacob:
>>>>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA.
>>>>>>>>>
>>>>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
>>>>>>>>>
>>>>>>>>
>>>>>>>> I did find that link too, last modified 4 years ago.
>>>>>>>> Despite that, I could not find any ARM references in libnuma sources, but
>>>>>>>> Jerin proved that there is support for it.
>>>>>>>>
>>>>>>>> http://oss.sgi.com/projects/libnuma/
>>>>>>>> https://github.com/numactl/numactl
>>>>>>>
>>>>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
>>>>>>> I guess we are talking about build time time dependency with libnuma here.
>>>>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
>>>>>>> libnuma if it is present in rootfs. Just that at runtime, it will return
>>>>>>> NUMA support not available. Correct?
>>>>>>>
>>>>>>> How hard is detect the presence of "numaif.h" if existing build system does not
>>>>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>> if build environment has "numaif.h".
>>>>>>>
>>>>>>> Some example in linux kernel build system:
>>>>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
>>>>>>
>>>>>> I think we should not try to detect numaif.h, because it should be
>>>>>> an error on platform supporting NUMA.
>>>>>
>>>>> I have installed libnuma on a NUMA and non NUMA machine.
>>>>> Compiled and ran following code on those machine and it could detect
>>>>> the numa availability. Could you add more details on the "error on
>>>>> platform supporting NUMA".
>>>>
>>>> I was saying that we do not need to detect NUMA.
>>>> If we are building DPDK for a NUMA architecture and libnuma is not
>>>> available, then it will be a problem that the user must catch.
>>>> The easiest way to catch it, is to fail on the include of numaif.h.
>>>
>>> libnuma is not really _architecture_ depended.
>>>
>>> Ilya Maximets patch disables NUMA support in common arm64 config.I
>>> think, It is not correct, We should not disable on any archs generic config.
>>>
>>> IMO, It should be enabled by default in common config and then we can
>>> detect the presence of numaif.h, if not available OR a target does not need it
>>> explicitly, proceed with disabling
>>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
>>
>> Detecting of headers is impossible until dpdk doesn't have dynamic build
>> configuration system like autotools, CMake or meson.
>> Right now we just can't do that.
>
> I agree. Unless if we do something like linux kernel does it below
> http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
>
> Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
> generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
> any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.
No, this is not acceptable. it should not be enabled in generic arm64.
It can be enabled in specific ARM platforms, which support NUMA
architecture.
We also use generic ARM code on various of our platform when running
with non-dpaa and/or virtio-net. So enabling it will break all those
platforms.
>
>>
>>> No strong opinion on "failing the build" vs "printing a warning" in the
>>> absence of numaif.h
>
27/06/2017 11:13, Hemant Agrawal:
> On 6/21/2017 4:52 PM, Jerin Jacob wrote:
> > From: Ilya Maximets <i.maximets@samsung.com>
> >>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>> 21/06/2017 10:41, Jerin Jacob:
> >>>>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA.
> >>>>>>>>>
> >>>>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I did find that link too, last modified 4 years ago.
> >>>>>>>> Despite that, I could not find any ARM references in libnuma sources, but
> >>>>>>>> Jerin proved that there is support for it.
> >>>>>>>>
> >>>>>>>> http://oss.sgi.com/projects/libnuma/
> >>>>>>>> https://github.com/numactl/numactl
> >>>>>>>
> >>>>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
> >>>>>>> I guess we are talking about build time time dependency with libnuma here.
> >>>>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
> >>>>>>> libnuma if it is present in rootfs. Just that at runtime, it will return
> >>>>>>> NUMA support not available. Correct?
> >>>>>>>
> >>>>>>> How hard is detect the presence of "numaif.h" if existing build system does not
> >>>>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> >>>>>>> if build environment has "numaif.h".
> >>>>>>>
> >>>>>>> Some example in linux kernel build system:
> >>>>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
> >>>>>>
> >>>>>> I think we should not try to detect numaif.h, because it should be
> >>>>>> an error on platform supporting NUMA.
> >>>>>
> >>>>> I have installed libnuma on a NUMA and non NUMA machine.
> >>>>> Compiled and ran following code on those machine and it could detect
> >>>>> the numa availability. Could you add more details on the "error on
> >>>>> platform supporting NUMA".
> >>>>
> >>>> I was saying that we do not need to detect NUMA.
> >>>> If we are building DPDK for a NUMA architecture and libnuma is not
> >>>> available, then it will be a problem that the user must catch.
> >>>> The easiest way to catch it, is to fail on the include of numaif.h.
> >>>
> >>> libnuma is not really _architecture_ depended.
> >>>
> >>> Ilya Maximets patch disables NUMA support in common arm64 config.I
> >>> think, It is not correct, We should not disable on any archs generic config.
> >>>
> >>> IMO, It should be enabled by default in common config and then we can
> >>> detect the presence of numaif.h, if not available OR a target does not need it
> >>> explicitly, proceed with disabling
> >>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
> >>
> >> Detecting of headers is impossible until dpdk doesn't have dynamic build
> >> configuration system like autotools, CMake or meson.
> >> Right now we just can't do that.
> >
> > I agree. Unless if we do something like linux kernel does it below
> > http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
> >
> > Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
> > generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
> > any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.
>
> No, this is not acceptable. it should not be enabled in generic arm64.
> It can be enabled in specific ARM platforms, which support NUMA
> architecture.
> We also use generic ARM code on various of our platform when running
> with non-dpaa and/or virtio-net. So enabling it will break all those
> platforms.
Which platforms?
It is your non-upstreamed code. You have to deal with it.
You should disable NUMA in the config of these platforms.
On 6/27/2017 2:56 PM, Thomas Monjalon wrote:
> 27/06/2017 11:13, Hemant Agrawal:
>> On 6/21/2017 4:52 PM, Jerin Jacob wrote:
>>> From: Ilya Maximets <i.maximets@samsung.com>
>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>> 21/06/2017 10:41, Jerin Jacob:
>>>>>>>>>>> 1. There are many machines (arm/ppc), which do not support NUMA.
>>>>>>>>>>>
>>>>>>>>>>> https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I did find that link too, last modified 4 years ago.
>>>>>>>>>> Despite that, I could not find any ARM references in libnuma sources, but
>>>>>>>>>> Jerin proved that there is support for it.
>>>>>>>>>>
>>>>>>>>>> http://oss.sgi.com/projects/libnuma/
>>>>>>>>>> https://github.com/numactl/numactl
>>>>>>>>>
>>>>>>>>> Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
>>>>>>>>> I guess we are talking about build time time dependency with libnuma here.
>>>>>>>>> Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
>>>>>>>>> libnuma if it is present in rootfs. Just that at runtime, it will return
>>>>>>>>> NUMA support not available. Correct?
>>>>>>>>>
>>>>>>>>> How hard is detect the presence of "numaif.h" if existing build system does not
>>>>>>>>> support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>>>>>>>>> if build environment has "numaif.h".
>>>>>>>>>
>>>>>>>>> Some example in linux kernel build system:
>>>>>>>>> http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh
>>>>>>>>
>>>>>>>> I think we should not try to detect numaif.h, because it should be
>>>>>>>> an error on platform supporting NUMA.
>>>>>>>
>>>>>>> I have installed libnuma on a NUMA and non NUMA machine.
>>>>>>> Compiled and ran following code on those machine and it could detect
>>>>>>> the numa availability. Could you add more details on the "error on
>>>>>>> platform supporting NUMA".
>>>>>>
>>>>>> I was saying that we do not need to detect NUMA.
>>>>>> If we are building DPDK for a NUMA architecture and libnuma is not
>>>>>> available, then it will be a problem that the user must catch.
>>>>>> The easiest way to catch it, is to fail on the include of numaif.h.
>>>>>
>>>>> libnuma is not really _architecture_ depended.
>>>>>
>>>>> Ilya Maximets patch disables NUMA support in common arm64 config.I
>>>>> think, It is not correct, We should not disable on any archs generic config.
>>>>>
>>>>> IMO, It should be enabled by default in common config and then we can
>>>>> detect the presence of numaif.h, if not available OR a target does not need it
>>>>> explicitly, proceed with disabling
>>>>> RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.
>>>>
>>>> Detecting of headers is impossible until dpdk doesn't have dynamic build
>>>> configuration system like autotools, CMake or meson.
>>>> Right now we just can't do that.
>>>
>>> I agree. Unless if we do something like linux kernel does it below
>>> http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
>>>
>>> Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
>>> generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
>>> any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.
>>
>> No, this is not acceptable. it should not be enabled in generic arm64.
>> It can be enabled in specific ARM platforms, which support NUMA
>> architecture.
>> We also use generic ARM code on various of our platform when running
>> with non-dpaa and/or virtio-net. So enabling it will break all those
>> platforms.
>
> Which platforms?
> It is your non-upstreamed code. You have to deal with it.
> You should disable NUMA in the config of these platforms.
>
>
See my reply in other thread. This is nothing to do with up-streaming.
All NXP - low end non-dpaa platforms, which don't have any platform
specific code, we use "arm64-armv8a-linuxapp-gcc" as the build config.
There is no need to create special configs for these platforms.
Creating a "non-NUMA" generic config will be an over-kill.
Version 9:
* Removed DPDK_DEP_NUMA from test-build.sh . Not needed
anymore.
* Fixed out of bound write to essential_memory in case
where socket-mem not specified and SIGBUS occured.
Version 8:
* helper functions from libnuma used to set mempolicy and
work with cpu mask.
* Function now restores previous mempolicy instead of MPOL_DEFAULT.
* Fixed essential_memory on SIGBUS.
* Fixed restoring of mempolicy in case of errors (goto out).
* Enabled by default for all linuxapp except armv7 and dpaa2.
Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
returned. Enabled by default for x86, ppc and thunderx.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 1 +
config/common_linuxapp | 2 +
config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 4 +
devtools/test-build.sh | 4 -
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 120 ++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
8 files changed, 129 insertions(+), 12 deletions(-)
Version 10:
* Fixed typo in DPAA2 config.
Version 9:
* Removed DPDK_DEP_NUMA from test-build.sh . Not needed
anymore.
* Fixed out of bound write to essential_memory in case
where socket-mem not specified and SIGBUS occured.
Version 8:
* helper functions from libnuma used to set mempolicy and
work with cpu mask.
* Function now restores previous mempolicy instead of MPOL_DEFAULT.
* Fixed essential_memory on SIGBUS.
* Fixed restoring of mempolicy in case of errors (goto out).
* Enabled by default for all linuxapp except armv7 and dpaa2.
Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
returned. Enabled by default for x86, ppc and thunderx.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 1 +
config/common_linuxapp | 2 +
config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 4 +
devtools/test-build.sh | 4 -
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 120 ++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
8 files changed, 129 insertions(+), 12 deletions(-)
-----Original Message-----
> Date: Thu, 29 Jun 2017 08:59:18 +0300
> From: Ilya Maximets <i.maximets@samsung.com>
> To: dev@dpdk.org, David Marchand <david.marchand@6wind.com>, Sergio
> Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Thomas Monjalon
> <thomas@monjalon.net>
> CC: Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu
> <yliu@fridaylinux.org>, Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>, Bruce
> Richardson <bruce.richardson@intel.com>, Jerin Jacob
> <jerin.jacob@caviumnetworks.com>, Hemant Agrawal <hemant.agrawal@nxp.com>,
> Ilya Maximets <i.maximets@samsung.com>
> Subject: [PATCH v10 0/2] Balanced allocation of hugepages
> X-Mailer: git-send-email 2.7.4
>
> Version 10:
> * Fixed typo in DPAA2 config.
>
> Version 9:
> * Removed DPDK_DEP_NUMA from test-build.sh . Not needed
> anymore.
> * Fixed out of bound write to essential_memory in case
> where socket-mem not specified and SIGBUS occured.
>
> Version 8:
> * helper functions from libnuma used to set mempolicy and
> work with cpu mask.
> * Function now restores previous mempolicy instead of MPOL_DEFAULT.
> * Fixed essential_memory on SIGBUS.
> * Fixed restoring of mempolicy in case of errors (goto out).
> * Enabled by default for all linuxapp except armv7 and dpaa2.
>
> Version 7:
> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>
> Version 6:
> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> returned. Enabled by default for x86, ppc and thunderx.
>
> Version 5:
> * Fixed shared build. (Automated build test will fail
> anyway because libnuma-devel not installed on build servers)
>
> Version 4:
> * Fixed work on systems without NUMA by adding check for NUMA
> support in kernel.
>
> Version 3:
> * Implemented hybrid schema for allocation.
> * Fixed not needed mempolicy change while remapping. (orig = 0)
> * Added patch to enable VHOST_NUMA by default.
>
> Version 2:
> * rebased (fuzz in Makefile)
>
> Ilya Maximets (2):
> mem: balanced allocation of hugepages
> config: enable vhost numa awareness by default
Series-Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Tested on a arm64 NUMA machine.
Tested-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
So, are we ready for merging this now?
Thomas?
Best regards, Ilya Maximets.
On 29.06.2017 09:29, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Thu, 29 Jun 2017 08:59:18 +0300
>> From: Ilya Maximets <i.maximets@samsung.com>
>> To: dev@dpdk.org, David Marchand <david.marchand@6wind.com>, Sergio
>> Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Thomas Monjalon
>> <thomas@monjalon.net>
>> CC: Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu
>> <yliu@fridaylinux.org>, Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman
>> <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com>, Bruce
>> Richardson <bruce.richardson@intel.com>, Jerin Jacob
>> <jerin.jacob@caviumnetworks.com>, Hemant Agrawal <hemant.agrawal@nxp.com>,
>> Ilya Maximets <i.maximets@samsung.com>
>> Subject: [PATCH v10 0/2] Balanced allocation of hugepages
>> X-Mailer: git-send-email 2.7.4
>>
>> Version 10:
>> * Fixed typo in DPAA2 config.
>>
>> Version 9:
>> * Removed DPDK_DEP_NUMA from test-build.sh . Not needed
>> anymore.
>> * Fixed out of bound write to essential_memory in case
>> where socket-mem not specified and SIGBUS occured.
>>
>> Version 8:
>> * helper functions from libnuma used to set mempolicy and
>> work with cpu mask.
>> * Function now restores previous mempolicy instead of MPOL_DEFAULT.
>> * Fixed essential_memory on SIGBUS.
>> * Fixed restoring of mempolicy in case of errors (goto out).
>> * Enabled by default for all linuxapp except armv7 and dpaa2.
>>
>> Version 7:
>> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>>
>> Version 6:
>> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
>> returned. Enabled by default for x86, ppc and thunderx.
>>
>> Version 5:
>> * Fixed shared build. (Automated build test will fail
>> anyway because libnuma-devel not installed on build servers)
>>
>> Version 4:
>> * Fixed work on systems without NUMA by adding check for NUMA
>> support in kernel.
>>
>> Version 3:
>> * Implemented hybrid schema for allocation.
>> * Fixed not needed mempolicy change while remapping. (orig = 0)
>> * Added patch to enable VHOST_NUMA by default.
>>
>> Version 2:
>> * rebased (fuzz in Makefile)
>>
>> Ilya Maximets (2):
>> mem: balanced allocation of hugepages
>> config: enable vhost numa awareness by default
>
> Series-Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Tested on a arm64 NUMA machine.
> Tested-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Version 11:
* Fixed test-build.sh for missing libnuma dependency
Version 10:
* Fixed typo in DPAA2 config.
Version 9:
* Removed DPDK_DEP_NUMA from test-build.sh . Not needed
anymore.
* Fixed out of bound write to essential_memory in case
where socket-mem not specified and SIGBUS occured.
Version 8:
* helper functions from libnuma used to set mempolicy and
work with cpu mask.
* Function now restores previous mempolicy instead of MPOL_DEFAULT.
* Fixed essential_memory on SIGBUS.
* Fixed restoring of mempolicy in case of errors (goto out).
* Enabled by default for all linuxapp except armv7 and dpaa2.
Version 7:
* RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
Version 6:
* Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
returned. Enabled by default for x86, ppc and thunderx.
Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
Version 2:
* rebased (fuzz in Makefile)
Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost NUMA awareness by default
config/common_base | 1 +
config/common_linuxapp | 2 +
config/defconfig_arm-armv7a-linuxapp-gcc | 4 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 4 +
devtools/test-build.sh | 6 +-
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 120 ++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
8 files changed, 132 insertions(+), 11 deletions(-)
30/06/2017 18:12, Thomas Monjalon:
> Version 11:
> * Fixed test-build.sh for missing libnuma dependency
>
> Version 10:
> * Fixed typo in DPAA2 config.
>
> Version 9:
> * Removed DPDK_DEP_NUMA from test-build.sh . Not needed
> anymore.
> * Fixed out of bound write to essential_memory in case
> where socket-mem not specified and SIGBUS occured.
>
> Version 8:
> * helper functions from libnuma used to set mempolicy and
> work with cpu mask.
> * Function now restores previous mempolicy instead of MPOL_DEFAULT.
> * Fixed essential_memory on SIGBUS.
> * Fixed restoring of mempolicy in case of errors (goto out).
> * Enabled by default for all linuxapp except armv7 and dpaa2.
>
> Version 7:
> * RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES --> RTE_EAL_NUMA_AWARE_HUGEPAGES
>
> Version 6:
> * Configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> returned. Enabled by default for x86, ppc and thunderx.
>
> Version 5:
> * Fixed shared build. (Automated build test will fail
> anyway because libnuma-devel not installed on build servers)
>
> Version 4:
> * Fixed work on systems without NUMA by adding check for NUMA
> support in kernel.
>
> Version 3:
> * Implemented hybrid schema for allocation.
> * Fixed not needed mempolicy change while remapping. (orig = 0)
> * Added patch to enable VHOST_NUMA by default.
>
> Version 2:
> * rebased (fuzz in Makefile)
>
> Ilya Maximets (2):
> mem: balanced allocation of hugepages
> config: enable vhost NUMA awareness by default
Applied this version, thanks for getting an agreement after long discussions :)
@@ -102,6 +102,7 @@ CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
CONFIG_RTE_EAL_IGB_UIO=n
CONFIG_RTE_EAL_VFIO=n
CONFIG_RTE_MALLOC_DEBUG=n
+CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n
# Default driver path (or "" to disable)
CONFIG_RTE_EAL_PMD_PATH=""
@@ -37,4 +37,8 @@ DEPDIRS-linuxapp := common
DIRS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += bsdapp
DEPDIRS-bsdapp := common
+ifeq ($(CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES),y)
+LDLIBS += -lnuma
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
@@ -83,6 +83,9 @@
#include <sys/time.h>
#include <signal.h>
#include <setjmp.h>
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+#include <numaif.h>
+#endif
#include <rte_log.h>
#include <rte_memory.h>
@@ -377,6 +380,21 @@ static int huge_wrap_sigsetjmp(void)
return sigsetjmp(huge_jmpenv, 1);
}
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+#ifndef ULONG_SIZE
+#define ULONG_SIZE sizeof(unsigned long)
+#endif
+#ifndef ULONG_BITS
+#define ULONG_BITS (ULONG_SIZE * CHAR_BIT)
+#endif
+#ifndef DIV_ROUND_UP
+#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
+#endif
+#ifndef BITS_TO_LONGS
+#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, ULONG_SIZE)
+#endif
+#endif
+
/*
* Mmap all hugepages of hugepage table: it first open a file in
* hugetlbfs, then mmap() hugepage_sz data in it. If orig is set, the
@@ -393,10 +411,48 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
void *virtaddr;
void *vma_addr = NULL;
size_t vma_len = 0;
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ unsigned long nodemask[BITS_TO_LONGS(RTE_MAX_NUMA_NODES)] = {0UL};
+ unsigned long maxnode = 0;
+ int node_id = -1;
+
+ for (i = 0; i < RTE_MAX_NUMA_NODES; i++)
+ if (internal_config.socket_mem[i])
+ maxnode = i + 1;
+#endif
for (i = 0; i < hpi->num_pages[0]; i++) {
uint64_t hugepage_sz = hpi->hugepage_sz;
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ if (maxnode) {
+ node_id = (node_id + 1) % RTE_MAX_NUMA_NODES;
+ while (!internal_config.socket_mem[node_id])
+ node_id = (node_id + 1) % RTE_MAX_NUMA_NODES;
+
+ nodemask[node_id / ULONG_BITS] =
+ 1UL << (node_id % ULONG_BITS);
+
+ RTE_LOG(DEBUG, EAL,
+ "Setting policy MPOL_PREFERRED for socket %d\n",
+ node_id);
+ /*
+ * Due to old linux kernel bug (feature?) we have to
+ * increase maxnode by 1. It will be unconditionally
+ * decreased back to normal value inside the syscall
+ * handler.
+ */
+ if (set_mempolicy(MPOL_PREFERRED,
+ nodemask, maxnode + 1) < 0) {
+ RTE_LOG(ERR, EAL,
+ "Failed to set policy MPOL_PREFERRED: "
+ "%s\n", strerror(errno));
+ return i;
+ }
+
+ nodemask[node_id / ULONG_BITS] = 0UL;
+ }
+#endif
if (orig) {
hugepg_tbl[i].file_id = i;
hugepg_tbl[i].size = hugepage_sz;
@@ -507,6 +563,10 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
vma_len -= hugepage_sz;
}
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ if (maxnode && set_mempolicy(MPOL_DEFAULT, NULL, 0) < 0)
+ RTE_LOG(ERR, EAL, "Failed to set mempolicy MPOL_DEFAULT\n");
+#endif
return i;
}
@@ -591,6 +651,11 @@ find_numasocket(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
if (hugepg_tbl[i].orig_va == va) {
hugepg_tbl[i].socket_id = socket_id;
hp_count++;
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ RTE_LOG(DEBUG, EAL,
+ "Hugepage %s is on socket %d\n",
+ hugepg_tbl[i].filepath, socket_id);
+#endif
}
}
}
@@ -173,6 +173,9 @@ ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
# The static libraries do not know their dependencies.
# So linking with static library requires explicit dependencies.
_LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lrt
+ifeq ($(CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES),y)
+_LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lnuma
+endif
_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm
_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt
_LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lm