From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Wed, 21 Jun 2017 16:52:43 +0530 Message-ID: <20170621112242.GA31460@jerin> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <3795576.X6Zydzo19D@xps> <20170621092744.GA26030@jerin> <2845661.r9ChRO7rgB@xps> <20170621102939.GA27670@jerin> <4786d356-963d-cb1e-72cc-da154265a1d3@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Thomas Monjalon , Sergio Gonzalez Monroy , Hemant Agrawal , dev@dpdk.org, Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Ilya Maximets Return-path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0050.outbound.protection.outlook.com [104.47.37.50]) by dpdk.org (Postfix) with ESMTP id D9EAF58EC for ; Wed, 21 Jun 2017 13:23:10 +0200 (CEST) Content-Disposition: inline In-Reply-To: <4786d356-963d-cb1e-72cc-da154265a1d3@samsung.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" -----Original Message----- > Date: Wed, 21 Jun 2017 13:36:58 +0300 > From: Ilya Maximets > To: Jerin Jacob , Thomas Monjalon > > CC: Sergio Gonzalez Monroy , Hemant > Agrawal , 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 > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 > Thunderbird/45.8.0 > > 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. 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 strong opinion on "failing the build" vs "printing a warning" in the > > absence of numaif.h