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 0FBA0A04DD; Fri, 20 Nov 2020 11:15:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 97016F90; Fri, 20 Nov 2020 11:15:55 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 8A4683B5 for ; Fri, 20 Nov 2020 11:15:52 +0100 (CET) IronPort-SDR: 8manxoWGO1rr5wZKeFiixbTFnOpNDitETXjZUVNLlOeKa9zDS5/PJdNre8pTwz21N5lrrkR/HH SdnPPdjKQ19Q== X-IronPort-AV: E=McAfee;i="6000,8403,9810"; a="170668963" X-IronPort-AV: E=Sophos;i="5.78,356,1599548400"; d="scan'208";a="170668963" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2020 02:15:50 -0800 IronPort-SDR: XMMGwkp35qzbnlrBekrpYl9nDJlLddJIVXBgkozFFMYXR8yMk5TRRmv40ffUAgAHqUY3pMMfqM MKV0UcmgwlSg== X-IronPort-AV: E=Sophos;i="5.78,356,1599548400"; d="scan'208";a="535114019" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.5.197]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 20 Nov 2020 02:15:46 -0800 Date: Fri, 20 Nov 2020 10:15:42 +0000 From: Bruce Richardson To: Honnappa Nagarahalli Cc: Juraj =?utf-8?Q?Linke=C5=A1?= , "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: <20201120101542.GA1376@bricha3-MOBL.ger.corp.intel.com> References: <1605267483-13167-1-git-send-email-juraj.linkes@pantheon.tech> <11763925.GOiJPSdkav@thomas> <2337679.hKZaPKL2be@thomas> <20201119121947.GC1829@bricha3-MOBL.ger.corp.intel.com> <20201119145101.GA1835@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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. /Bruce