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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-12-18 12:04, Jerin Jacob:
> 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:
> > > > 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.

Of course, we have to support DPDK for old/current kernels.
But if we continue to implement features in out-of-tree modules without trying
to have a solution with upstream kernel, we are stuck with our legacy forever.
So, as sane policy, we should not accept new changes in our kernel modules
if there is no alternative in Linus' repo.