From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by dpdk.org (Postfix) with ESMTP id 6F1C868A5 for ; Thu, 17 Dec 2015 11:21:21 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id q3so20126831pav.3 for ; Thu, 17 Dec 2015 02:21:21 -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=T88YUfY6bwAe0hUM4F6HpliA+2j8/5132tvZS/nNfWA=; b=fQPKzb+0bj4Fsawu/ocfyGUHwSp/hNa38btRxUNfl6RhRnSDV9wr5AaunphtvqGiHR 7MWnElKczyeBprTr5rLcAfcH5fqBKlgxy5jOUE4CESNRse6gH/JpwILZlwiq7jEIb3su uSlKq1lQw8N3wHyjLXJ18ce9ob96fNpDt5Fu16ffM7rol73hD0M2BK3wke/RprTLHkTN dxaCEyIiRjlfTRAxA1PdrieFmZntZPFwCQk1auOjsBaYlTWOaE8LaBcbOziGP8UgkIAF t+OAYRsYlCX7fZK97h1KIaYKSdwJWGAyrJXT0wjuX/MDMpxBpEuJZ6M83sg67pO0FuYK 5TFQ== 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=T88YUfY6bwAe0hUM4F6HpliA+2j8/5132tvZS/nNfWA=; b=V3MxPT5jgSdbYUJBj6vIUrkpHd18hiVitJZdhO0iBPnk4tEgH6fsaXhydhsJGTUIog +soeT4zK7pm1+53xEu5GmljK58VCVajTl+o+nIevfCR8ajfuAsqXjadOd2KilfXa7Rw8 u+nrdtoiOqBhkklkBYv3LuQZ9jb2/kXhnPAVA2BlN4C23HB9L0eLWZf3ECd3m3JE7sT/ QqMyus2iq10QdesTx+DFkrfLuwR9jbjipuM/LqQTdAeenOuvj/ufBbGXTdIxNX9nFxSu uLFiCm+lva6x0plIV5+xzN9FOATERrgPFz9FuyyvjWgBkyDRdxL/Jmbt0FIZSiRzS4lk BXwg== X-Gm-Message-State: ALoCoQlxWJ4yybF0fYzNK0sPg0p1GoeW+vFBSiarDEi8KSXu9HqD5eVIkZFVjvHvV+gxyPYVb9aJmhgGdkjZUeDZcCEELtBGp9QtOVTvADbDwsNFl+PpJEE= MIME-Version: 1.0 X-Received: by 10.66.140.79 with SMTP id re15mr68926162pab.127.1450347680764; Thu, 17 Dec 2015 02:21:20 -0800 (PST) Received: by 10.66.13.233 with HTTP; Thu, 17 Dec 2015 02:21:20 -0800 (PST) In-Reply-To: <2241331.HNmyzf8foi@xps13> References: <2241331.HNmyzf8foi@xps13> Date: Thu, 17 Dec 2015 15:51:20 +0530 Message-ID: From: Santosh Shukla To: Thomas Monjalon 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:21:21 -0000 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. > 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()?