From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 96A0821321; Tue, 27 Jun 2017 05:26:29 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 27 Jun 2017 05:26:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=NjUlT3Ad1JH4ueb yELALfArqbOfoVVuYFgNXn3oAnW4=; b=mkQnCJGOaT6cLg4pb7d3/oBdY00TtQe +5SdOU3iMYlYpEe53Y4fTv+MeWWcO7l7ZCSH+QoEcqSQtSfFKnltLdVPOlrhwss6 ESKOQt/yrITc97mepLcxWxb4HIvJ7Htg+sBGrEFBDW7lTzx//c4GPEhcYgMgsAXh D7zSvX+GhweA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=NjUlT3Ad1JH4uebyELALfArqbOfoVVuYFgNXn3oAnW4=; b=IpwXn4sy mOjrE74cbwIxMt1thN67A6GJqekURkMZP8CDAFRA4rtr0NJ6XaVpqNGSuoZSYSpV V4fMD0poYAgMZwk47hoJLhP18CMsHiAPkg1cxJZDHJlCQlRLaM5uGjfUuqWfiXTo ERqp1jvS/ACR9pGvUV/2sf1E+N8/YulkJx73gjg8G47QF3HNFfE+F0P1G1bqAgbO /ZIqB/LlJz2nidgjf0h2qpIvBShGpt2d1DAzpsgnFycufMBbPEo5PrtnLR13oUYv Wt7Z3URorNZ62NQGKKfV9fG4y+0KWdFwiQoyJn21Nj2BoQSvtYO8EYqjgtNJYhz1 sMsuYi7IQVhkcQ== X-ME-Sender: X-Sasl-enc: thE6bMcW4TDVMQn0zQSDpOSoPKXrn/vLICcLyrQaZk1n 1498555589 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A9DF2458E; Tue, 27 Jun 2017 05:26:29 -0400 (EDT) From: Thomas Monjalon To: Hemant Agrawal 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 Date: Tue, 27 Jun 2017 11:26:28 +0200 Message-ID: <1754978.DhjFZ6qBWF@xps> In-Reply-To: <7586fff1-32c7-7468-2cd1-f1406b27974d@nxp.com> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 09:26:30 -0000 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.