From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id A86CF8D8F for ; Thu, 17 Dec 2015 11:34:56 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id p187so16823489wmp.0 for ; Thu, 17 Dec 2015 02:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=z9jyTbsipXjQkhMicSCJ2lcYFRzn1hf/+XET6TAs+FY=; b=WiaZnq9I6Ynbrf0iLJCWwc5ZXi7A7NB0Y8ha2yuh/Wak06R1j7SQyZS68KFKhCVzhO 6coFgobjwYIc29YeaNMorQzDfLFd2vYtfm5uImztt1XDrpri7ul2cXoy5nSsevchwCfV cMhByHOb+DFWuTROmN458a4FVYu2bur08kdOFiG5PRH5BxD1xagpw1UQgFckiiQrXB9F MDnCH/CSYqyR4ECEf5zkU2h0a3NPg79jgsknYVY+bf34PgHCHe83lXbViVqyRTHAh4HZ RISTidABe65CDKSOCCkG0G2k+Lg7N7Y1oMEQDQKX/rbL6vrf5nm87+GAxipVcPauY1fh M29Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=z9jyTbsipXjQkhMicSCJ2lcYFRzn1hf/+XET6TAs+FY=; b=GLYPykq0xkiNxdLnaSIf6I5L3PLj/aT5ITmZyEPTdMwXDFJb6m/6H+n1iC57QZ0CTY Kbk5f1yA1opWpTGg20zRe0vzv9f03EBUrSrvTsmTn+QnOfLiag3Gdjy6QYimGiKSiYGm uabiSL5KJnuv+qSWCpm3WYNqkqFO/U7soYTT7w6Sa61zfi4VzQT/QFQHgzEQ7pIAwE/P J0Vd+SHlWJqggbxFYH4BCTq+I4sE9YqoGIoIGcr+WraFSdnBrfNKNHguU7xcjKEy6cYk S4SSsdGNnsio80teVuR0T6AJ+uJLghNh0gRaYMUH5Rio4/qIqzjbEtl1k2549gJ22fAV Pn2g== X-Gm-Message-State: ALoCoQn4dUzeQq94arAfMyT/5biY1BqIYOIxTEesFgvtXYgt2saKLj+tsla4/keegAJB34aDX8MZn1f3jE2hYJaMYOPea6hFvA== X-Received: by 10.28.50.70 with SMTP id y67mr3212457wmy.91.1450348496389; Thu, 17 Dec 2015 02:34:56 -0800 (PST) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id z13sm9813042wjr.47.2015.12.17.02.34.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 02:34:55 -0800 (PST) From: Thomas Monjalon To: Santosh Shukla Date: Thu, 17 Dec 2015 11:33:39 +0100 Message-ID: <2979402.yeVYlcCDUH@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <2241331.HNmyzf8foi@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Thu, 17 Dec 2015 10:34:56 -0000 2015-12-17 15:51, Santosh Shukla: > On Thu, Dec 17, 2015 at 3:44 PM, Thomas Monjalon > wrote: > > Hi, > > > > 2015-12-17 15:37, Santosh Shukla: > >> On Thu, Dec 17, 2015 at 3:32 PM, Santosh Shukla wrote: > >> > On Thu, Dec 17, 2015 at 3:31 PM, Santosh Shukla wrote: > >> >> On Thu, Dec 17, 2015 at 3:08 PM, Yuanhan Liu > >> >> wrote: > >> >>> On Wed, Dec 16, 2015 at 07:21:55PM +0530, Santosh Shukla wrote: > >> >>>> On Wed, Dec 16, 2015 at 6:18 PM, Yuanhan Liu > >> >>>> wrote: > >> >>>> > On Wed, Dec 16, 2015 at 01:31:04PM +0100, David Marchand wrote: > >> >>>> >> x86 requires a special set of instructions to access ioports, but other > >> >>>> >> architectures let you remap io resources. > >> >>>> >> So let eal remap io resources by accepting IORESOURCE_IO flag for > >> >>>> >> architectures other than x86. > >> >>>> > > >> >>>> > One question: this patch could be a replacement of the igbuio_iomap patch > >> >>>> > from Santosh? If so, I like it: It's more elegant. > >> >>>> > > >> >>>> > --yliu > >> >>>> > > >> >>>> > >> >>>> I did tried similar in past but not in parse_sysfs (such that > >> >>>> mem.resource_addr to accept IO_RESOURCE_IO types) and observed that > >> >>>> pci_map_resource not able to map address hence segfault at tespmd > >> >>>> initialization. > >> >>>> > >> >>>> i was getting these: > >> >>>> EAL: pci_map_resource(): cannot mmap(19, 0x7fa5c00000, 0x20, 0x0): > >> >>>> Invalid argument (0xffffffffffffffff) > >> >>> > >> >>> That's because ARM (at least the kernel) doesn't allow an IO map: > >> >>> > >> >>> arch/arm/kernel/bios32.c > >> >>> ------------------------ > >> >>> 618 int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma, > >> >>> 619 enum pci_mmap_state mmap_state, int write_combine) > >> >>> 620 { > >> >>> 621 if (mmap_state == pci_mmap_io) > >> >>> 622 return -EINVAL; > >> >>> > >> >>> And with a quick glimpse of powerpc, I see no such limitation. Hence, > >> >>> this peice of code may work only on Powerpc platform (and maybe a few > >> >>> others we don't care). > >> >>> > >> >>> So, apparently, this will not work for ARM. > >> >>> > >> >> > >> >> Right and I did shared detailed explanation on why it wont work on > >> >> this link [1], infact this patch shouldn;t work for mips too. > >> >> > >> >> As I mentioned earlier I did tried similar approach and so to get > >> >> everything working like iomem is currently in dpdk; we need to add > >> >> something like pci_remap_iospace --> ioremap_page_range() but this api > >> >> not really pci_mmap_page_range types. user need to write more code on > >> >> top so to use this api efficiently, also this api looks like meant to > >> >> use by arch file only in kernel space. > >> >> > >> >> > >> > missed link; > >> > > >> > [1] http://dpdk.org/dev/patchwork/patch/9365/ > >> > > >> > >> 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. > > 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. Then we can try a pci_mmap solution or, as you suggest, an interface in drivers/char/mem.c