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 9D9F2A09E4; Thu, 21 Jan 2021 18:31:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 67B7A140DD3; Thu, 21 Jan 2021 18:31:34 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 73F76140DCC for ; Thu, 21 Jan 2021 18:31:33 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id C7D575805BC; Thu, 21 Jan 2021 12:31:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 21 Jan 2021 12:31:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= P5V2JngnFcYqrZ7HMDVzokAECBXu1X0TuBpElEP5zNs=; b=IdrvKldvkNXAzobU ExkPqLxqVGnBLyG6dT/g9J85Htp8hfUNmYTXSlJcOXnYhbNrl3LQ5wK5l+3emT6Y ruF8PTOag+ANcZZUiMerBm76TXz6JdLnyMCJ3A2MjaNfPHOIidge1NaM+gLTw8NC y9Ah4RjtZT1MyqCr0qarSkQe8BSY1qBCV/drzIILBjob2NG6m6FLDcyzBQb4P7Mv QN5+kNhIPTi52mIyY+lsEScAn8Ia5nfycdqJKDTGiHAiJbxLcO8OqJy/mXIylF+5 s/13BULK4UaM/DCeooZRfnQqgOTV15Ss4LxMzgX3An4pkvRaUQ1A561v5IU/1gsX kd70Mw== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=P5V2JngnFcYqrZ7HMDVzokAECBXu1X0TuBpElEP5z Ns=; b=N0QCTratUMvXrGPapb7f1Hf0jyW7XIzZYrGXJu30WlL1AEVGI99cTt0o0 19bObOjvwi6/Bm0UzsoCg6qMjRNfjUjm8SbvOq8BZvSjWHxDL37N4N+p9xltIdSu r1JCkMfnFv4neNzPbSEkxTjqCqzjpSBLJWElfKhp+6TEUPYhXC6gECYMPC8zCUJc MKOVTwNbmhrOgnWw/JZBMUmo81GQgse/WBVocTBN3U3ovN7gnTHNY8K3AkI/QZin NJsopxI52u7aReWCsSJa0ZrmFOdZ1EDraEvOyj67GCOSQWWhCVgm6DhiCAH/9v85 uCpi4/2bBQf89TlGiQNGfQqaxqbsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeggddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepheekheejkeevleevvdelleehhfelheejueehgefhudfgueekjeeh leekieffvedtnecuffhomhgrihhnpeguphgukhdrohhrghdpghhithhhuhgsrdgtohhmne cukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 11D4F108005C; Thu, 21 Jan 2021 12:31:29 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson Cc: Honnappa Nagarahalli , Juraj =?utf-8?B?TGlua2XFoQ==?= , 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 Date: Thu, 21 Jan 2021 18:31:27 +0100 Message-ID: <2827865.u46X8b0EpR@thomas> In-Reply-To: <20210121161242.GD258@bricha3-MOBL.ger.corp.intel.com> References: <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech> <12395282.DmjqacFy5q@thomas> <20210121161242.GD258@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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" 21/01/2021 17:12, Bruce Richardson: > On Thu, Jan 21, 2021 at 04:52:43PM +0100, Thomas Monjalon wrote: > > 21/01/2021 16:02, Juraj Linke=C5=A1: > > > From: Thomas Monjalon > > > > 20/01/2021 09:41, Juraj Linke=C5=A1: > > > > > 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=C5=A1: > > > > > > > > > > > From: Thomas Monjalon > > > > > > > > > > > > 15/01/2021 14:26, Juraj Linke=C5=A1: > > > > > > > > > > > > > --- 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 suggest= ions. > > > > > > > > > > > > > > > > > > > > Another name could be "machine". > > > > > > > > > > Should it be the same mechanism as compiling for a spec= ific > > > > > > > > > > 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' co= uld be > > > > either 'native', 'generic' or an soc, which is, I believe, exactly = what we want. > > > >=20 > > > > 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. > > > >=20 > > >=20 > > > I think we had this (or similar) discussion here http://patches.dpdk.= org/patch/85956/. I agree with your summary. > > >=20 > > > > I think "native" and "generic" should be specified as instruction s= et, in the > > > > existing option "machine" or renamed as "instruction_set" or "isa". > > > >=20 > > >=20 > > > Agree, but I would add that we also want "native" and "generic" as va= lid platforms. More below. > > >=20 > > > > Let's imagine the first option is "isa" and the new second option i= s "platform". > > > > We can have a default "isa" per "platform". > > > > The default "platform" would have a default "isa": native or generi= c? > > > >=20 > > >=20 > > > In general, yes, but I let me expand the "platform" option a bit. > > >=20 > > > Let's dig into what "platform" means. I understand it to be a set of = configuration options, e.g.: > > > platform=3Dnative: use discovered values for all configuration option= s (where we can do that) > > > platform=3Dgeneric: use predetermined values to produce a "generic" b= uild that would work on most machine of the corresponding type/arch > >=20 > > 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. > >=20 > > After more thoughts, I think it's fine. > >=20 > >=20 > > > platform=3Dother: use predetermined values to produce a build tailore= d to platform "other", such as some arm soc. > > >=20 > > > In all these cases, leave user the option to specify supported option= s (i.e. user can specifying "instruction_set" and that value would be used = for machine args or "max_lcores" would set max lcores). > > >=20 > > > The default "instruction_set" would be different per platform: > >=20 > > What do you think about calling this option "isa"? > >=20 > > > platform=3Dnative =3D> instruction_set=3Dnative > > > platform=3Dgeneric =3D> the generic instruction_set for the architect= ure, as specified here: https://github.com/DPDK/dpdk/blob/main/config/meson= =2Ebuild#L79 > > > platform=3Dother =3D> the instruction set of the platform > > >=20 > > > When "instruction_set" is set to its default value (such as auto), th= e per-platform instruction set would be used. If the user specifies anythin= g else, that value would be used. > >=20 > > Why auto? This is what we call native. > >=20 >=20 > "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 defau= lt > 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. >=20 > 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". OK now I understand all, thanks.