From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hemant Agrawal Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Tue, 27 Jun 2017 15:18:14 +0530 Message-ID: <6f07b0aa-d677-5974-5481-6c988a7b2969@nxp.com> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <20170621112242.GA31460@jerin> <7586fff1-32c7-7468-2cd1-f1406b27974d@nxp.com> <1754978.DhjFZ6qBWF@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Jerin Jacob , Ilya Maximets , Sergio Gonzalez Monroy , , Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Thomas Monjalon Return-path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0068.outbound.protection.outlook.com [104.47.33.68]) by dpdk.org (Postfix) with ESMTP id ACDA7374 for ; Tue, 27 Jun 2017 11:48:29 +0200 (CEST) In-Reply-To: <1754978.DhjFZ6qBWF@xps> 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 6/27/2017 2:56 PM, Thomas Monjalon wrote: > 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. > > See my reply in other thread. This is nothing to do with up-streaming. All NXP - low end non-dpaa platforms, which don't have any platform specific code, we use "arm64-armv8a-linuxapp-gcc" as the build config. There is no need to create special configs for these platforms. Creating a "non-NUMA" generic config will be an over-kill.