[dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages

Ilya Maximets i.maximets at samsung.com
Wed Jun 21 12:36:58 CEST 2017


On 21.06.2017 13:29, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Wed, 21 Jun 2017 11:58:12 +0200
>> From: Thomas Monjalon <thomas at monjalon.net>
>> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy at intel.com>, Hemant
>>  Agrawal <hemant.agrawal at nxp.com>, Ilya Maximets <i.maximets at samsung.com>,
>>  dev at dpdk.org, Bruce Richardson <bruce.richardson at intel.com>, David
>>  Marchand <david.marchand at 6wind.com>, Heetae Ahn
>>  <heetae82.ahn at samsung.com>, Yuanhan Liu <yliu at fridaylinux.org>, Jianfeng
>>  Tan <jianfeng.tan at intel.com>, Neil Horman <nhorman at tuxdriver.com>, Yulong
>>  Pei <yulong.pei at 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 at monjalon.net>
>>>> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>>>> Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy at intel.com>, Hemant
>>>>  Agrawal <hemant.agrawal at nxp.com>, Ilya Maximets <i.maximets at samsung.com>,
>>>>  dev at dpdk.org, Bruce Richardson <bruce.richardson at intel.com>, David
>>>>  Marchand <david.marchand at 6wind.com>, Heetae Ahn
>>>>  <heetae82.ahn at samsung.com>, Yuanhan Liu <yliu at fridaylinux.org>, Jianfeng
>>>>  Tan <jianfeng.tan at intel.com>, Neil Horman <nhorman at tuxdriver.com>, Yulong
>>>>  Pei <yulong.pei at 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


More information about the dev mailing list