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 C5C06A04DB; Mon, 16 Nov 2020 10:13:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1CA63C8B2; Mon, 16 Nov 2020 10:13:18 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 4D561C8B0 for ; Mon, 16 Nov 2020 10:13:15 +0100 (CET) IronPort-SDR: WbAJZ3KHPos1Eco90NZ/jNNqBY+ScBxmNgH/tHyNal87Z31fLFEO20sHrsKV9kE5a6arDmDT38 Gqgb4Vqhf7EA== X-IronPort-AV: E=McAfee;i="6000,8403,9806"; a="255430661" X-IronPort-AV: E=Sophos;i="5.77,482,1596524400"; d="scan'208";a="255430661" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Nov 2020 01:13:10 -0800 IronPort-SDR: 59MHk9NeQYHeynVEV9oCC0yC6ZWOh8RXQavDjj64fTHQUdkGEqbv5H1UGftvZvetGRObjCVTEY LchV6qm7xKWQ== X-IronPort-AV: E=Sophos;i="5.77,482,1596524400"; d="scan'208";a="358398806" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.82.79]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Nov 2020 01:13:07 -0800 Date: Mon, 16 Nov 2020 09:13:03 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Juraj =?utf-8?Q?Linke=C5=A1?= , Ruifeng.Wang@arm.com, Honnappa.Nagarahalli@arm.com, Phil.Yang@arm.com, vcchunga@amazon.com, Dharmik.Thakkar@arm.com, jerinjacobk@gmail.com, hemant.agrawal@nxp.com, ajit.khaparde@broadcom.com, ferruh.yigit@intel.com, dev@dpdk.org Message-ID: <20201116091303.GA1469@bricha3-MOBL.ger.corp.intel.com> References: <1605267483-13167-1-git-send-email-juraj.linkes@pantheon.tech> <1605277875-13625-1-git-send-email-juraj.linkes@pantheon.tech> <1605277875-13625-10-git-send-email-juraj.linkes@pantheon.tech> <6632500.QiOchURiYm@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6632500.QiOchURiYm@thomas> 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 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. As I flagged in a previous mail thread, the whole config of DPDK builds is something we need to take a bigger look at in 21.02 and beyond. /Bruce