From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
Date: Wed, 21 Jun 2017 11:58:12 +0200
Message-ID: <2845661.r9ChRO7rgB@xps>
References: <1496736832-835-1-git-send-email-i.maximets@samsung.com>
 <3795576.X6Zydzo19D@xps> <20170621092744.GA26030@jerin>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>,
 Ilya Maximets <i.maximets@samsung.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>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 777555583
 for <dev@dpdk.org>; Wed, 21 Jun 2017 11:58:14 +0200 (CEST)
In-Reply-To: <20170621092744.GA26030@jerin>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

21/06/2017 11:27, Jerin Jacob:
> -----Original Message-----
> > Date: Wed, 21 Jun 2017 10:49:14 +0200
> > From: Thomas Monjalon <thomas@monjalon.net>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>, Hemant
> >  Agrawal <hemant.agrawal@nxp.com>, Ilya Maximets <i.maximets@samsung.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>
> > 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.