From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 25E965A9D for ; Thu, 17 Dec 2015 11:15:55 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id l126so16313668wml.1 for ; Thu, 17 Dec 2015 02:15:55 -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=6/D+DVfOQTR7H9j0ueuOlzIb/LFrkFMKYVq87UH5h+c=; b=FPN7rJbMSlohXqBRocHc4knsp9GEMiuRw3iAte86Dn8mDKq+nimOi9Arvmi+1jZ2MX /L9PocckN04Etiv0oM6jtlz9NJkJUypfHSMBhozu8Mtm0FD2rMjQHJXfc7N3eKZYWBGi hCvhnHcCAJeLwWekgWdMulP8MLgMHKIMtNk6QNEDHFs7utvzTQGPPCtAI4aaEesN5YT1 Gk4kOxCMeZ+XH+/Du+dD77fQuC6fkS1u1ZEKPntHgRHjXmTatOkI6jMb1m9nJiKWvESQ c01YxTlRIkaE/4Avlgw0xEdjePQRcGI5cWk9S2hChdKr6eH3EUDo61vVyzlaniC/gF9m 9Lgg== 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=6/D+DVfOQTR7H9j0ueuOlzIb/LFrkFMKYVq87UH5h+c=; b=GyOwO2NZGr/uSkkN95JN+mIWliyF2dGHDsrrtnzCzlukGUm7XKQE0Xfq7XbFUyVZQG yc+C9y1nZ/ZIMyfuCZlCe5Pj9/yfyy4YrCKfCmp+ifMdIBS0TaG3hwaNLUJsc/YRBWRg tnqs41fsnkknnTVdjW+E66GsFFx+bwGsch1B8Eu8ZUL9WJhkwp93thjDVz6EZt/1FGrD Ye5usPjvvlmXU9evgIYROgsC4brbqDIdlBdTEXikSfV96oXXYi33Y7mKmrgmAy6/vPjz 6FlQqOD6yksHZpGve6ZpW/kyGP+UdoXkL5tjoRRzXPFH1WiZ5rqjQep4tMjp1494ujd8 A12A== X-Gm-Message-State: ALoCoQnMoBUmhYDU5fbIxLM3ujWp8umq/K/VBEWxH++IcA0Lhd9fuzjzWWkC09eQIxB5yeEKbNTUb4bpYBkkMslPyRKWKUkaJg== X-Received: by 10.28.134.142 with SMTP id i136mr2872196wmd.86.1450347354896; Thu, 17 Dec 2015 02:15:54 -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 b203sm1598642wmh.24.2015.12.17.02.15.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 02:15:54 -0800 (PST) From: Thomas Monjalon To: Santosh Shukla Date: Thu, 17 Dec 2015 11:14:38 +0100 Message-ID: <2241331.HNmyzf8foi@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: 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:15:55 -0000 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. 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.