From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 9A1E72E83 for ; Mon, 3 Jul 2017 16:20:21 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 470C220A5C; Mon, 3 Jul 2017 10:20:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 03 Jul 2017 10:20:21 -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=Vzu/6CrebquTGaO BWFx+tZ8f6+G47LcNNNy5kA3E8PI=; b=QqyHkF1jAia9b5TuGSUh0D37I0w70WK vUae7/jsDagoaDJ0i7gF57uTRg2U+Kyrx60OzuAX6642aDd51GRlKWXDJurcPcqu bBsK5gaNq8K8puDlzpitlF2dISr1UVCPc2ZGroaF1TCcMVaRL894xUzzLUlrFCRS wG8wKIgCK0Tk= 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=Vzu/6CrebquTGaOBWFx+tZ8f6+G47LcNNNy5kA3E8PI=; b=GocUAxbJ Zo1bT8Zobm6afqw4L4UBGrzxk8RbAfV323AbYiNTBqMjkU2ldpv+e7QAak/jOIwx 2spGuP7dfY4m/b2YBA5p9Veta9H1X1RRLGcW+kRF9+Ayi6jGMSf/+0A0yxwQ70QX LmlBBUJEc4QQwLmrbKHx6Y9aLy5b84xNcissKhDxuHxC1/5LKcM4U8U2og2Grl88 WkYoIG1EhM5jiLgcYTizKTDyaVFlMZnXOlSnfIrnhGHQiU1fSmlHeYW4wvWAa5ub ZMFW/dcHv6sxNdbI+EyoVX+w7gOsMH8Pm/n7k02P1ECOk7nvTgzbwFhP4lPY6Mjm DNu6hweagJK85g== X-ME-Sender: X-Sasl-enc: V3vfYkaq1PcAwbI4Qk1mAMzLp5KdS/0Ru3bjCy34YZEz 1499091621 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 013DA7E429; Mon, 3 Jul 2017 10:20:20 -0400 (EDT) From: Thomas Monjalon To: Sergio Gonzalez Monroy Cc: Gregory Etelson , dev@dpdk.org, Ilya Maximets , "Richardson, Bruce" , Jerin Jacob , "hemant.agrawal@nxp.com" Date: Mon, 03 Jul 2017 16:20:20 +0200 Message-ID: <3166039.3hnOorBvff@xps> In-Reply-To: <33607ba3-f359-de3e-1351-66140e693a44@intel.com> References: <25388622.XuEPg0MkIL@polaris> <4398639.Xci2ANazcN@xps> <33607ba3-f359-de3e-1351-66140e693a44@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: use get_mempolicy(2) to find numa socket on Linux 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: Mon, 03 Jul 2017 14:20:22 -0000 03/07/2017 16:11, Sergio Gonzalez Monroy: > On 01/07/2017 15:18, Thomas Monjalon wrote: > > 21/06/2017 17:49, Sergio Gonzalez Monroy: > >> I think following the discussion of libnuma dependency in another thread > >> [1], you would need to implement a similar approach and keep the old > >> method while providing this alternative if libnuma is present. > > Considering that libnuma becomes mandatory to build DPDK on NUMA-capable > > systems, we can assume there is only one CPU socket if libnuma is > > unavailable. > > > >> As Ilya mentions in the thread, this is usually the job of tools such as > >> autotools, cmake or meson but given that we do not have such tools in > >> DPDK yet, we rely in a build time config option for libnuma. > >> > >> Given that we already have a libnuma config option for VHOST, we might > >> be adding anew one for hugepage balancing, I think it would make sense > >> to just have single CONFIG_RTE_LIBNUMA option instead. > >> > >> Thoughts? > > I am not sure about merging every NUMA options into one. > > It may be interesting to track different NUMA features requiring libnuma. > > Do you see the case where a system with libnuma we want to use the > support for hugapage allocation but not for vhost? > In my opinion this looks like a manual check for libnuma where with a > different build system would have been automated. I think it is not related to the build system. We could have an automatic check for libnuma which enables several options. I'm just advocating to keep the different uses of libnuma clearly advertised in order to simply find what are the features enabled with this dependency.