On 9/17/20 9:02 PM, Jerin Jacob wrote: > > On Thu, Sep 17, 2020 at 10:41 PM Honnappa Nagarahalli > <honnappa.nagaraha...@arm.com> wrote: >> >> <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. > > Ack. Both native and cross can use same config. > >> >>> 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. > > Thanks. We wait for the patch for the rework before applying Graviton patches. > Ack. I will update Graviton patch once we have the meson build changes.
> >> >>> >>>> >>>>> >>>>> 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 <vcchu...@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 >>>>>> >>>>
