From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Tue, 20 Jun 2017 21:11:40 +0530 Message-ID: <20170620154138.GA8453@jerin> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <2889333.ySLvsRWIRF@xps> <3955508.CKAFNdPa9c@xps> <7e71f1d8-f975-05ed-c14c-526c1c2c651f@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Thomas Monjalon , Ilya Maximets , dev@dpdk.org, Hemant Agrawal , Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Sergio Gonzalez Monroy Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0065.outbound.protection.outlook.com [104.47.38.65]) by dpdk.org (Postfix) with ESMTP id 4AFF3374C for ; Tue, 20 Jun 2017 17:42:06 +0200 (CEST) Content-Disposition: inline In-Reply-To: <7e71f1d8-f975-05ed-c14c-526c1c2c651f@intel.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: Tue, 20 Jun 2017 15:58:50 +0100 > From: Sergio Gonzalez Monroy > To: Thomas Monjalon , Ilya Maximets > > CC: dev@dpdk.org, Hemant Agrawal , Bruce Richardson > , David Marchand , > Heetae Ahn , Yuanhan Liu , > Jianfeng Tan , Neil Horman > , Yulong Pei > Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 > Thunderbird/45.1.1 > > On 20/06/2017 15:35, Thomas Monjalon wrote: > > 20/06/2017 15:58, Ilya Maximets: > > > On 20.06.2017 16:07, Thomas Monjalon wrote: > > > > 19/06/2017 13:10, Hemant Agrawal: > > > > > > > > On Thu, Jun 08, 2017 at 02:21:58PM +0300, Ilya Maximets wrote: > > > > > > > > > So, there are 2 option: > > > > > > > > > > > > > > > > > > 1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES > > > > > > > > > from the first version of the patch and disable it by default. > > > > > > > > > > > > > > > > > > 2. Keep patch as it is now and make everyone install libnuma > > > > > > > > > for successful build. > > > > > +1 for option 1 > > > > > It will be a issue and undesired dependency for SoCs, not supporting > > > > > NUMA architecture. > > > > > > > > > > It can be added to the config, who desired to use it by default. > > > > Yes I agree, it cannot be a dependency for architectures which > > > > do not support NUMA. > > > > Please can we rework the patch so that only one node is assumed > > > > if NUMA is disabled for the architecture? > > Ilya, I missed that libnuma is not supported on ARM. It is supported on arm64 and arm64 has NUMA machines(thunderx, thunderx2) too. [dpdk.org] $ dpkg-query -L libnuma-dev /. /usr /usr/lib /usr/lib/aarch64-linux-gnu /usr/lib/aarch64-linux-gnu/libnuma.a /usr/share /usr/share/man /usr/share/man/man3 /usr/share/man/man3/numa.3.gz /usr/share/doc /usr/share/doc/libnuma-dev /usr/share/doc/libnuma-dev/copyright /usr/include /usr/include/numaif.h /usr/include/numa.h /usr/include/numacompat1.h /usr/lib/aarch64-linux-gnu/libnuma.so > > > > We're still don't have dynamic build time configuration system. > > > To make get/set_mempolicy work we need to include > > > and have libnuma for successful linkage. > > > This means that the only option to not have libnuma as dependency > > > is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES > > > as it was in the first version of the patch. > > > > > > There is, actually, the third option (besides 2 already described): > > > > > > 3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES > > > from the first version of the patch and *enable* it by default. > > > In this case anyone who doesn't want to have libnuma as dependency > > > will be able to disable the config option manually. > > > > > > Thomas, what do you think? Bruce? Sergio? > > It should be enabled on x86 and ppc, and disabled in other > > default configurations (ARM for now). > > Agree. > > > > P.S. We're always able to implement syscall wrappers by hands without any > > > external dependencies, but I don't think it's a good decision. > > I agree to use libnuma instead of re-inventing the wheel. > > Let's just make it optional at build time and fallback on one node > > if disabled. > > That is the simple way out. > > Sergio