From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Maximets Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Wed, 21 Jun 2017 13:36:58 +0300 Message-ID: <4786d356-963d-cb1e-72cc-da154265a1d3@samsung.com> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <3795576.X6Zydzo19D@xps> <20170621092744.GA26030@jerin> <2845661.r9ChRO7rgB@xps> <20170621102939.GA27670@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Sergio Gonzalez Monroy , Hemant Agrawal , dev@dpdk.org, Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Jerin Jacob , Thomas Monjalon Return-path: Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by dpdk.org (Postfix) with ESMTP id 131445583 for ; Wed, 21 Jun 2017 12:37:04 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0ORW00CBJ85QUM60@mailout4.w1.samsung.com> for dev@dpdk.org; Wed, 21 Jun 2017 11:37:02 +0100 (BST) In-reply-to: <20170621102939.GA27670@jerin> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 21.06.2017 13:29, Jerin Jacob wrote: > -----Original Message----- >> Date: Wed, 21 Jun 2017 11:58:12 +0200 >> From: Thomas Monjalon >> To: Jerin Jacob >> Cc: Sergio Gonzalez Monroy , Hemant >> Agrawal , Ilya Maximets , >> dev@dpdk.org, Bruce Richardson , David >> Marchand , Heetae Ahn >> , Yuanhan Liu , Jianfeng >> Tan , Neil Horman , Yulong >> Pei >> 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 >>>> To: Jerin Jacob >>>> Cc: Sergio Gonzalez Monroy , Hemant >>>> Agrawal , Ilya Maximets , >>>> dev@dpdk.org, Bruce Richardson , David >>>> Marchand , Heetae Ahn >>>> , Yuanhan Liu , Jianfeng >>>> Tan , Neil Horman , Yulong >>>> Pei >>>> 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