[dpdk-dev] [PATCH 1/2] config: add Graviton2(arm64) meson configuration

[Honnappa Nagarahalli]

<snip>

> > >
> > > On 9/11/20 8:23 PM, Honnappa Nagarahalli wrote:
> > > >
> > > > +Jerin, Hemant, Dharmik
> > > >
> > > > <snip>
> > > > Hi Vimal,
> > > >         Few comments inline.
> > > >
> > > >>
> > > >> Add meson build configuration for Graviton2 platform with 64-bit
> > > >> ARM Neoverse N1 cores. This patch makes the following changes to
> > > >> generic Neoverse N1 config:
> > > >>
> > > >> 1. increase lcore limit to 64
> > > >> 2. increase memory support to 1TB
> > > > There will be multiple SoCs with N1 cores. All of them will have
> > > > the same
> > > implementor ID and part number. But, they will have different values
> > > for these configurable parameters.
> > > > IMO, from usage perspective, we have 2 cases:
> > > > 1) Ability to build a portable binary that can run on multiple Arm
> > > > SoCs (for ex: BlueField, thunderx1, thunderx2, N1SDP, Graviton2
> > > > etc)
> > > > 2) Ability to build a binary which would run only on a SoC it was
> > > > compiled
> > > for and provide the most optimized binary for that SoC. But, this
> > > may not be portable.
> > > >
> > > > For 1) we have default march.
> > > >
> > > > For 2) we do not have the capability today in meson build (at
> > > > least, this is
> > > my understanding, please correct me if I am wrong). In this case,
> > > the user knows the target platform for compilation. IMO, we should
> > > add the capability to take the target platform as an input from the
> > > user (similar to the make build system) and Graviton2 can be one such
> target platform.
> > >
> > > My intention was to have parameters that work for both N1SDP and
> > > Graviton2 rather than 2). Does the change to RTE_MAX_LCORE and
> > > RTE_MAX_MEM_MB make them incompatible with N1SDP?
> > They are not optimal for N1SDP. In the future these parameters might have
> to be changed. For ex: if there a N1 based SoC with more than 64 CPU cores.
> 
> 
> Sorry for the late reply.
> 
> Looking at the Bluefield, Graviton2, and upcoming SoCs based on ARM IP, It is
> very clear that MIDR value can not be changed by the silicon vendors.
> So our existing build scheme of using the MIDR  value-based probe does not
> work anymore with ARM IP.
> So IMO, We need to change our build scheme. i.e
> 
> 1) For native build just use -march=native
I think we do not need the native build. With the native build, it is not possible to identify the SoC and use the correct configuration parameters.

> 2) For cross-build, explicitly, mention the target to pick the configuration
> values instead of probing the MIDR value-based scheme.
Agree

> 
> If we agree, Any volunteers for the update to new scheme?
Arm will work on this.

> 
> >
> > >
> > > I'm not sure if taking target platform from user is the best option here.
> > > Would this be specific to N1 since other platforms like thunderx
> > > differentiate the flags with part number?
> > This issue is specific to Arm CPU cores in general. So, it applies to N1 too.
> >
> > >
> > > >
> > > >> 3. remove +crc from -march as that is default when setting
> > > >> armv8.2
> > > >>
> > > >> For more information about Graviton2 platform, refer to:
> > > >> https://aws.amazon.com/ec2/graviton/
> > > >>
> > > >> Signed-off-by: Vimal Chungath <vcchunga at amazon.com>
> > > >> ---
> > > >>  config/arm/arm64_graviton2_linux_gcc | 17 +++++++++++++++++
> > > >>  config/arm/meson.build               | 12 +++++++++++-
> > > >>  2 files changed, 28 insertions(+), 1 deletion(-)  create mode
> > > >> 100644 config/arm/arm64_graviton2_linux_gcc
> > > >>
> > > >> diff --git a/config/arm/arm64_graviton2_linux_gcc
> > > >> b/config/arm/arm64_graviton2_linux_gcc
> > > >> new file mode 100644
> > > >> index 000000000..022e06303
> > > >> --- /dev/null
> > > >> +++ b/config/arm/arm64_graviton2_linux_gcc
> > > >> @@ -0,0 +1,17 @@
> > > >> +[binaries]
> > > >> +c = 'aarch64-linux-gnu-gcc'
> > > >> +cpp = 'aarch64-linux-gnu-cpp'
> > > >> +ar = 'aarch64-linux-gnu-gcc-ar'
> > > >> +strip = 'aarch64-linux-gnu-strip'
> > > >> +pkgconfig = 'aarch64-linux-gnu-pkg-config'
> > > >> +pcap-config = ''
> > > >> +
> > > >> +[host_machine]
> > > >> +system = 'linux'
> > > >> +cpu_family = 'aarch64'
> > > >> +cpu = 'armv8-a'
> > > >> +endian = 'little'
> > > >> +
> > > >> +[properties]
> > > >> +implementor_id = '0x41'
> > > >> +implementor_pn = '0xd0c'
> > > >> diff --git a/config/arm/meson.build b/config/arm/meson.build
> > > >> index 8728051d5..64e277ebc 100644
> > > >> --- a/config/arm/meson.build
> > > >> +++ b/config/arm/meson.build
> > > >> @@ -86,6 +86,16 @@ flags_octeontx2_extra = [
> > > >>       ['RTE_ARM_FEATURE_ATOMICS', true],
> > > >>       ['RTE_EAL_IGB_UIO', false],
> > > >>       ['RTE_USE_C11_MEM_MODEL', true]]
> > > >> +flags_n1generic_extra = [
> > > >> +     ['RTE_MACHINE', '"neoverse-n1"'],
> > > >> +     ['RTE_MAX_LCORE', 64],
> > > >> +     ['RTE_CACHE_LINE_SIZE', 64],
> > > >> +     ['RTE_ARM_FEATURE_ATOMICS', true],
> > > >> +     ['RTE_USE_C11_MEM_MODEL', true],
> > > >> +     ['RTE_MAX_MEM_MB', 1048576],
> > > >> +     ['RTE_MAX_NUMA_NODES', 1],
> > > >> +     ['RTE_EAL_NUMA_AWARE_HUGEPAGES', false],
> > > >> +     ['RTE_LIBRTE_VHOST_NUMA', false]]
> > > >>
> > > >>  machine_args_generic = [
> > > >>       ['default', ['-march=armv8-a+crc']], @@ -97,7 +107,7 @@
> > > >> machine_args_generic = [
> > > >>       ['0xd09', ['-mcpu=cortex-a73']],
> > > >>       ['0xd0a', ['-mcpu=cortex-a75']],
> > > >>       ['0xd0b', ['-mcpu=cortex-a76']],
> > > >> -     ['0xd0c', ['-march=armv8.2-a+crc+crypto', '-mcpu=neoverse-n1'],
> > > >> flags_n1sdp_extra]]
> > > >> +     ['0xd0c', ['-march=armv8.2-a+crypto', '-mcpu=neoverse-n1'],
> > > >> +flags_n1generic_extra]]
> > > >>
> > > >>  machine_args_cavium = [
> > > >>       ['default',
> > > >> ['-march=armv8-a+crc+crypto','-mcpu=thunderx']],
> > > >> --
> > > >> 2.16.6
> > > >
> >