27/06/2017 11:13, Hemant Agrawal: > On 6/21/2017 4:52 PM, Jerin Jacob wrote: > > From: Ilya Maximets <i.maxim...@samsung.com> > >>> From: Thomas Monjalon <tho...@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.
