On 21.06.2017 13:29, Jerin Jacob wrote: > -----Original Message----- >> Date: Wed, 21 Jun 2017 11:58:12 +0200 >> From: Thomas Monjalon <[email protected]> >> To: Jerin Jacob <[email protected]> >> Cc: Sergio Gonzalez Monroy <[email protected]>, Hemant >> Agrawal <[email protected]>, Ilya Maximets <[email protected]>, >> [email protected], Bruce Richardson <[email protected]>, David >> Marchand <[email protected]>, Heetae Ahn >> <[email protected]>, Yuanhan Liu <[email protected]>, Jianfeng >> Tan <[email protected]>, Neil Horman <[email protected]>, Yulong >> Pei <[email protected]> >> 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 <[email protected]> >>>> To: Jerin Jacob <[email protected]> >>>> Cc: Sergio Gonzalez Monroy <[email protected]>, Hemant >>>> Agrawal <[email protected]>, Ilya Maximets <[email protected]>, >>>> [email protected], Bruce Richardson <[email protected]>, David >>>> Marchand <[email protected]>, Heetae Ahn >>>> <[email protected]>, Yuanhan Liu <[email protected]>, Jianfeng >>>> Tan <[email protected]>, Neil Horman <[email protected]>, Yulong >>>> Pei <[email protected]> >>>> 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
