From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by dpdk.org (Postfix) with ESMTP id D8B823195 for ; Tue, 8 Dec 2015 13:53:54 +0100 (CET) Received: by pacej9 with SMTP id ej9so11896741pac.2 for ; Tue, 08 Dec 2015 04:53:54 -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=5BGn+zRapQwRn7Zbfq2p5S/M2Sbb0vVV+tBELbX8rtc=; b=AtD/EC5DYwVpDi9NFS9oKJBMHFqBSY6Ghb+cAdVr6wF8FZDTovUCTdUeZLGTeLfb5X 1acUgNKWd7XHRTl7ZnEtsNSBhW+ATtOvviAnNWZ5e51viHFVm+5dO7Lu8h7Z+LBiXYvp mfsX8T9PRPr4pwNj/5/BLAqZ4KjpQTCq6+VYjZrUnp6Grd1IRHTsTcNsANrn6HZTgiJI sd0MUmDYGhNUXLEKwE/jjE9SthQMjiluIShKwUtRMQC43oLv5g/OzVWaGj6Pr0RYsDns ExLJ9NiCouq0LRxQgcGiMMob2fJaWB/I9ey+jh7vK2I01QiylxUWUn0wg2w1fpiQW2Fc 1J5Q== 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=5BGn+zRapQwRn7Zbfq2p5S/M2Sbb0vVV+tBELbX8rtc=; b=KQ5Bao8JdInIwWL0kb4CkeSM1cQoN8GgUUjbnqV38IGKVB+QNM/V3G2MKqa7WqBlk5 A0Jj16P/tFOIeZA+VlSr7YWI7uotSt+TdAcknFb6ZjzgU5ecafI68h/MiOEQfJ6nvf29 P8XzV6ysEnyHnUIvVy0Qo/nhCgl90fPusSbxQoUo9eAZ9Mo9gGBL2eUKOUhRTVx2GKTy 78LiGdTeKmcEwM3e+gXusn+ikUN9lN6QTmlnrnAASnelgjZH/tf8PJFdbrsjAmqQ75OI x19KanmU+uVDrTJ6VqGoYsudGVgMRKONgglKJHR7x1wSt8+73w7pg1SCgKK/ORVjLJP+ scPg== X-Gm-Message-State: ALoCoQmff9SREoV4MZGuFE0VVA5jNmbyfDHMU2Pwpb7kutGGDDFQ+yX4YsrV0iHwtqQJRA1IZEGqTpRHvLXrSlkX6k7LSoiwhRfLveWt2sO0SbgpsT7RybM= MIME-Version: 1.0 X-Received: by 10.66.140.79 with SMTP id re15mr4016365pab.127.1449579234242; Tue, 08 Dec 2015 04:53:54 -0800 (PST) Received: by 10.66.13.233 with HTTP; Tue, 8 Dec 2015 04:53:54 -0800 (PST) In-Reply-To: <20151207090833.03f65d63@xeon-e3> References: <1449250519-28372-1-git-send-email-sshukla@mvista.com> <1449250519-28372-7-git-send-email-sshukla@mvista.com> <20151207090833.03f65d63@xeon-e3> Date: Tue, 8 Dec 2015 18:23:54 +0530 Message-ID: From: Santosh Shukla To: Stephen Hemminger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org, Rizwan Ansari Subject: Re: [dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver 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: Tue, 08 Dec 2015 12:53:55 -0000 On Mon, Dec 7, 2015 at 10:38 PM, Stephen Hemminger < stephen@networkplumber.org> wrote: > On Fri, 4 Dec 2015 23:05:19 +0530 > Santosh Shukla wrote: > > > > > +#ifdef RTE_EXEC_ENV_LINUXAPP > > +/* start address of first pci_iobar slot (user-space virtual-addres) */ > > +void *ioport_map; > > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > > + > > +#include > > +#define DEV_NAME "/dev/igb_ioport" > > + > > +/* Keeping pci_ioport_size = 4k. > > + * So maximum mmaped pci_iobar supported = > > + * (ioport_size/pci_dev->mem_resource[0].len) > > + * > > + * note: kernel could allow maximum 32 virtio-net-pci interface, that > mean > > + * maximum 32 PCI_IOBAR(s) where each PCI_IOBAR_LEN=0x20, so > virtio_map_ioport() > > + * func by theory gonna support 4k/0x20 ==> 128 PCI_IOBAR(s), more than > > + * max-virtio-net-pci interface. > > + */ > > +#define PAGE_SIZE 4096 > > +#define PCI_IOPORT_SIZE PAGE_SIZE > > +#define PCI_IOPORT_MAX 128 /* 4k / 0x20 */ > > + > > +int ioport_map_cnt; > > +#endif /* ARM, ARM64 */ > > +#endif /* RTE_EXEC_ENV_LINUXAPP */ > > These variables should be static. > > (Sorry for delayed follow, Was travelling..) Right, > Also, it is should be possible to extract the I/O bar stuff in a generic > way through sysfs > and not depend on a character device. The long term goal for DPDK > acceptance is to > eliminate (or at least reduce to a minumum) any requirement for special > kernel drivers. > I agree. Existing implementation does read pci_iobar for start address and size, But for non-x86 arch, we need someway to map pci_iobar and thats-why thought of adding device file for a purpose, as archs like arm lack iopl() privileged io syscall support, However iopl() too quite native driver design assumption. I have few idea in my mind such that - Right now I am updating ioport_mapped addr {kernel-virtual-addr-io-memory} to /sys/bus/pci/pci_bus_xxxx/xxx/map field, instead of mapping their, I'll try to map to uio's pci interface and then use existing pci_map_resource() api to mmap kernel-virtual-io-address to user-space-virtual-ioaddr. We'll come back on this.