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š:
> > > From: Thomas Monjalon <tho...@monjalon.net>
> > > > 20/01/2021 09:41, Juraj Linkeš:
> > > > > From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
> > > > > > > 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 <tho...@monjalon.net>
> > > > > > > > > > > > 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".
OK now I understand all, thanks.
