From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH] eal: map io resources for non x86 architectures Date: Fri, 18 Dec 2015 12:04:48 +0530 Message-ID: <20151218063444.GA8572@localhost.localdomain> References: <2241331.HNmyzf8foi@xps13> <2979402.yeVYlcCDUH@xps13> <20151218053053.GL29571@yliu-dev.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org To: Yuanhan Liu Return-path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0100.outbound.protection.outlook.com [157.56.111.100]) by dpdk.org (Postfix) with ESMTP id 057758D3A for ; Fri, 18 Dec 2015 07:35:10 +0100 (CET) Content-Disposition: inline In-Reply-To: <20151218053053.GL29571@yliu-dev.sh.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > >