[v15,11/12] build: add Arm SoC meson option
Checks
Commit Message
Add Arm SoC configuration to Arm meson.build and add a meson option to
enable those options for native builds. This is preferable to
specifying a cross file when doing aarch64 -> aarch64 builds, since the
cross file specifies the toolchain as well.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
config/arm/arm64_armada_linux_gcc | 7 +-
config/arm/arm64_armv8_linux_gcc | 5 +-
config/arm/arm64_bluefield_linux_gcc | 6 +-
config/arm/arm64_dpaa_linux_gcc | 6 +-
config/arm/arm64_emag_linux_gcc | 5 +-
config/arm/arm64_graviton2_linux_gcc | 6 +-
config/arm/arm64_n1sdp_linux_gcc | 6 +-
config/arm/arm64_n2_linux_gcc | 6 +-
config/arm/arm64_octeontx2_linux_gcc | 6 +-
config/arm/arm64_stingray_linux_gcc | 6 +-
config/arm/arm64_thunderx2_linux_gcc | 5 +-
config/arm/arm64_thunderxt88_linux_gcc | 5 +-
config/arm/meson.build | 136 +++++++++++++++++-
.../linux_gsg/cross_build_dpdk_for_arm64.rst | 80 ++++-------
meson_options.txt | 2 +
15 files changed, 174 insertions(+), 113 deletions(-)
Comments
15/01/2021 14:26, Juraj Linkeš:
> Add Arm SoC configuration to Arm meson.build and add a meson option to
> enable those options for native builds. This is preferable to
> specifying a cross file when doing aarch64 -> aarch64 builds, since the
> cross file specifies the toolchain as well.
>
> Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
[...]
> --- a/config/arm/arm64_graviton2_linux_gcc
> +++ b/config/arm/arm64_graviton2_linux_gcc
> [properties]
> -implementor_id = '0x41'
> -implementor_pn = '0xd0c'
> -max_lcores = 64
> -max_numa_nodes = 1
> -numa = false
> +soc = 'graviton2'
[...]
> --- 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.')
This is more elegant, I like how cross and native share almost the same option.
Why the option is named "arm_soc" and not just "soc"?
The same option could be used by other archs, isn't it?
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 18, 2021 2:42 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com;
> Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com;
> vcchunga@amazon.com; Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com;
> ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option
>
> 15/01/2021 14:26, Juraj Linkeš:
> > Add Arm SoC configuration to Arm meson.build and add a meson option to
> > enable those options for native builds. This is preferable to
> > specifying a cross file when doing aarch64 -> aarch64 builds, since
> > the cross file specifies the toolchain as well.
> >
> > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> [...]
> > --- a/config/arm/arm64_graviton2_linux_gcc
> > +++ b/config/arm/arm64_graviton2_linux_gcc
> > [properties]
> > -implementor_id = '0x41'
> > -implementor_pn = '0xd0c'
> > -max_lcores = 64
> > -max_numa_nodes = 1
> > -numa = false
> > +soc = 'graviton2'
> [...]
> > --- 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.')
>
> This is more elegant, I like how cross and native share almost the same option.
>
> 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.
19/01/2021 15:56, Juraj Linkeš:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 15/01/2021 14:26, Juraj Linkeš:
> > > Add Arm SoC configuration to Arm meson.build and add a meson option to
> > > enable those options for native builds. This is preferable to
> > > specifying a cross file when doing aarch64 -> aarch64 builds, since
> > > the cross file specifies the toolchain as well.
> > >
> > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > [...]
> > > --- a/config/arm/arm64_graviton2_linux_gcc
> > > +++ b/config/arm/arm64_graviton2_linux_gcc
> > > [properties]
> > > -implementor_id = '0x41'
> > > -implementor_pn = '0xd0c'
> > > -max_lcores = 64
> > > -max_numa_nodes = 1
> > > -numa = false
> > > +soc = 'graviton2'
> > [...]
> > > --- 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.')
> >
> > This is more elegant, I like how cross and native share almost the same option.
> >
> > 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?
On Tue, Jan 19, 2021 at 04:52:19PM +0100, Thomas Monjalon wrote:
> 19/01/2021 15:56, Juraj Linkeš:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 15/01/2021 14:26, Juraj Linkeš:
> > > > Add Arm SoC configuration to Arm meson.build and add a meson option to
> > > > enable those options for native builds. This is preferable to
> > > > specifying a cross file when doing aarch64 -> aarch64 builds, since
> > > > the cross file specifies the toolchain as well.
> > > >
> > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > [...]
> > > > --- a/config/arm/arm64_graviton2_linux_gcc
> > > > +++ b/config/arm/arm64_graviton2_linux_gcc
> > > > [properties]
> > > > -implementor_id = '0x41'
> > > > -implementor_pn = '0xd0c'
> > > > -max_lcores = 64
> > > > -max_numa_nodes = 1
> > > > -numa = false
> > > > +soc = 'graviton2'
> > > [...]
> > > > --- 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.')
> > >
> > > This is more elegant, I like how cross and native share almost the same option.
> > >
> > > 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.
<snip>
>
> On Tue, Jan 19, 2021 at 04:52:19PM +0100, Thomas Monjalon wrote:
> > 19/01/2021 15:56, Juraj Linkeš:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 15/01/2021 14:26, Juraj Linkeš:
> > > > > Add Arm SoC configuration to Arm meson.build and add a meson
> > > > > option to enable those options for native builds. This is
> > > > > preferable to specifying a cross file when doing aarch64 ->
> > > > > aarch64 builds, since the cross file specifies the toolchain as well.
> > > > >
> > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > Reviewed-by: Honnappa Nagarahalli
> <honnappa.nagarahalli@arm.com>
> > > > [...]
> > > > > --- a/config/arm/arm64_graviton2_linux_gcc
> > > > > +++ b/config/arm/arm64_graviton2_linux_gcc
> > > > > [properties]
> > > > > -implementor_id = '0x41'
> > > > > -implementor_pn = '0xd0c'
> > > > > -max_lcores = 64
> > > > > -max_numa_nodes = 1
> > > > > -numa = false
> > > > > +soc = 'graviton2'
> > > > [...]
> > > > > --- 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.')
> > > >
> > > > This is more elegant, I like how cross and native share almost the same
> option.
> > > >
> > > > 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.
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 <thomas@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
<snip>
>
> 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 <thomas@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.
>
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Wednesday, January 20, 2021 3:20 AM
> To: thomas@monjalon.net; Bruce Richardson <bruce.richardson@intel.com>;
> Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; vcchunga@amazon.com; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; Ajit Khaparde (ajit.khaparde@broadcom.com)
> <ajit.khaparde@broadcom.com>; ferruh.yigit@intel.com; aboyer@pensando.io;
> dev@dpdk.org; nd <nd@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>
> Subject: RE: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option
>
> <snip>
> >
> > 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 <thomas@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.
20/01/2021 09:41, Juraj Linkeš:
> 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 wrote:
> > > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > > From: Thomas Monjalon <thomas@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 "native" and "generic" should be specified as instruction set,
in the existing option "machine" or renamed as "instruction_set" or "isa".
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?
What else do we need?
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, January 20, 2021 5:10 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Bruce
> Richardson <bruce.richardson@intel.com>; Juraj Linkeš
> <juraj.linkes@pantheon.tech>
> Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>; Phil Yang
> <Phil.Yang@arm.com>; vcchunga@amazon.com; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; Ajit Khaparde (ajit.khaparde@broadcom.com)
> <ajit.khaparde@broadcom.com>; ferruh.yigit@intel.com; aboyer@pensando.io;
> dev@dpdk.org; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option
>
> 20/01/2021 09:41, Juraj Linkeš:
> > 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 wrote:
> > > > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > > > From: Thomas Monjalon <thomas@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
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".
21/01/2021 16:02, Juraj Linkeš:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 20/01/2021 09:41, Juraj Linkeš:
> > > 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 wrote:
> > > > > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > > > > From: Thomas Monjalon <thomas@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.
> 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".
On Thu, Jan 21, 2021 at 04:52:43PM +0100, Thomas Monjalon wrote:
> 21/01/2021 16:02, Juraj Linkeš:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 20/01/2021 09:41, Juraj Linkeš:
> > > > 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 wrote:
> > > > > > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > > > > > From: Thomas Monjalon <thomas@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".
/Bruce
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 <thomas@monjalon.net>
> > > > 20/01/2021 09:41, Juraj Linkeš:
> > > > > 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 wrote:
> > > > > > > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > > > > > > From: Thomas Monjalon <thomas@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.
@@ -14,9 +14,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x56'
-part_number = '0xd08'
-max_lcores = 16
-max_numa_nodes = 1
-numa = false
-disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
+soc = 'armada'
@@ -14,7 +14,4 @@ endian = 'little'
[properties]
# Generate binaries that are portable across all Armv8 machines
-implementer_id = 'generic'
-part_number = 'generic'
-max_lcores = 256
-max_numa_nodes = 4
+soc = 'generic'
@@ -13,8 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x41'
-part_number = '0xd08'
-max_lcores = 16
-max_numa_nodes = 1
-numa = false
+soc = 'bluefield'
@@ -14,8 +14,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = 'dpaa'
-part_number = '0xd08'
-max_lcores = 16
-max_numa_nodes = 1
-numa = false
+soc = 'dpaa'
@@ -13,7 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x50'
-part_number = '0x0'
-max_lcores = 32
-max_numa_nodes = 1
+soc = 'emag'
@@ -13,8 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementor_id = '0x41'
-implementor_pn = '0xd0c'
-max_lcores = 64
-max_numa_nodes = 1
-numa = false
+soc = 'graviton2'
@@ -13,8 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x41'
-part_number = '0xd0c'
-max_lcores = 4
-max_numa_nodes = 1
-numa = false
+soc = 'n1sdp'
@@ -13,8 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x41'
-part_number = '0xd49'
-max_lcores = 64
-max_numa_nodes = 1
-numa = false
+soc = 'n2'
@@ -13,8 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x43'
-part_number = '0xb2'
-max_lcores = 36
-max_numa_nodes = 1
-numa = false
+soc = 'octeontx2'
@@ -13,8 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x41'
-part_number = '0xd08'
-max_lcores = 16
-max_numa_nodes = 1
-numa = false
+soc = 'stingray'
@@ -13,7 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x43'
-part_number = '0xaf'
-max_lcores = 256
-max_numa_nodes = 2
+soc = 'thunderx2'
@@ -13,7 +13,4 @@ cpu = 'armv8-a'
endian = 'little'
[properties]
-implementer_id = '0x43'
-part_number = '0xa1'
-max_lcores = 96
-max_numa_nodes = 1
+soc = 'thunderxt88'
@@ -29,7 +29,7 @@ native_machine_args = ['-mcpu=native']
## Part numbers are specific to Arm implementers
# implementer specific aarch64 flags have middle priority
# (will overwrite common flags)
-# part number specific aarch64 flags have the highest priority
+# part number specific aarch64 flags have higher priority
# (will overwrite both common and implementer specific flags)
implementer_generic = {
'description': 'Generic armv8',
@@ -181,6 +181,106 @@ implementers = {
'dpaa': implementer_dpaa
}
+# soc specific aarch64 flags have the highest priority
+# (will overwrite all other flags)
+soc_generic = {
+ 'description': 'Generic un-optimized build for all aarch64 machines.',
+ 'implementer': 'generic',
+ 'part_number': 'generic'
+}
+
+soc_armada = {
+ 'description': 'Marvell ARMADA',
+ 'implementer': '0x56',
+ 'part_number': '0xd08',
+ 'numa': false,
+ 'disabled_drivers': ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
+}
+
+soc_bluefield = {
+ 'description': 'NVIDIA BlueField',
+ 'implementer': '0x41',
+ 'part_number': '0xd08',
+ 'numa': false
+}
+
+soc_dpaa = {
+ 'description': 'NXP DPAA',
+ 'implementer': 'dpaa',
+ 'part_number': '0xd08',
+ 'numa': false
+}
+
+soc_emag = {
+ 'description': 'Ampere eMAG',
+ 'implementer': '0x50',
+ 'part_number': '0x0'
+}
+
+soc_graviton2 = {
+ 'description': 'AWS Graviton2',
+ 'implementer': '0x41',
+ 'part_number': '0xd0c',
+ 'numa': false
+}
+
+soc_n1sdp = {
+ 'description': 'Arm Neoverse N1SDP',
+ 'implementer': '0x41',
+ 'part_number': '0xd0c',
+ 'flags': [
+ ['RTE_MAX_LCORE', 4]
+ ],
+ 'numa': false
+}
+
+soc_n2 = {
+ 'description': 'Arm Neoverse N2',
+ 'implementer': '0x41',
+ 'part_number': '0xd49',
+ 'numa': false
+}
+
+soc_octeontx2 = {
+ 'description': 'Marvell OCTEON TX2',
+ 'implementer': '0x43',
+ 'part_number': '0xb2',
+ 'numa': false
+}
+
+soc_stingray = {
+ 'description': 'Broadcom Stingray',
+ 'implementer': '0x41',
+ 'part_number': '0xd08',
+ 'numa': false
+}
+
+soc_thunderx2 = {
+ 'description': 'Marvell ThunderX2 T99',
+ 'implementer': '0x43',
+ 'part_number': '0xaf'
+}
+
+soc_thunderxt88 = {
+ 'description': 'Marvell ThunderX T88',
+ 'implementer': '0x43',
+ 'part_number': '0xa1'
+}
+
+socs = {
+ 'generic': soc_generic,
+ 'armada': soc_armada,
+ 'bluefield': soc_bluefield,
+ 'dpaa': soc_dpaa,
+ 'emag': soc_emag,
+ 'graviton2': soc_graviton2,
+ 'n1sdp': soc_n1sdp,
+ 'octeontx2': soc_octeontx2,
+ 'stingray': soc_stingray,
+ 'thunderx2': soc_thunderx2,
+ 'thunderxt88': soc_thunderxt88
+}
+
dpdk_conf.set('RTE_ARCH_ARM', 1)
dpdk_conf.set('RTE_FORCE_INTRINSICS', 1)
@@ -193,11 +293,18 @@ if dpdk_conf.get('RTE_ARCH_32')
else
# aarch64 build
use_native_machine_args = false
+ arm_soc = get_option('arm_soc')
+ soc_config = {}
if not meson.is_cross_build()
if machine == 'default'
# default build
+ if arm_soc != ''
+ error('Arm SoC is unsupported with default build.')
+ endif
implementer_id = 'generic'
part_number = 'generic'
+ elif arm_soc != ''
+ soc_config = socs.get(arm_soc, {'not_supported': true})
else
# native build
# The script returns ['Implementer', 'Variant', 'Architecture',
@@ -216,8 +323,27 @@ else
endif
else
# cross build
- implementer_id = meson.get_cross_property('implementer_id')
- part_number = meson.get_cross_property('part_number')
+ arm_soc = meson.get_cross_property('soc', '')
+ if arm_soc == ''
+ error('Arm SoC must be specified in the cross file.')
+ endif
+ soc_config = socs.get(arm_soc, {'not_supported': true})
+ endif
+
+ soc_flags = []
+ if soc_config.has_key('not_supported')
+ error('SoC @0@ not supported.'.format(arm_soc))
+ elif soc_config != {}
+ implementer_id = soc_config['implementer']
+ implementer_config = implementers[implementer_id]
+ part_number = soc_config['part_number']
+ soc_flags = soc_config.get('flags', [])
+ if not soc_config.get('numa', true)
+ has_libnuma = 0
+ endif
+ if soc_config.has_key('disabled_drivers')
+ disabled_drivers += soc_config['disabled_drivers']
+ endif
endif
if implementers.has_key(implementer_id)
@@ -243,8 +369,8 @@ else
'(-Dmachine=generic) build.')
endif
- # use default flags with implementer flags
- dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', [])
+ # add flags in the proper order
+ dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
# apply supported machine args
machine_args = [] # Clear previous machine args
@@ -100,54 +100,32 @@ command::
meson arm64-build --cross-file config/arm/arm64_armv8_linux_gcc
ninja -C arm64-build
-Supported cross-compilation targets
------------------------------------
-
-If you wish to build for a target which is not among the current cross-files,
-you may use various combinations of implementer/part number::
-
- Supported implementers:
- 'generic': Generic armv8
- '0x41': Arm
- '0x43': Cavium
- '0x50': Ampere Computing
- '0x56': Marvell ARMADA
- 'dpaa': NXP DPAA
-
- Supported part_numbers for generic:
- 'generic': valid for all armv8-a architectures (unoptimized portable build)
-
- Supported part_numbers for 0x41, 0x56, dpaa:
- '0xd03': cortex-a53
- '0xd04': cortex-a35
- '0xd09': cortex-a73
- '0xd0a': cortex-a75
- '0xd0b': cortex-a76
- '0xd0c': neoverse-n1
-
- Supported part_numbers for 0x43:
- '0xa1': thunderxt88
- '0xa2': thunderxt81
- '0xa3': thunderxt83
- '0xaf': thunderx2t99
- '0xb2': octeontx2
-
- Supported part_numbers for 0x50:
- '0x0': emag
-
-Other cross file options
-------------------------
-
-There are other options you may specify in a cross file to tailor the build::
-
- Supported extra configuration
- max_numa_nodes = n # will set RTE_MAX_NUMA_NODES
- max_lcores = n # will set RTE_MAX_LCORE
-
- disabled_drivers = ['bus/dpaa', 'crypto'] # add disabled drivers
- # valid values are directories (optionally with their subdirs)
- # in the drivers directory
-
- numa = false # set to false to force building for a non-NUMA system
- # if not set or set to true, the build system will build for a NUMA
- # system only if libnuma is installed
+Building for an aarch64 SoC on an aarch64 build machine
+-------------------------------------------------------
+
+If you wish to build on an aarch64 build machine for a different aarch64 SoC,
+you don't need a separate cross toolchain, just a different set of
+configuration options. To build for an aarch64 SoC, use the -Darm_soc meson
+option::
+
+ meson soc_build -Darm_soc=<target_soc>
+
+Substitute <target_soc> with one of the supported SoCs::
+
+ generic: Generic un-optimized build for all aarch64 machines.
+ armada: Marvell ARMADA
+ bluefield: NVIDIA BlueField
+ dpaa: NXP DPAA
+ emag: Ampere eMAG
+ graviton2: AWS Graviton2
+ n1sdp: Arm Neoverse N1SDP
+ octeontx2: Marvell OCTEON TX2
+ stingray: Broadcom Stingray
+ thunderx2: Marvell ThunderX2 T99
+ thunderxt88: Marvell ThunderX T88
+
+These SoCs are also used in cross files, e.g.::
+
+ [properties]
+ # Generate binaries that are portable across all Armv8 machines
+ soc = 'generic'
@@ -1,5 +1,7 @@
# Please keep these options sorted alphabetically.
+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.')
option('disable_drivers', type: 'string', value: '',
description: 'Comma-separated list of drivers to explicitly disable.')
option('drivers_install_subdir', type: 'string', value: 'dpdk/pmds-<VERSION>',