From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by dpdk.org (Postfix) with ESMTP id D52EAFE5 for ; Thu, 17 Dec 2015 11:07:23 +0100 (CET) Received: by mail-pa0-f51.google.com with SMTP id ur14so39910406pab.0 for ; Thu, 17 Dec 2015 02:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=le3r6x979om6pCS8n5tS1s2xM+IPRzjyipghfpg2M5k=; b=OE/98+6OnStgTC/Gfol5y53Msw1NAWC14qD2YLAmNtNZ85PZ6B7qPND6mjdEzoQ4Er NRqKhAVfIPKzqeUUXgU0dH48pHeJ2FaY4dvaUQYoUdvBP92TCY2JSR9nxrrIgfn5jYzt W7eRywPlGAj83pYKZ/Y1KgGj4ifKuBdhV1GwRY4BJr3LlVtGI7mgc7FNT3Y/fbORZJN+ qlTdnMBk9ji/bYPXkUhOMxff7+8oPmpj8S9nrYYQqlwXuH0S1ZNaPuDYBvrGWUSfSYvv JPRfIPZ/y2ZYZ1wJTqPy9ccMxzHnUtlb7hXM+NdNoj91GaMoPJsfXyb41jaQG8+DJ1pO ygVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=le3r6x979om6pCS8n5tS1s2xM+IPRzjyipghfpg2M5k=; b=O1pP53c/GzwWJBjbXckh0gBuZkvaWiDSBcsgoxQ6RuDsCeum93C3H2qMEsExkIIuIy ZiuWaVU2R2MPhG4WKWq4QfnWI9zZNVRrp0sPEjuo+1IrC2q/p9F4AECIIIy+asEgCUCp Qd+rR53qLY5wt8UZ+Hq4KD5XYrmiQ3rbeOtovxj55FHR0GYvDT1Tcre+Dm3MqUD5HuYu sDjiKVwwAH3Ajv7aJIGk0sPRTR8YL/GWfApMMu15uQJOCFhfqYvP4ky4VnmtQEbcgTRs G/TLiy1Pwpk0cJ4yQIshK37ddPLM+WN7eMglaKMnEdIxV8mbtduzHefxLbaToiAcnl0q nAng== X-Gm-Message-State: ALoCoQlsNAHFuOsLI1PLdY2c5LgXIsDE0RBr3kFuoQcxd950BxzrNxckdhE/ZKLDJt2IgO6cP4t6qoynkTyqKF/IU/0txYPeqfXLSZ1dVlwKzCEOaTkotfs= MIME-Version: 1.0 X-Received: by 10.66.182.202 with SMTP id eg10mr70858792pac.50.1450346843105; Thu, 17 Dec 2015 02:07:23 -0800 (PST) Received: by 10.66.13.233 with HTTP; Thu, 17 Dec 2015 02:07:23 -0800 (PST) In-Reply-To: References: <1450269064-23608-1-git-send-email-david.marchand@6wind.com> <20151216124834.GR29571@yliu-dev.sh.intel.com> <20151217093847.GB29571@yliu-dev.sh.intel.com> Date: Thu, 17 Dec 2015 15:37:23 +0530 Message-ID: From: Santosh Shukla To: Yuanhan Liu Content-Type: text/plain; charset=UTF-8 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:07:24 -0000 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. Let me know! >>> --yliu