From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hemant Agrawal Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages Date: Wed, 21 Jun 2017 13:44:20 +0530 Message-ID: <40e6b510-72cc-5459-6861-75b6837e3392@nxp.com> References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <2889333.ySLvsRWIRF@xps> <3955508.CKAFNdPa9c@xps> <7e71f1d8-f975-05ed-c14c-526c1c2c651f@intel.com> <20170620154138.GA8453@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Monjalon , Ilya Maximets , , Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei To: Jerin Jacob , Sergio Gonzalez Monroy Return-path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0083.outbound.protection.outlook.com [104.47.36.83]) by dpdk.org (Postfix) with ESMTP id C763F5599 for ; Wed, 21 Jun 2017 10:14:34 +0200 (CEST) In-Reply-To: <20170620154138.GA8453@jerin> 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 6/20/2017 9:11 PM, Jerin Jacob wrote: > -----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 > 1. There are many machines (arm/ppc), which do not support NUMA. https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA 2. I could not locate it by default in Linaro toolchains. 3. Since this is not a common across all platform. This option should not be added to the common_base or common configs. It can be added to any architecture configuration, which needs it. Regards, Hemant > >> >>>> 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 >