From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 924CE4BE1 for <dev@dpdk.org>; Wed, 21 Jun 2017 13:29:58 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0068020C4C; Wed, 21 Jun 2017 07:29:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 21 Jun 2017 07:29:58 -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=nH6OxCQQf6U0mVe vfmfVD/rRLOQhya7UglIiitOFTbo=; b=U9Wbg48k96XLZBaZhhsrZ86Y7mtwy5V pUA6M12OzzPHfs7gN942DlEaQU4DnHrvOp9RDHkcVo14OHxV8v4Q92r6PyCC5Tfr jJP8naJJ82QOKmnieoazALrV98TH2avPgyhEIg35AT1wjzxI+6SWdGUcQKAhn2y/ MrTWDu32lgdk= 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=nH6OxCQQf6U0mVevfmfVD/rRLOQhya7UglIiitOFTbo=; b=bfeg5X/Q /oPKLuRw+AXwdMlVRNJF+nR3SGORQiV/OUT5mSvEGtVmBiDz9BgeCkXHR2hFBcTt vvLCifM16tEsaNKHeQ6kaOQW3NxssXkGcvTvQFt64+15HkiW61MQkx6CsL33wkh8 pwUDFKOa14B0IG7hfX+VC5Na7nrYR+l2GShy1KfPnR4xpV+TLDpMK+7BKPZ+YKOt puMR3wwwAZhrVyMOY63Vb6ofn2mMxJwUl1K/pAAy9wdGsFEcNBRMZKybMAN+MO0t iTmzPL1nc31pT9gH7oSqoknH9b0jfmzKXHxgxsa6UXTCxx/I1BOE9ZLe4A1zbkYM dO8crS0UDS/qqQ== X-ME-Sender: <xms:tVhKWSo_RuW_PFzdTXAllTVo0fRCGDw3diYd7ctJ6COcl8n8fywHcg> X-Sasl-enc: Sbk3QKlpokf/RXJSsF2wfIUYUU9K2dSt4EY/vmGCGoxj 1498044597 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B227240AF; Wed, 21 Jun 2017 07:29:57 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Ilya Maximets <i.maximets@samsung.com> Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, David Marchand <david.marchand@6wind.com>, Heetae Ahn <heetae82.ahn@samsung.com>, Yuanhan Liu <yliu@fridaylinux.org>, Jianfeng Tan <jianfeng.tan@intel.com>, Neil Horman <nhorman@tuxdriver.com>, Yulong Pei <yulong.pei@intel.com> Date: Wed, 21 Jun 2017 13:29:31 +0200 Message-ID: <8917631.90xRooPCoe@xps> In-Reply-To: <20170621112242.GA31460@jerin> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <4786d356-963d-cb1e-72cc-da154265a1d3@samsung.com> <20170621112242.GA31460@jerin> 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 21 Jun 2017 11:29:58 -0000 21/06/2017 13:22, Jerin Jacob: > From: Ilya Maximets <i.maximets@samsung.com> > > On 21.06.2017 13:29, Jerin Jacob wrote: > > > From: Thomas Monjalon <thomas@monjalon.net> > > >> 21/06/2017 11:27, Jerin Jacob: > > >>> From: Thomas Monjalon <thomas@monjalon.net> > > >>>> 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. In this case, you can enable it in common_base and disable it only for armv7 and dpaa2.