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

[Honnappa Nagarahalli]

<snip>

> On 9/18/20, 12:42 PM, "Vimal Chungath" <vcchunga at amazon.com> wrote:
> 
>     On 9/17/20 9:02 PM, Jerin Jacob wrote:
>     >
>     > On Thu, Sep 17, 2020 at 10:41 PM Honnappa Nagarahalli
>     > <Honnappa.Nagarahalli at 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 native binaries the answer should be either use -march=native or map the
> MIDR to the compiler options. The MIDR defines the core and thus the core
> features and which architecture features the compiler supports. It seems like
The MIDR identifies the core. It does not identify the SoC. We will use the option of taking the target SoC from the user and use a config to get the correct compiler options.

> the only sticking point here is RTE_MAX_MEM_MB and RTE_MAX_LCORE. Is
> the slight increase in memory size by having a reasonable max for the various
> SoCs given a single core MIDR (80 seems to be the high number for N1
> currently), reason to add complexity and require the user to explicitly pass
> the system they're compiling for?
The largest I know is 128 cores [1]. But, the SoCs could have as little as 4 cores. The new method provides complete flexibility in controlling more parameters than what can be done currently. IMO, the solution is not complex and is inline with the way the make build system works currently.

[1] https://www.hpcwire.com/off-the-wire/ampere-announces-altra-max-arm-processor-with-128-cores/

> 
> 
> Ali
> 
>