From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergio Gonzalez Monroy Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Tue, 20 Jun 2017 15:58:50 +0100 Message-ID: <7e71f1d8-f975-05ed-c14c-526c1c2c651f@intel.com> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <2889333.ySLvsRWIRF@xps> <3955508.CKAFNdPa9c@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Hemant Agrawal , Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Thomas Monjalon , Ilya Maximets Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 7898520F for ; Tue, 20 Jun 2017 16:58:54 +0200 (CEST) In-Reply-To: <3955508.CKAFNdPa9c@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 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. >> 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