-----Original Message-----
From: Thomas Monjalon <redacted>
Sent: Wednesday, January 20, 2021 5:10 PM
To: Honnappa Nagarahalli <redacted>; Bruce
Richardson [off-list ref]; Juraj Linkeš
[off-list ref]
Cc: Ruifeng Wang <redacted>; Phil Yang
[off-list ref]; vcchunga@amazon.com; Dharmik Thakkar
[off-list ref]; jerinjacobk@gmail.com;
hemant.agrawal@nxp.com; Ajit Khaparde (ajit.khaparde@broadcom.com)
[off-list ref]; ferruh.yigit@intel.com; aboyer@pensando.io;
dev@dpdk.org; nd [off-list ref]
Subject: Re: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option

20/01/2021 09:41, Juraj Linkeš:

quoted

From: Honnappa Nagarahalli <redacted>

quoted

quoted

20/01/2021 02:04, Honnappa Nagarahalli:

quoted

quoted

On Tue, Jan 19, 2021 at 04:52:19PM +0100, Thomas Monjalon wrote:

quoted

19/01/2021 15:56, Juraj Linkeš:

quoted

From: Thomas Monjalon <redacted>

quoted

15/01/2021 14:26, Juraj Linkeš:

quoted

--- 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
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:
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.

I basically just reworded Bruce's proposal from the other thread, since I agree with it.

Using the "platform" option in this commit just extends the supported platforms (from "native" and "default") by adding the soc platforms. (or the other patch would extend the supported platforms, depending on in which order the patches would be applied)

What else do we need?

I think the above proposal (actually implemented here: http://patches.dpdk.org/patch/85956/) gives us what we want, which I believe is this (which is 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, which the "instruction_set" option does.
3. We don't want to change the default or expected behavior much or not at all, which we can do by choosing the right default values for "platform" and "instruction_set".