On Thu, May 12, 2016 at 10:01:05AM +0800, Jianbo Liu wrote: > On 12 May 2016 at 02:25, Stephen Hemminger <stephen at networkplumber.org> > wrote: > > On Wed, 11 May 2016 22:32:16 +0530 > > Jerin Jacob <jerin.jacob at caviumnetworks.com> wrote: > > > >> On Wed, May 11, 2016 at 08:22:59AM -0700, Stephen Hemminger wrote: > >> > On Wed, 11 May 2016 19:17:58 +0530 > >> > Hemant Agrawal <hemant.agrawal at nxp.com> wrote: > >> > > >> > > IGB_UIO not supported for arm64 arch in kernel so disable. > >> > > > >> > > Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com> > >> > > Reviewed-by: Santosh Shukla <santosh.shukla at caviumnetworks.com> > >> > > >> > Really, I have use IGB_UIO on ARM64 > >> > >> May I know what is the technical use case for igb_uio on arm64 > >> which cannot be addressed through vfio or vfioionommu. > > > > I was running on older kernel which did not support vfioionommu mode. > > As I said, most of DPDK developers are not kernel developers. They may > have their own kernel tree, and couldn't like to upgrade to latest > kernel. > They can choose to use or not use igb_uio when binding the driver. But > blindly disabling it in the base config seems unreasonable.
if user keeping his own kernel so they could also keep IGB_UIO=y in their local dpdk tree. Why are you imposing user-x custome depedancy on upstream dpdk base config. Is it not enough for explanation that - Base config ie.. armv8 doesn;t support pci mmap, so igb_uio is n/a. New user wont able to build/run dpdk/arm64 in igb_uio-way, He'll prefer to use upstream stuff. I think, you are not making sense.
