On 10 May 2016 at 00:17, Jerin Jacob <jerin.jacob at caviumnetworks.com> wrote: > 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 I don't think DPDK user is kernel developer in most cases. They maybe like the traditional way.
> 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. Agree. But there is possible that people/company maintain their own kernel tree. > >> 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. We don't have to do that. You didn't explictly disable this config in your current defconfig_arm64-thunderx-linuxapp-gcc, but you know which module to bind.
