From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 34BD28D8C for ; Fri, 18 Dec 2015 06:30:24 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 17 Dec 2015 21:30:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,444,1444719600"; d="scan'208";a="619965603" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 17 Dec 2015 21:30:21 -0800 Date: Fri, 18 Dec 2015 13:30:53 +0800 From: Yuanhan Liu To: Santosh Shukla Message-ID: <20151218053053.GL29571@yliu-dev.sh.intel.com> References: <2241331.HNmyzf8foi@xps13> <2979402.yeVYlcCDUH@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] eal: map io resources for non x86 architectures X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 05:30:24 -0000 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 > >