DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	bruce.richardson@intel.com, bluca@debian.org,
	harry.van.haaren@intel.com, herbert.guan@arm.com
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] build: add support for detecting march on ARM
Date: Mon, 8 Jan 2018 16:42:36 +0530	[thread overview]
Message-ID: <20180108111235.xzrirvnwmp6jzfma@Pavan-LT> (raw)
In-Reply-To: <20180108081305.GA14975@jerin>

On Mon, Jan 08, 2018 at 01:43:07PM +0530, Jerin Jacob wrote:
> -----Original Message-----
> > Date: Sat, 30 Dec 2017 22:07:54 +0530
> > From: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > To: bruce.richardson@intel.com, bluca@debian.org,
> >  harry.van.haaren@intel.com, jerin.jacob@caviumnetworks.com
> > Cc: dev@dpdk.org, Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > Subject: [dpdk-dev] [PATCH] build: add support for detecting march on ARM
> > X-Mailer: git-send-email 2.14.1
> >
> > Added support for detecting march and mcpu by reading midr_el1 register.
> > The implementer, primary part number values read can be used to figure
> > out the underlying arm cpu.
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > ---

<snip>

> > +cmd = run_command(detect_vendor.path())
> > +if cmd.returncode() != 0
> > +	message('Unable to read midr_el1')
>
> Instead of this "unable to read midr_el1", We could fallback to
> "message('Implementer : Generic arm64')" message
>
> Some thoughts,
> 1) From the Linux documentation[1] this sysfs entries are available
> from the kernels > June 2016
>
> [1]
> What:		/sys/devices/system/cpu/cpuX/regs/
> 		/sys/devices/system/cpu/cpuX/regs/identification/
> 		/sys/devices/system/cpu/cpuX/regs/identification/midr_el1
> 		/sys/devices/system/cpu/cpuX/regs/identification/revidr_el1
> Date: 		June 2016
> Contact:      	Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
> Description:   	AArch64 CPU registers 'identification' directory exposes the CPU ID registers or
>                 identifying model and revision of the CPU.
>
> 2) This scheme is not available in Freebsd.
> 3) I guess, we anyway need a meta file to store this information for cross compilation case.
>
> If so,
> 1) Can we introduce something similar to T= for cross compilation case and
> use the same scheme to override for native compilation flags if required.
> 2) If above scheme is not chosen and
> a) if /sys/devices/system/cpu/cpuX/regs/identification/midr_el1 avilable then derive
> machine_arg based on that
> b) if /sys/devices/system/cpu/cpuX/regs/identification/midr_el1 not available then fallback to generic arm64 compilation.
>
> Thoughts?
>

[1&2] Agreed, when midr_el1 file is unavailable should continue with generic arm32/64.
This would cover freebsd too and if we need we can use the meta stored in cross
compilation case for native compilation.

It would be good if we start agreeing in directory structure where cross-compile
meta files are stored so that we can start adding and experiment with them.

The meta files would have info as mentioned in
http://dpdk.org/dev/patchwork/patch/32410/

Thanks,
Pavan.

>
> > +else
> > +	cmd_output = cmd.stdout().strip().split(' ')
> > +	message('midr_el1 output: \n' + 'Implementor ' + cmd_output[0] +
> > +			' Variant ' + cmd_output[1] + ' Architecture ' +
> > +			cmd_output[2] + ' Primary Part number ' + cmd_output[3]
> > +			+ ' Revision ' + cmd_output[4])
> > +	if cmd_output[0] == '0x43'
> > +		message('Implementor : Cavium')
> > +		dpdk_conf.set('RTE_MACHINE', 'thunderx')
> > +		machine_arg = []
> > +	        machine_arg += '-march=' + 'armv8-a+crc+crypto'
> > +		machine_arg += '-mcpu=' + 'thunderx'
>
> 1) Instead of changing the code for each Vendors and the multiple
> variants, Can we put some framework to just define this information some
> where?
> 2) Please add the another mcpu variables for the Cavium produces like
> 81xx and 83xx etc
>
>
> > +	endif
> > +endif
> > diff --git a/config/meson.build b/config/meson.build
> > index 86e978fb1..fe8104676 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -8,7 +8,8 @@ else
> >  	machine = get_option('machine')
> >  endif
> >  dpdk_conf.set('RTE_MACHINE', machine)
> > -machine_arg = '-march=' + machine
> > +machine_arg = []
> > +machine_arg += '-march=' + machine
> >
> >  # use pthreads
> >  add_project_link_arguments('-pthread', language: 'c')
> > diff --git a/drivers/meson.build b/drivers/meson.build
> > index 9b5039847..f5009aa2e 100644
> > --- a/drivers/meson.build
> > +++ b/drivers/meson.build
> > @@ -22,7 +22,7 @@ foreach class:driver_classes
> >  		version = 1
> >  		sources = []
> >  		objs = []
> > -		cflags = [machine_arg]
> > +		cflags = machine_arg
> >  		includes = [include_directories(drv_path)]
> >  		# set up internal deps. Drivers can append/override as necessary
> >  		deps = std_deps
> > diff --git a/examples/meson.build b/examples/meson.build
> > index 0abed7169..88df650cf 100644
> > --- a/examples/meson.build
> > +++ b/examples/meson.build
> > @@ -9,7 +9,7 @@ endif
> >  foreach example: get_option('examples').split(',')
> >  	name = example
> >  	sources = []
> > -	cflags = [machine_arg]
> > +	cflags = machine_arg
> >  	ext_deps = []
> >  	includes = [include_directories(example)]
> >  	deps = ['eal', 'mempool', 'net', 'mbuf', 'ethdev', 'cmdline']
> > diff --git a/lib/meson.build b/lib/meson.build
> > index 0c94d74b9..3c98efa70 100644
> > --- a/lib/meson.build
> > +++ b/lib/meson.build
> > @@ -31,7 +31,7 @@ foreach l:libraries
> >  	sources = []
> >  	headers = []
> >  	includes = []
> > -	cflags = [machine_arg]
> > +	cflags = machine_arg
> >  	objs = [] # other object files to link against, used e.g. for
> >  	          # instruction-set optimized versions of code
> >
> > diff --git a/meson.build b/meson.build
> > index 3dce8579e..493bcc313 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -66,5 +66,5 @@ pkg.generate(name: meson.project_name(),
> >  			['-Wl,-Bdynamic'] + dpdk_extra_ldflags,
> >  	description: 'The Data Plane Development Kit (DPDK)',
> >  	subdirs: [get_option('include_subdir_arch'), '.'],
> > -	extra_cflags: ['-include "rte_config.h"', machine_arg]
> > +	extra_cflags: ['-include "rte_config.h"'] + machine_arg
> >  )
> > --
> > 2.15.1
> >

  reply	other threads:[~2018-01-08 11:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-30 16:37 Pavan Nikhilesh
2018-01-08  8:13 ` Jerin Jacob
2018-01-08 11:12   ` Pavan Nikhilesh [this message]
2018-01-08 17:05 ` Bruce Richardson
2018-01-10  8:21   ` Pavan Nikhilesh
2018-01-10 10:12     ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180108111235.xzrirvnwmp6jzfma@Pavan-LT \
    --to=pbhagavatula@caviumnetworks.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=herbert.guan@arm.com \
    --cc=jerin.jacob@caviumnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).