From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 421EA58C5 for ; Fri, 9 Sep 2016 11:07:15 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id w12so20036592wmf.0 for ; Fri, 09 Sep 2016 02:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gmPJwHbCdByAPsyxkMlCdZvL4T6LGBH/D16Vungooac=; b=MGnG7Myzpyu6+5M3F6gjeO9QKOHOZ4RbLSAq+JUGKEJCP12ws+PpoAO+bUNXJtaA7z 14ydnl7dUnAe9TzL1iGdkNh9Ni5ljcvutMHZdVsL6iw9f8Nru8XvZdby1s2aeE2lCcYi IVv+RxelDKcSddDJ6cioRpVCtvTDP5slmXlilSfqg5sb1ACm+syvXAivTsY2foD0cCAy SGvFsAxBnXqcK1P7NuZmu3ANCe/G9MySNly27QleJgQaQNJk2cPip2CzAcvH+QBg44Y+ T/YwjVnJvQ6Ash5oH9PRZs6lhpQ/OkwpMD3QaL1rkzH0I2z0WTHxwDx4iPSmq4wU0zEi Lf2A== 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:from:date :message-id:subject:to:cc; bh=gmPJwHbCdByAPsyxkMlCdZvL4T6LGBH/D16Vungooac=; b=PX/3FGuD5PR54nLEXYt6JXNcPIYtB7+FMSwDRuS4gitiEytdorSYCPGC6IAET0rtkY zTBKKEic8HZ27fSr9nqLwQUHc2pfLD4fSVIGLpyOa4ThUnO1bxISiHK1WpD4AUVbVsVl X0LlHy2Nbw53fbzzHNw8l6luDwnvYaJ+19B1UafRUyVK7d03isoE5/aM2Py1ucL0G1l2 1kllZn4N5oOe5qkRTcxffVXGh1k7DWjiq2qF0+XtXr02ebtb6xMsKKFWR9xeFSmgTyQg +p+o+Ue1AhPWgNfAT9rNVJ0RiNrCefBWuC+fHC7jM9uQK7hshcaxqphXPIvnc+3s9lIz w4Zg== X-Gm-Message-State: AE9vXwN3hPIOikJIOznRCaDzA1X3N/9ZSV9SDn0zTYCKtPVPURI2ehQ/vUUMBMHzCuuTeXMMkRsok6SOqrmnBSrq X-Received: by 10.194.81.106 with SMTP id z10mr1911915wjx.140.1473412035043; Fri, 09 Sep 2016 02:07:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.97.213 with HTTP; Fri, 9 Sep 2016 02:06:54 -0700 (PDT) In-Reply-To: <1472696197-37614-1-git-send-email-jianfeng.tan@intel.com> References: <1472696197-37614-1-git-send-email-jianfeng.tan@intel.com> From: David Marchand Date: Fri, 9 Sep 2016 11:06:54 +0200 Message-ID: To: Jianfeng Tan Cc: "dev@dpdk.org" , Ferruh Yigit , Stephen Hemminger Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [RFC] igb_uio: deprecate iomem and ioport mapping 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: Fri, 09 Sep 2016 09:07:15 -0000 Hello Jianfeng, On Thu, Sep 1, 2016 at 4:16 AM, Jianfeng Tan wrote: > Previously in igb_uio, iomem is mapped, and both ioport and io mem > are recorded into uio framework, which is duplicated and makes the > code too complex. > > For iomem, DPDK user space code never opens or reads files under > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/maps/. Instead, > /sys/pci/bus/devices/xxxx:xx:xx.x/resourceY are used to map device > memory. > > For ioport, non-x86 platforms cannot read from files under > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/portio/ directly, because > non-x86 platforms need to map port region for access in user space, > see non-x86 version pci_uio_ioport_map(). x86 platforms can use the > the same way as uio_pci_generic. > > This patch deprecates iomem and ioport mapping in igb_uio kernel > module, and adjusts the iomem implementation in both igb_uio and > uio_pci_generic: > - for x86 platform, get ports info from /proc/ioports; > - for non-x86 platform, map and get ports info by pci_uio_ioport_map(). > > Note: this will affect those applications who are using files under > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/maps/ and > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/portio/. > > Signed-off-by: Jianfeng Tan > --- > lib/librte_eal/linuxapp/eal/eal_pci.c | 4 - > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 56 +------------- > lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 119 ++---------------------------- > 3 files changed, 9 insertions(+), 170 deletions(-) [snip] > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > index 1786b75..28d09ed 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c [snip] > - /* FIXME only for primary process ? */ > - if (dev->intr_handle.type == RTE_INTR_HANDLE_UNKNOWN) { > - > - snprintf(filename, sizeof(filename), "/dev/uio%u", uio_num); > - dev->intr_handle.fd = open(filename, O_RDWR); > - if (dev->intr_handle.fd < 0) { > - RTE_LOG(ERR, EAL, "Cannot open %s: %s\n", > - filename, strerror(errno)); > - return -1; > - } > - dev->intr_handle.type = RTE_INTR_HANDLE_UIO; > - } The only potential issue I can see removing this is that if a device has no iomem resource, then its interrupt fd will never be initialised. I can see no problem at the moment, so let's go with this. If such a problem arises later, we can separate this from the resource mapping stuff (with a new api ?). The rest looks good to me. As Ferruh said, this should go through deprecation notices then go in 17.02. -- David Marchand