From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Jianbo Liu <jianbo.liu@linaro.org>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>, <dev@dpdk.org>
Subject: Re: [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a
Date: Mon, 9 May 2016 21:47:41 +0530 [thread overview]
Message-ID: <20160509161740.GA1853@localhost.localdomain> (raw)
In-Reply-To: <CAP4Qi3-kkrkS9zusN5hse79bprfzjbiJ=moNUxRtpL0akttdGQ@mail.gmail.com>
On Mon, May 09, 2016 at 11:22:15PM +0800, Jianbo Liu wrote:
> On 9 May 2016 at 20:11, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > On Mon, May 09, 2016 at 07:02:36PM +0800, Jianbo Liu wrote:
> >> On 9 May 2016 at 17:06, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> >> > On Mon, May 09, 2016 at 07:18:22PM +0530, Hemant Agrawal wrote:
> >> >> This patch introduces dpaa2 machine target to address difference
> >> >> in cpu parameter, number of core to 8 and no numa support
> >> >> w.r.t default armv8-a machine
> >> >>
> >> >> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> >> >> ---
Snip
> >> >> +#
> >> >> +# Compile Environment Abstraction Layer
> >> >> +#
> >> >> +CONFIG_RTE_MAX_LCORE=8
> >> >> +CONFIG_RTE_MAX_NUMA_NODES=1
> >> >> +CONFIG_RTE_EAL_IGB_UIO=n
> >> >
> >> > I think it makes sense to move this option to generic arm64 config
> >> > as upstream arm64 kernel does not have support for sysfs based PCI mmap
> >> > resource file,(/sys/bus/pci/devices/B:D:F/resource[_wc]X) need for
> >> > CONFIG_RTE_EAL_IGB_UIO to work) and use VFIO for all cases.
> >> >
> >> > Any objections?
> >> >
> >> Is there any conflict to keep both?
> >
> > I would like to avoid the case like below in dpdk.org ml.
> > http://dpdk.org/ml/archives/dev/2016-January/031313.html
> >
> So no conflict to enable both.
IMO, Conflict part comes secondary, It does not even work with upstream kernel.
Why keep the broken configuration? Two main reasons I think it makes
sense to disable
- It is broken, I don't think arm64 kernel developers likes non VFIO approach
now. So mostly likely it will be broken
- Trying to avoid out of tree patches wherever is possible as
distribution folks like to work with upstream version.
> I'd rather keep as it is for armv8a defconfig, becasue it's the base,
> any change may affect existing user.
IMO, It makes sense to disable at armv8a defconfig otherwise all armv8
variants need add CONFIG_RTE_EAL_IGB_UIO=n in all the configs and its
arch specific issue.
next prev parent reply other threads:[~2016-05-09 16:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 13:48 [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a Hemant Agrawal
2016-05-09 8:20 ` Santosh Shukla
2016-05-09 8:39 ` Thomas Monjalon
2016-05-09 9:09 ` Hemant Agrawal
2016-05-09 9:06 ` Jerin Jacob
2016-05-09 9:13 ` Santosh Shukla
2016-05-09 9:16 ` Hemant Agrawal
2016-05-09 11:02 ` Jianbo Liu
2016-05-09 12:11 ` Jerin Jacob
2016-05-09 15:22 ` Jianbo Liu
2016-05-09 16:17 ` Jerin Jacob [this message]
2016-05-10 2:10 ` Jianbo Liu
2016-05-10 5:26 ` Jerin Jacob
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=20160509161740.GA1853@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=jianbo.liu@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.