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

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

On Fri, Dec 18, 2015 at 01:30:53PM +0800, Yuanhan Liu wrote:
> 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.

IMO, We need to support DPDK-ARM for the old kernels also. If there is no means
to expose iomap region to userspace in the existing kernel then we add that
support through out-of-tree driver like igb_uio and when make become part of
the kernel then we can turn off of the out-of-tree driver based
on the kernel major and minor version numbers.

Jerin


>
> 	--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
> > >