From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by dpdk.org (Postfix) with ESMTP id B626795CD for ; Tue, 2 Feb 2016 17:18:45 +0100 (CET) Received: by mail-pa0-f54.google.com with SMTP id uo6so103186231pac.1 for ; Tue, 02 Feb 2016 08:18:45 -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=QrezTUxD+WPVCgHNnVu65MrkV63biM0KfQNMqQNLb7I=; b=bmKIjmzM1dyi9408KWgmFiuWIt8vBEaf9XMVM2yH0qxjFlw15SvoYaN7HDCXIM1C/8 0MQSmsv6qlVPFQIgVl7Q5I+c5UBfyuGnZo8J7+ld/Y3Y8pWNqJ1txp6npcGN+W0fWN5I fSvLuxmc/ClU1nS6vmphIhUjIQQYPFIXbosMiZ082dizBEevJx3tDG1XXgRoik7iqDV0 JEQt3AE9jBnA5oX72aTWa0UMV1BnKx96nRyKLgDrYVP3v17ecDsSppn0MPdYnqYi/QXb KqVGjMyDL2AmBIaHb/GT0rucrM659jy7KsZj+TadhFHolfbhv2zBy3AtsJsgYKrEUXCT DPxw== 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=QrezTUxD+WPVCgHNnVu65MrkV63biM0KfQNMqQNLb7I=; b=Ye8I6QMPoB8Lbe/Xi6J/xNt+SX4ws/otaTlk8lQO2U7sfJHhj/5EYydyNxEkv53zrE fYd+AgDaainCYCY7zuL7zgIAnNdVtiIRA32jTba//dK8Htl4RigqlL49ExOI10hfhzWa rGVm0NADZ4TaRuxfHZUHuapKiW8r7JcK5glRG2y1jcsPaa3JnU3HTszmWkHHU6FslQQu wfZIYg9a54hfBZ+b8YKSgZoknrhrSGEkGoNq6S16zSX77zKcnnGh9y3dFLJRARzaZnGS JxuQwR3aRBxWnKxNW0TnAOa36qUB6NcAo+jg51c16Lbz3GH+G2T78vWN2pMvDshsAGin EWeg== X-Gm-Message-State: AG10YORBR78tHB+WP/gjy67jQo9Vmc3JEjNSI486zCAj6nA3ECDh6ywCXQBPkplUpeo8eiKx0EdQuXy8yjIY9W4P MIME-Version: 1.0 X-Received: by 10.67.30.201 with SMTP id kg9mr3317821pad.132.1454429925104; Tue, 02 Feb 2016 08:18:45 -0800 (PST) Received: by 10.66.12.132 with HTTP; Tue, 2 Feb 2016 08:18:44 -0800 (PST) In-Reply-To: References: <1454091717-32251-1-git-send-email-sshukla@mvista.com> <20160201134854.GE4257@yliu-dev.sh.intel.com> <20160202054345.GI4257@yliu-dev.sh.intel.com> <20160202084933.GJ4257@yliu-dev.sh.intel.com> Date: Tue, 2 Feb 2016 21:48:44 +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 v6 1/8] eal: pci: add api to rd/wr pci bar region 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, 02 Feb 2016 16:18:46 -0000 On Tue, Feb 2, 2016 at 9:21 PM, Santosh Shukla wrote: > On Tue, Feb 2, 2016 at 2:19 PM, Yuanhan Liu wrote: >> On Tue, Feb 02, 2016 at 06:50:18AM +0100, David Marchand wrote: >>> On Tue, Feb 2, 2016 at 6:43 AM, Yuanhan Liu wrote: >>> > On Tue, Feb 02, 2016 at 09:44:14AM +0530, Santosh Shukla wrote: >>> >> Current use-case is virtio: It is used as io_bar which is first >>> >> bar[1]. But implementation is generic, can be used to do rd/wr for >>> >> other bar index too. Also vfio facilitate user to do rd/wr to pci_bars >>> >> w/o mapping that bar, So apis will be useful for such cases in future. >>> >> >>> >> AFAIU: uio has read/write_config api only and Yes if bar region mapped >>> >> then no need to do rd/wr, user can directly access the pci_memory. But >>> >> use-case of this api entirely different: unmapped memory by >>> >> application context i.e.. vfio_rd/wr-way {pread/pwrite-way}. >>> >> >>> >> Is above explanation convincing? Pl. let me know. >>> > >>> > TBH, not really. So, as you stated, it should be generic APIs to >>> > read/write bar space, but limiting it to VFIO only and claiming >>> > that read/write bar space is not support by other drivers (such >>> > as UIO) while in fact it can (in some ways) doesn't seem right >>> > to me. >>> > >>> > Anyway, it's just some thoughts from me. David, comments? >>> >>> >From the very start, same opinion. >>> We should have a unique api to access those, and eal should hide >>> details like kernel drivers (uio, vfio, whatever) to the pmd. >>> >>> Now the thing is, how to do this in an elegant and efficient way. >> >> I was thinking that we may just make it be IO port specific read/ >> write functions: >> > > Ok, > >> rte_eal_pci_ioport_read(dev, bar, buf, size) >> { >> >> return if not an IO bar; >> >> if (has io) >> return inb/w/l(); >> > > In that case, It may be r / if (has io) / if (drv->kdrv == UIO) > >> if (vfio) >> return vfio_ioport_read(); >> >> else, claim aloud that io port read is not allowed >> } >> >> Let us not handle memory bar resource here: in such case, you should >> go with rte_eal_pci_map_device() and do it with memory mapped io. >> >> Does that make any sense? >> > I am not entirely sure. > Are you considering IGB_UIO, UIO_GENERIC and NIC_UIO: all the cases ? > Just came-up something below what Yuanhan has proposed, Does this look okay? int rte_eal_pci_ioport_read(const struct rte_pci_device *device, void *buf, size_t len, off_t offset, int bar_idx) { if (bar_idx != 0) { RTE_LOG(ERR, EAL, "not a ioport bar\n"); return -1; } switch (device->kdrv) { case RTE_KDRV_VFIO: return pci_vfio_ioport_read(device, buf, len, offset, bar_idx); case RTE_KDRV_IGB_UIO: case RTE_KDRV_UIO_GENERIC: case RTE_KDRV_NIC_UIO: { switch (size) case 1: return inb(buf /*ioport address*/); case 2: return inw(buf /* ioport address*/); case 4: return inl(buf /* ioport address*/); default: RTE_LOG(ERR, EAL, "invalid size\n"); } default: RTE_LOG(ERR, EAL, "read bar not supported by driver\n"); return -1; } } > >> --yliu