On Mon, May 09, 2016 at 11:22:15PM +0800, Jianbo Liu wrote: > On 9 May 2016 at 20:11, Jerin Jacob <jerin.jacob at 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 at 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 at 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.
