Re: [PATCH v5 0/2] Balanced allocation of hugepages

[Thomas Monjalon <thomas@monjalon.net>]

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.