On Tue, Feb 06, 2018 at 05:51:29AM +0000, Herbert Guan wrote: > Hi Pavan, > > > -----Original Message----- > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > Sent: Monday, February 5, 2018 17:23 > > To: Herbert Guan <herbert.g...@arm.com>; > > jerin.ja...@caviumnetworks.com; hemant.agra...@nxp.com; > > bruce.richard...@intel.com; harry.van.haa...@intel.com > > Cc: dev@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.g...@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 <pbhagavat...@caviumnetworks.com>