[dpdk-dev] [PATCH v1] build: add more implementers' IDs and PNs for Arm platforms

[Pavan Nikhilesh]

On Tue, Feb 06, 2018 at 05:51:29AM +0000, Herbert Guan wrote:
> Hi Pavan,
>
> > -----Original Message-----
> > From: Pavan Nikhilesh [mailto:pbhagavatula at caviumnetworks.com]
> > Sent: Monday, February 5, 2018 17:23
> > To: Herbert Guan <Herbert.Guan at arm.com>;
> > jerin.jacob at caviumnetworks.com; hemant.agrawal at nxp.com;
> > bruce.richardson at intel.com; harry.van.haaren at intel.com
> > Cc: dev at dpdk.org
> > Subject: Re: [PATCH v1] build: add more implementers' IDs and PNs for Arm
> > platforms
> >
> > Hi Herbert,
> >
> > On Wed, Jan 31, 2018 at 03:39:19PM +0800, Herbert Guan wrote:
> > > 1) Add native PN option '-march=native' to allow automatic detection.
> > >    Set 'arm_force_native_march' to 'true' in config/arm/meson.build
> > >    to use native PN option.
> > > 2) Add implementer_pn option for part num selection in cross compile
> > > 3) Add known Arm cortex PN support
> > > 4) Add known implementers' IDs (use generic flags/archs by default)
> > > 5) Sync build options with config/common_armv8a_linuxapp
> > >
> > > Signed-off-by: Herbert Guan <herbert.guan at arm.com>
> > > ---
> > <snip>
> > > +
> > >  machine_args_generic = [
> > > -['default', ['-march=armv8-a+crc+crypto']]]
> > > +['default', ['-march=armv8-a']],
> >
> > Any specific reason for this change?
> > Traditional make uses
> > MACHINE_CFLAGS += -march=armv8-a+crc+crypto
> > found at mk/machine/armv8a/rte.vars.mk
> >
>
> Both CRC and Crypto are optional instructions / extensions on Arm v8 CPUs.
> When making a general build (e.g. a release build for distribution), we need to
> ensure all targeted CPUs (all Armv8 for example) can support this compiled
> binary.  Defaulting crc and crypto to be supported may introduce risks.  For a certain
> CPU/platform, '-march=native' may be used, or CPU implementers can further
> Customize these args in this file.
> On the other hand, the rte_cpuflags.c is already supporting run-time CPU flags
> (instruction sets) detection and this is the preferred approach.
>

Makes sense, As I mentioned in the previous mail some vendors use 64B
cacheline instead of 128B as of now I dont see a way to detect that. The vendor
needs to modify implementor Id specific flags flags_<vendor>.
With that in mind.

Acked-by: Pavan Nikhilesh <pbhagavatula at caviumnetworks.com>