On Tue, Feb 06, 2018 at 11:32:59AM +0530, Pavan Nikhilesh wrote: > 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>
Applied to dpdk-next-build Thanks, /Bruce
