From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 03C3EA09E4; Thu, 21 Jan 2021 17:12:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DFF74140D1B; Thu, 21 Jan 2021 17:12:52 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id C3AA7140D0A for ; Thu, 21 Jan 2021 17:12:50 +0100 (CET) IronPort-SDR: lI9H6ozy4C4i8CaNdTWWsXF1cCvir9fgRMufN0Bg9AWbx+TnRvgvGb49RWdbrOldYBWvT5FGcS UVQwrJQx36cg== X-IronPort-AV: E=McAfee;i="6000,8403,9871"; a="178513272" X-IronPort-AV: E=Sophos;i="5.79,364,1602572400"; d="scan'208";a="178513272" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2021 08:12:49 -0800 IronPort-SDR: GOS8ggumz4KE89nYiZktnQh4t6nN/LWdAMPgQszUdiRnY2rGdyF4LInnmtzCji5u4I1s0RmlZt 5am3mgUqzz1Q== X-IronPort-AV: E=Sophos;i="5.79,364,1602572400"; d="scan'208";a="385362520" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.19.120]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 21 Jan 2021 08:12:46 -0800 Date: Thu, 21 Jan 2021 16:12:42 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Honnappa Nagarahalli , Juraj =?utf-8?Q?Linke=C5=A1?= , 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" , "aboyer@pensando.io" , "dev@dpdk.org" , nd Message-ID: <20210121161242.GD258@bricha3-MOBL.ger.corp.intel.com> References: <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech> <1722431.dKycXfZpIb@thomas> <12395282.DmjqacFy5q@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12395282.DmjqacFy5q@thomas> Subject: Re: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Thu, Jan 21, 2021 at 04:52:43PM +0100, Thomas Monjalon wrote: > 21/01/2021 16:02, Juraj Linkeš: > > From: Thomas Monjalon > > > 20/01/2021 09:41, Juraj Linkeš: > > > > From: Honnappa Nagarahalli > > > > > > 20/01/2021 02:04, Honnappa Nagarahalli: > > > > > > > > On Tue, Jan 19, 2021 at 04:52:19PM +0100, Thomas Monjalon wrote: > > > > > > > > > 19/01/2021 15:56, Juraj Linkeš: > > > > > > > > > > From: Thomas Monjalon > > > > > > > > > > > 15/01/2021 14:26, Juraj Linkeš: > > > > > > > > > > > > --- a/meson_options.txt > > > > > > > > > > > > +++ b/meson_options.txt > > > > > > > > > > > > +option('arm_soc', type: 'string', value: '', > > > > > > > > > > > > + description: 'Specify if you want to build for a > > > > > > > > > > > > +particular > > > > > > > > > > > > +aarch64 Arm SoC when building on an aarch64 > > > > > > > > > > > > +machine.') > > > > > > > > > > > > > > > > > > > > > > Why the option is named "arm_soc" and not just "soc"? > > > > > > > > > > > The same option could be used by other archs, isn't it? > > > > > > > > > > > > > > > > > > > > Agree that a more generic name would be better. > > > > > > > > > > I'll change it to "soc" if there are no other suggestions. > > > > > > > > > > > > > > > > > > Another name could be "machine". > > > > > > > > > Should it be the same mechanism as compiling for a specific > > > > > > > > > x86 CPU from an x86 machine? > > > > > > > > > > > > > > > > > I'd rather not re-use the term "machine", for a new use, > > > > > > > > better to use a new term IMHO. > > > > > > > +1, agree. 'soc' sounds good to me. > > > > > > > > > > > > Another possible word is "platform", as in > > > > > > http://doc.dpdk.org/guides/platform/index.html > > > > > I am fine with 'platform' too. > > > > > > > > > > > > > 'platform' is likely the best and actually works nicely with > > > http://patches.dpdk.org/patch/85956/. Taken together, 'platform' could be > > > either 'native', 'generic' or an soc, which is, I believe, exactly what we want. > > > > > > I am not sure what we want :) > > > We need to specify the instruction set, and the specific target. > > > We could deduce the instruction set from the target, but I think it is good to be > > > able to overwrite the instruction set in case there can be multiple instruction > > > sets for a target. > > > > > > > I think we had this (or similar) discussion here http://patches.dpdk.org/patch/85956/. I agree with your summary. > > > > > I think "native" and "generic" should be specified as instruction set, in the > > > existing option "machine" or renamed as "instruction_set" or "isa". > > > > > > > Agree, but I would add that we also want "native" and "generic" as valid platforms. More below. > > > > > Let's imagine the first option is "isa" and the new second option is "platform". > > > We can have a default "isa" per "platform". > > > The default "platform" would have a default "isa": native or generic? > > > > > > > In general, yes, but I let me expand the "platform" option a bit. > > > > Let's dig into what "platform" means. I understand it to be a set of configuration options, e.g.: > > platform=native: use discovered values for all configuration options (where we can do that) > > platform=generic: use predetermined values to produce a "generic" build that would work on most machine of the corresponding type/arch > > This is where I was disagreeing: > you propose to have 2 special values of platform (native and generic), > I propose to have only 1 default value for platform. > > After more thoughts, I think it's fine. > > > > platform=other: use predetermined values to produce a build tailored to platform "other", such as some arm soc. > > > > In all these cases, leave user the option to specify supported options (i.e. user can specifying "instruction_set" and that value would be used for machine args or "max_lcores" would set max lcores). > > > > The default "instruction_set" would be different per platform: > > What do you think about calling this option "isa"? > > > platform=native => instruction_set=native > > platform=generic => the generic instruction_set for the architecture, as specified here: https://github.com/DPDK/dpdk/blob/main/config/meson.build#L79 > > platform=other => the instruction set of the platform > > > > When "instruction_set" is set to its default value (such as auto), the per-platform instruction set would be used. If the user specifies anything else, that value would be used. > > Why auto? This is what we call native. > "auto" is a better term. If the platform is selected as "native" then the default isa will be "native", while if the platform is generic, the default isa should be something generic too. Since we unfortunately can't have one option automatically update the value of the other, we need to use a value of "auto" to allow platform to provide variable defaults for this, while still allowing explicit overrides. So in this case, "auto" will imply the isa being the same as the platform in most cases. In terms of other possible parameters, it makes even more sense. For example, for max lcores - as I understand it on ARM SoC's "native" is generally meant to set the max lcores to the detected values, while on x86 we want to allow some flexibility, so that if you compile on a 4-core VM, you can still run that binary on a 32-core machine of the same or later micro-architecture. In this case, "auto" again is a good value implying "choose what you think is best". /Bruce