[dpdk-dev] [RFC PATCH 1/2] build: rework Arm build options

[Honnappa Nagarahalli]

<snip>
> 
> > > > >
> > > > > The current system can identify only the implementer and part
> > > > > number of the arm device we're targeting, which is enough to
> > > > > identify the target
> > > CPU.
> > > > > However, even the full MIDR information is not enough to
> > > > > identify the SoC we're targeting.
> > > > >
> > > > > Expand the "machine" meson variable to allow specifying the
> > > > > target arm
> > > SoC.
> > > > > The SoC identification implies the CPU, so drop the current MIDR
> > > > > based CPU identification in favor of user input, which is the
> > > > > only way to identify the target SoC. This implies that native
> > > > > builds are not possible. Instead do a default (non-optimized,
> > > > > but executable on any
> > > > > aarch64 device) build.
> I don't think this is really what we want. The MIDR identifies the architecture
> features that are supported and we should continue to use that for native
> builds.
> 
> The difference between SoCs really comes down to the RAM and core count,
> which are also detectable or could be specified seperately and defaulted to
> the detected values.
Hi Ali, thank you for the feedback. The differences between SoCs can be more than RAM/core count (ex: NUMA details) and addresses the need to compile only some modules of DPDK.
But, having said that we will keep the native build also. It will continue to function the way it does today. 

> 
> <snip>
> 
> > >
> > > Maybe we can have multiple labels mean the same thing - default,
> > > generic,
> > > armv8 or even generic-armv8 (that's the most descriptive name IMO)
> > > could all mean the generic arm build executable on all aarch64 SoCs.
> > > That many names is probably confusing, but sticking to two (default
> > > and one more) seems feasible.
> > >
> > > What does everyone else think?
> > 'armv8' makes lot more sense to me and it conveys what the build does.
> We can keep 'default' to be backward compatible, we can skip others.
> 
> native build below should just be that. Detect the MIDR, use that for the
> feature flags and use the existing number of CPUs (or a user-specified
> number). I like
> generic-armv8 personally beacuse specifies a generic build that won't be
> optimized.