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 4C78CA09E4; Thu, 21 Jan 2021 16:52:51 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 36E18140CF1; Thu, 21 Jan 2021 16:52:51 +0100 (CET) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 1D387140CE9 for ; Thu, 21 Jan 2021 16:52:50 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7B661580392; Thu, 21 Jan 2021 10:52:48 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 21 Jan 2021 10:52:48 -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= o0L1HM/YuOUfjGoaR87ZJdkofPKUMsgoq+8pfpMxs2o=; b=bbuqj0IQKUPH4WuR st7LBzKFh2jT6EAZQEYiBIBgJTKS85BaQZXDi7RVlo03zJ0fff+0tcLbAixYB3Ln rprHVDncRxwpfLK09C7fyCYWMTuYJeYERvKwjq37DJxPhD5PK3G2+khzNvfYqsnv jR4nitwMSwjXh1O9W5CEjCYU9rx2VQavZGFdUEbyaENTnGTPaT+NjgLQjPmtxC3Y g78nySYDUenxx6Uuim/E2QWfsX667Hi6HYcNxV71a8yBmDakuU3eaFiGgcCTEBS7 WV9c+z3JF7GyxvsJXHGV3fndxBi94pMo3ZrUnl5x04TSlEOhWDXZkXV1A87GJ45E oFq9FQ== 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=o0L1HM/YuOUfjGoaR87ZJdkofPKUMsgoq+8pfpMxs 2o=; b=EyBIMBFo5mg75Vzs5rdvW7OmfJPQcUHVbgLnYTixxJ7HLsSbApWeKQRj+ SQRuQDSLYohQ+HGAOg69H8s4HGUUXsAYu2knLZJ96VfIgzmN25MENCEKphMrwWv4 2RJnTuBpxBWSciXhpJ5yvMbpRBfO0Zud26xrsBqRaoAGwZtr3wYfqCcIcEhTdfM0 FVUOLdv2OnP5G0CABaOSvlL5cyf+kwdAkItuy/zzcaaYPozS1syB7TkBjDA2Kai7 p2tUQgP4RuB24/ylzyHszohDCOYv6W4arHq7nOY8HrDT+G0MmqGOv67fLnnQGG/a +kbML9d5HAkW8YDXd43MMVySfVDAw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeggdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeehkeehjeekveelvedvleelhefhleehjeeuheeghfdugfeukeejheel keeiffevtdenucffohhmrghinhepughpughkrdhorhhgpdhgihhthhhusgdrtghomhenuc fkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 8BBC61080063; Thu, 21 Jan 2021 10:52:45 -0500 (EST) From: Thomas Monjalon To: Honnappa Nagarahalli , Juraj =?utf-8?B?TGlua2XFoQ==?= Cc: 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 16:52:43 +0100 Message-ID: <12395282.DmjqacFy5q@thomas> In-Reply-To: References: <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech> <1722431.dKycXfZpIb@thomas> 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 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 wro= te: > > > > > > > > 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 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. > >=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 ins= truction > > 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 set, = 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 valid = platforms. More below. >=20 > > Let's imagine the first option is "isa" and the new second option is "p= latform". > > We can have a default "isa" per "platform". > > The default "platform" would have a default "isa": native or generic? > >=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 conf= iguration options, e.g.: > platform=3Dnative: use discovered values for all configuration options (w= here we can do that) > platform=3Dgeneric: 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=3Dother: use predetermined values to produce a build tailored to= platform "other", such as some arm soc. >=20 > In all these cases, leave user the option to specify supported options (i= =2Ee. user can specifying "instruction_set" and that value would be used fo= r machine args or "max_lcores" would set max lcores). >=20 > The default "instruction_set" would be different per platform: What do you think about calling this option "isa"? > platform=3Dnative =3D> instruction_set=3Dnative > platform=3Dgeneric =3D> the generic instruction_set for the architecture,= as specified here: https://github.com/DPDK/dpdk/blob/main/config/meson.bui= ld#L79 > platform=3Dother =3D> the instruction set of the platform >=20 > When "instruction_set" is set to its default value (such as auto), the pe= r-platform instruction set would be used. If the user specifies anything el= se, that value would be used. Why auto? This is what we call native. > I basically just reworded Bruce's proposal from the other thread, since I= agree with it. >=20 > Using the "platform" option in this commit just extends the supported pla= tforms (from "native" and "default") by adding the soc platforms. (or the o= ther patch would extend the supported platforms, depending on in which orde= r the patches would be applied) >=20 > > What else do we need? > >=20 > >=20 >=20 > I think the above proposal (actually implemented here: http://patches.dpd= k.org/patch/85956/) gives us what we want, which I believe is this (which i= s basically your summary + maybe some extra thoughts): > 1. Arm wants to have the ability to choose a configuration set (i.e. the = "platform" option). We also refer to this as the "type" of the build. > 2. We also want to keep the current behavior of fine tuning the isa, whic= h the "instruction_set" option does. > 3. We don't want to change the default or expected behavior much or not a= t all, which we can do by choosing the right default values for "platform" = and "instruction_set".