From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 3F5485A3E for ; Tue, 20 Jun 2017 16:35:30 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E3AE620EC2; Tue, 20 Jun 2017 10:35:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 20 Jun 2017 10:35:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=cvZemVdN7NeXXAP lBf6mvWawFWj/+dJHrWj1xpqKl98=; b=WoIH+bQbPOhewtq91ttQJ5D4V5Fzt8N R40uWN5qXxIed/U8yGIze89VIQXV6d32LTXUqRbh0VtTFreNCajKoWZSKbPh58mK 6UOH1W7BbfSr3+zj1O07qWiDSYHGQnsjnSGPdewdKVv5bG2/U/2D5vM6oG4ej2dz fwAGmqtTVzyY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=cvZemVdN7NeXXAPlBf6mvWawFWj/+dJHrWj1xpqKl98=; b=r/twhKOx aVtnyaMuvEAaRuZeafH1BNFAc50v9f9A0og4qWFsjpLQpWDjQmYQmtP45DlnCD7S lfchpwt5Stta9ZJ8lV3YrNImAFjr5b9TwVqs9alRVPI2lHc92t5drYhEfVacsNEE 8iwsXTZpQlzqNjw4WL+e5kcqkUQL8tux7x3DloAzrwelL1Vy6S0HkZ9QTSPHB0Ef 0YPbxa4T6iMeRYOP7MnR/V6VqCGj2/ovWUTzIq0emvQ73RwGRfprcbmguWeMf0AA GPBtbW/WQLu8IZUGKt8Y2XIygyWvENO996nUgdQhvNdbQMCMsLUwoJ/7E/7rmowA Uu6jEu7YWeK4DA== X-ME-Sender: X-Sasl-enc: R5q1Qj4pib+K2SF4eKcLu1D+qI8vlLlFhX+FGwQqQ7WP 1497969329 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E6657E070; Tue, 20 Jun 2017 10:35:29 -0400 (EDT) From: Thomas Monjalon To: Ilya Maximets Cc: dev@dpdk.org, Hemant Agrawal , Sergio Gonzalez Monroy , Bruce Richardson , David Marchand , Heetae Ahn , Yuanhan Liu , Jianfeng Tan , Neil Horman , Yulong Pei Date: Tue, 20 Jun 2017 16:35:28 +0200 Message-ID: <3955508.CKAFNdPa9c@xps> In-Reply-To: References: <1496736832-835-1-git-send-email-i.maximets@samsung.com> <2889333.ySLvsRWIRF@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:35:30 -0000 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? > > 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). > 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.