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

Ali Saidi alisaidi+dpdk at amazon.com
Fri Sep 25 00:08:24 CEST 2020


<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. 
 
<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. 



More information about the dev mailing list