Re: [PATCH] eal: map io resources for non x86 architectures

[Yuanhan Liu <yuanhan.liu@linux.intel.com>]

On Thu, Dec 17, 2015 at 04:52:00PM +0530, Santosh Shukla wrote:
> >> >> IMO, it is worth keeping one special device file who could work across
> >> >> archs like arm/arm64/powerpc and others, who could map iopci bar to
> >> >> dpdk user-space. also this approach has no kernel version dependency
> >> >> too. BTW; I did mentioned in second approach in to add /dev/ioport
> >> >> interface in drivers/char/mem.c which could read more than byte in one
> >> >> single operation, but that has kernel dependency. However that
> >> >> approach too is arch agnostic.
> >> >
> >> > Your first approach use an out-of-tree kernel module (igb_uio), so we cannot
> >> > really say there is no kernel dependency.
> >>
> >> Agree but I mentioned kernel __version__ dependency.
> >
> > Yes you did.
> > One of the main issue with out-of-tree kernel modules is the version
> > dependency. Probably that igb_uio from DPDK 2.3 will not compile with
> > the kernel 5.0.
> >
> 
> don't know kernel 5.0 feature list so I guess your may be right. is
> uio obsoleted for 5.0 kernel?

Nope, Thomas meant to say that we should keep the old DPDK will work
with newer kernel, not just the newest DPDK work on newest linux kernel
only. The out-of-tree kernel makes no garantee on that.

> >> > We should try to remove the need for any out-of-tree kernel module.
> >> > That's why the Linux upstream approach is a better solution.
> >>
> >> IIUC, your suggesting archs like arm/arm64 to support io_mappe_io in
> >> pci_mmap_page_range()?
> >
> > I don't know what is the best solution in the kernel.
> > First we need to be sure that there is absolutely no solution without
> > kernel changes.
> 
> I guess we have done enough evaluation / investigation that suggest -
> so to map iopci region to userspace in arch agnostic-way -
> 
> # either we need to modify kernel
>                - Make sure all the non-x86 arch to support mapping for
> iopci region (i.e. pci_mmap_page_range). I don;t think its a correct
> approach though.
>             or
>                - include /dev/ioport char-mem device file who could do
> more than byte operation, Note that this implementation does not exist
> in kernel.  I could send an RFC to lkml.

Maybe you could propose the two to lkml, to get some feedbacks from
those kernel/ARM gurus? Please cc me if you do so.

	--yliu
> 
> OR keep device file in user space (current approach)
> Right now Virtio-for-arm patches are blocked on this, let me know if
> someone has better approach/thought in mind.
> 
> Thanks.
> 
> > Then we can try a pci_mmap solution or, as you suggest, an interface in
> > drivers/char/mem.c
> >