From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Tue, 27 Jun 2017 11:26:28 +0200 Message-ID: <1754978.DhjFZ6qBWF@xps> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <20170621112242.GA31460@jerin> <7586fff1-32c7-7468-2cd1-f1406b27974d@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Jerin Jacob , Ilya Maximets , Sergio Gonzalez Monroy , dev@dpdk.org, Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Hemant Agrawal Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id EE023374 for ; Tue, 27 Jun 2017 11:26:29 +0200 (CEST) In-Reply-To: <7586fff1-32c7-7468-2cd1-f1406b27974d@nxp.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 27/06/2017 11:13, Hemant Agrawal: > On 6/21/2017 4:52 PM, Jerin Jacob wrote: > > From: Ilya Maximets > >>> From: Thomas Monjalon > >>>>>> 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.