On Fri, Dec 18, 2015 at 11:00 AM, Yuanhan Liu
<yuanhan.liu at linux.intel.com> 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.
>
The latter one I already shared old lkml thread, Pl. revisit my v1 0/6
patch [1] and in that refer [2].
Josh has already proposed to lkml but for some reason thread didn't
went far. I can restart that discussion giving dpdk use-case as an
example/ requirement.
And for the former one, I'll have to check with linux-arm why iopci
region not mappable. By grepping kernel source all i could see two
commit - latest one is 415ae101 and older one 1da177e. Both has
nothing to explain why
if (mmap_state == pci_mmap_io)
return -EINVAL;
Setting pci io region to -EINVAL, should have fundamental reason for
sure. But we'll have to check, for that I could post as a query rather
a patch to lkml.
Note that dpdk already has out-of-tree implementation for
dom0/xen-case too, it creates special device file which maps pci
resources. so keep one more igb_uio char device so to map iopci region
wont hurt much though!
[1] http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/29531
> --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
>> >
