From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:TqMJYCQ72JYuCvnbEaQMb4-W2wRDl40wT41fqHCmK-sbubsQTKFBvw>
<xme:TqMJYHyiWYQ_oO56jni_e6CzqdirDhc47JhCrMFsQC5_-ck9pfF-RXNdOvf8f1llr
REmRIsfgpssOqp8Cg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeggdekgecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs
ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
frrghtthgvrhhnpeehkeehjeekveelvedvleelhefhleehjeeuheeghfdugfeukeejheel
keeiffevtdenucffohhmrghinhepughpughkrdhorhhgpdhgihhthhhusgdrtghomhenuc
fkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfr
rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:TqMJYP3u1SumQZ20CzV2o2Y8zWLUU1KtAbFotDqfb0CkDHCB5aOjRg>
<xmx:TqMJYOB77doQCGP49NCMJUavWtQevXTymPfTLt2iQGSIc01VF3Namw>
<xmx:TqMJYLjCLEMjablY7DGkNzaRGMGVIEAiXGYbSBcpLSZFPx03ez-TNg>
<xmx:UKMJYAZzqTNnpbBTuMTYrBOSX-LEezuGbcDvR2NNa4iB7FTzkS4Yig>
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 <thomas@monjalon.net>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Juraj =?utf-8?B?TGlua2XFoQ==?= <juraj.linkes@pantheon.tech>
Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>, Phil Yang <Phil.Yang@arm.com>,
"vcchunga@amazon.com" <vcchunga@amazon.com>,
Dharmik Thakkar <Dharmik.Thakkar@arm.com>,
"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"Ajit Khaparde (ajit.khaparde@broadcom.com)" <ajit.khaparde@broadcom.com>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"aboyer@pensando.io" <aboyer@pensando.io>, "dev@dpdk.org" <dev@dpdk.org>,
nd <nd@arm.com>
Date: Thu, 21 Jan 2021 16:52:43 +0100
Message-ID: <12395282.DmjqacFy5q@thomas>
In-Reply-To: <ef896f2973a640d5a3896718a7d01fc0@pantheon.tech>
References: <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech>
<1722431.dKycXfZpIb@thomas> <ef896f2973a640d5a3896718a7d01fc0@pantheon.tech>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
21/01/2021 16:02, Juraj Linke=C5=A1:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 20/01/2021 09:41, Juraj Linke=C5=A1:
> > > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > > 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 <thomas@monjalon.net>
> > > > > > > > > > 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".