From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5DF23A04DD; Fri, 20 Nov 2020 13:04:33 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 99E54C8A8; Fri, 20 Nov 2020 13:04:30 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id AC52EC87E for ; Fri, 20 Nov 2020 13:04:28 +0100 (CET) IronPort-SDR: Qx9hcVOrKpTRSatlv0DyZYKtDfca/YZbf+wPrYnj8+zMRVCr0fvIHhgzw9iABgjaJPox9NRHfQ I5QLfGS4ngCg== X-IronPort-AV: E=McAfee;i="6000,8403,9810"; a="159231319" X-IronPort-AV: E=Sophos;i="5.78,356,1599548400"; d="scan'208";a="159231319" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2020 04:04:10 -0800 IronPort-SDR: wY2+WhSVnZoBcr6KWEyKF4BkJoPZKGmeRODyjMLrLACDfNZU3sn1963Mjn4ZXM0iAoEpG9rvIQ P9Yg+qr9pidw== X-IronPort-AV: E=Sophos;i="5.78,356,1599548400"; d="scan'208";a="545419933" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.5.197]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 20 Nov 2020 04:04:07 -0800 Date: Fri, 20 Nov 2020 12:04:03 +0000 From: Bruce Richardson To: Juraj =?utf-8?Q?Linke=C5=A1?= Cc: Honnappa Nagarahalli , "thomas@monjalon.net" , Ruifeng Wang , Phil Yang , "vcchunga@amazon.com" , Dharmik Thakkar , "jerinjacobk@gmail.com" , "hemant.agrawal@nxp.com" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , "ferruh.yigit@intel.com" , "dev@dpdk.org" , nd Message-ID: <20201120120403.GA1387@bricha3-MOBL.ger.corp.intel.com> References: <2337679.hKZaPKL2be@thomas> <20201119121947.GC1829@bricha3-MOBL.ger.corp.intel.com> <20201119145101.GA1835@bricha3-MOBL.ger.corp.intel.com> <20201120101542.GA1376@bricha3-MOBL.ger.corp.intel.com> <20201120101933.GB1376@bricha3-MOBL.ger.corp.intel.com> <1cf3e1c4f1084692823701bbf0530331@pantheon.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1cf3e1c4f1084692823701bbf0530331@pantheon.tech> Subject: Re: [dpdk-dev] [PATCH v12 09/14] build: optional NUMA and cpu counts detection 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Nov 20, 2020 at 11:56:44AM +0000, Juraj Linkeš wrote: > > > > -----Original Message----- > > From: Bruce Richardson > > Sent: Friday, November 20, 2020 11:20 AM > > To: Honnappa Nagarahalli > > Cc: Juraj Linkeš ; thomas@monjalon.net; Ruifeng > > Wang ; Phil Yang ; > > vcchunga@amazon.com; Dharmik Thakkar ; > > jerinjacobk@gmail.com; hemant.agrawal@nxp.com; Ajit Khaparde > > (ajit.khaparde@broadcom.com) ; > > ferruh.yigit@intel.com; dev@dpdk.org; nd > > Subject: Re: [dpdk-dev] [PATCH v12 09/14] build: optional NUMA and cpu counts > > detection > > > > On Fri, Nov 20, 2020 at 10:15:42AM +0000, Bruce Richardson wrote: > > > On Fri, Nov 20, 2020 at 04:33:12AM +0000, Honnappa Nagarahalli wrote: > > > > > > > > > > > > > > > > > 18/11/2020 15:19, Juraj Linkeš: > > > > > > > > > > From: Thomas Monjalon > > > > > > > > > > > 16/11/2020 10:13, Bruce Richardson: > > > > > > > > > > > > On Mon, Nov 16, 2020 at 08:24:48AM +0100, Thomas > > > > > > > > > > > > Monjalon > > > > > wrote: > > > > > > > > > > > > > 13/11/2020 15:31, Juraj Linkeš: > > > > > > > > > > > > > > +option('max_lcores', type: 'integer', value: 0, > > > > > > > > > > > > > > + description: 'maximum number of cores/threads > > > > > > > > > > > > > > +supported by > > > > > > > > > EAL. > > > > > > > > > > > > > > +Set to positive integer to overwrite per-arch > > > > > > > > > > > > > > +or cross-compilation > > > > > > > > > > > defaults. Set to -1 to detect the number of cores on > > > > > > > > > > > the build > > > > > > > > > > > machine.') option('max_numa_nodes', type: 'integer', value: > > > > > > > > > > > 0, > > > > > > > > > > > > > > + description: 'maximum number of NUMA nodes > > > > > supported > > > > > > > > > > > > > > +by > > > > > > > > > EAL. > > > > > > > > > > > > > > +Set to positive integer to overwrite per-arch > > > > > > > > > > > > > > +or cross-compilation defaults. Set to -1 to > > > > > > > > > > > > > > +detect the number of numa nodes on the build > > > > > > > > > > > > > > +machine.') > > > > > > > > > > > > > > > > > > > > > > > > > > First comment: I don't like having so long description. > > > > > > > > > > > > > Second: I don't understand. > > > > > > > > > > > > > > > > > > > > > > > > > > It is said the default value is 0 so I expect it > > > > > > > > > > > > > means automatic > > > > > > > detection. > > > > > > > > > > > > > But later it is said -1 is for detection. So ? > > > > > > > > > > > > > > > > > > > > > > > > > Zero is for the "per-arch or cross-compilation default". > > > > > > > > > > > > This was discussed quite a bit in previous versions > > > > > > > > > > > > and this was te best compromise we could come up > > > > > > > > > > > > with. Having a default of auto-detect is definitely > > > > > > > > > > > > not something I think we should go with - just > > > > > > > > > > > > thinking of all the build CI jobs running on > > > > > > > > > > > > 2 or 4 core VMs! However, Juraj really felt there > > > > > > > > > > > > was value in having auto-detection, so it's set as a > > > > > > > > > > > > -1 value, which I'm > > > > > ok with. > > > > > > > > > > > > > > > > > > > > > > The problem is that I don't understand what 0 means. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are three pieces of information which we need to convey: > > > > > > > > > > 1. The default value (0) indicates that per-arch or > > > > > > > > > > cross-compilation defaults > > > > > > > > > will be used. > > > > > > > > > > 2. Positive integer values will be used instead of these defaults. > > > > > > > > > > > > > > > > > > Where these positive values come from? > > > > > > > > > > > > > > > > > > > > > > > > > From the user - they will have the option to set it to > > > > > > > > whatever the like if they > > > > > > > don't want to use defaults. > > > > > > > > > > > > > > > > > > 3. Detected values will be used for native build when the value is - > > 1. > > > > > > > > > > > > > > > > > > Why not detect for any native build set up with 0 (default)? > > > > > > > > > > > > > > > > > > > > > > > > > I'll let Bruce explain this, but I'll just say that we > > > > > > > > wanted to make the detection > > > > > > > the default for native builds, so we're in agreement. > > > > > > > > > > > > > > I think most of us agree that the different understanding of > > > > > > > the term "native build", is the cause of much of the > > > > > > > disagreements and > > > > Agree, that's the main reason. > > > > > > > > > > > points of dispute on this thread. From my view point, the term "native" > > > > > can refer to: > > > > > > > > > > > > > > 1. what meson considers a native build, i.e. one not using a > > > > > > > cross-file 2. a build for a different machine architecture to > > > > > > > the one on the > > > > > build > > > > > > > machine (this largely overlaps with #1, except that e.g. 32-bit build on > > > > > > > 64-bit may be considered a cross-build in this case). > > > > Sorry, I did not understand #2 here. Are you saying, native "means" - "a build > > for a different machine architecture to the one on the build machine" > > > > > > > > > > > 3. a build tailored exactly for the build machine itself i.e. both ISA, and > > > > > > > things like core counts. > > > > > > > 4. a flag passed to the compiler to indicate the uarch level of the > > > > > > > instruction set to be used, e.g. on x86, AVX2, AVX-512 etc., based on > > > > > > > that of the build machine. > > > > > > > > > > > > > > Historically, IIRC, in DPDK the "RTE_MACHINE" value was > > > > > > > originally > > > > > > > #4 since that was it's use on x86 in the first versions of DPDK. > > > > > > > With the move from make to meson, that aspect was kept, but > > > > > > > the meaning of #1 (I think we can ignore #2) also came into play. > > > > > > > Finally, while for x86 architecture, the idea of #4 still > > > > > > > held, for ARM use #3 > > > > > is of major concern. > > > > Yes, #3 is the concern. > > > > > > > > At the same time, I am also interested in avoiding 'native' (or any other > > option) having different meaning for different architectures. > > > > Now that we have introduced 'soc' option for Arm platforms, we are able to > > achieve the builds that would be produced by #3. > > > > 'soc' combines both the 'platform' and 'instruction set' (as you have defined > > them below). > > > > > > > > > > My thinking was that platform would be a synonym for "soc" for SOCs - > > > it would just seem weird to refer to x86 or PPC server systems as > > > soc's, so I thought "platform" a more neutral term. > > > Also, as I defined it above, the idea of "platform" would always > > > encompass the "instruction set" option too, unless the user explicitly > > > overrode it - hence the "auto" default value. > > > > > Also, we could document the "instruction set" value as a 'hint', rather than a > > mandatory value, which gives the arm meson.build files the option to ignore it if > > it doesn't make sense to use for a given value of "platform/soc". > > > > /Bruce > > Let's (or let me) put together a new patch that would decouple ISA from platform. How should we do this? > > I want to send this commit separately - should I add the ISA/platform to that series or do a completely new series? I like the latter, since we're basically done with reviewing this commit. > Yes, let's start a new series for this. It makes the whole thing easier to see and review. /Bruce