From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sergio.gonzalez.monroy@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 7898520F
 for <dev@dpdk.org>; Tue, 20 Jun 2017 16:58:54 +0200 (CEST)
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
 by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 20 Jun 2017 07:58:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.39,364,1493708400"; d="scan'208";a="276481851"
Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.32])
 ([10.237.221.32])
 by fmsmga004.fm.intel.com with ESMTP; 20 Jun 2017 07:58:51 -0700
To: Thomas Monjalon <thomas@monjalon.net>,
 Ilya Maximets <i.maximets@samsung.com>
References: <1496736832-835-1-git-send-email-i.maximets@samsung.com>
 <2889333.ySLvsRWIRF@xps> <cf2a3124-6b44-05b9-f297-83df43a88ffd@samsung.com>
 <3955508.CKAFNdPa9c@xps>
Cc: dev@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>,
 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>
From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Message-ID: <7e71f1d8-f975-05ed-c14c-526c1c2c651f@intel.com>
Date: Tue, 20 Jun 2017 15:58:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <3955508.CKAFNdPa9c@xps>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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: Tue, 20 Jun 2017 14:58:55 -0000

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 <numaif.h>
>> 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