From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) by dpdk.org (Postfix) with ESMTP id 5BD4E56B7 for ; Tue, 2 Feb 2016 08:01:29 +0100 (CET) Received: by mail-pf0-f170.google.com with SMTP id w123so5385277pfb.0 for ; Mon, 01 Feb 2016 23:01:29 -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=jvZRZBFGxdsypi+z7eoZs2oxzWEkg7a3V0zFouQyui0=; b=zF0NZQTj26DnPbZ2om/j88bZq2tGZP/ctiCMQXcchkpII3gVAWYbpS/DlN/GoHhuO0 xL0Zt5MONmcAGaHT8cYOGXtno3PTjP+/L1f1N547CyT+GHd0rBcrg8y/worTqgucNN6f rmUjyEVq5VLRHqI8YRj78sSu4GikxiFol3+cRzexbU0CX5PU7YTZc723fesFa/H7ri3z iI1leRm8f3JzkuCb9qspvAkmsnOifR+Fiesx4CogvE0ko1AHy4oSvgqnPRGHllt1CX1l Y3H75gCmFo6emhRqTwXeUwBQZtrlch2ZLa24/Tj8N4t4WnNk/JOCNnixH1/+gz2cxOMY Y1vA== 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=jvZRZBFGxdsypi+z7eoZs2oxzWEkg7a3V0zFouQyui0=; b=KEg+ltVV1KxbHTrgRQpLGTs5dO5lOvW4UWAP72KRXBwbZrTZXwOAol2OTqWrBf7ynt 9E+VOQjEHC8AokMzTGWZm40DWWITZxfdpLcXlzvaKvYJjd8ts2axKEROs3+6f9Wqv/dn eGuYu+oQz03kvlH/I67oxosMEwEu5p7ZLOHkg0z+jNAOvdCEvv1+fnpmUSAPSQu+33di 4ZQ6Owl8ohKhhiVNNLsQti+HxewRvdGJmZQRNvQ9dM6sAr3KkR/semQnrXZ2C+lxlSd5 6ouh6ol9R57tPli8tHBjSnSl7esD8ck9nc02QYt9i68eI3gHROxjBJObyd+1Gu+9Z/Df alYA== X-Gm-Message-State: AG10YOTlxETOkvGrLBPcb1xgNz+Vw+FuXiB16aSbwRFhLDLatK1J+jXEqdymG2OG11a8gCTm9DfeaJHzK0We0zaV MIME-Version: 1.0 X-Received: by 10.98.0.66 with SMTP id 63mr44830028pfa.61.1454396488772; Mon, 01 Feb 2016 23:01:28 -0800 (PST) Received: by 10.66.12.132 with HTTP; Mon, 1 Feb 2016 23:01:28 -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> Date: Tue, 2 Feb 2016 12:31:28 +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 07:01:29 -0000 On Tue, Feb 2, 2016 at 12:30 PM, Santosh Shukla wrote: > On Tue, Feb 2, 2016 at 11:13 AM, Yuanhan Liu > wrote: >> On Tue, Feb 02, 2016 at 09:44:14AM +0530, Santosh Shukla wrote: >>> >> +int rte_eal_pci_read_bar(const struct rte_pci_device *device, >>> >> + void *buf, size_t len, off_t offset, >>> >> + int bar_idx) >>> >> + >>> >> +{ >>> >> + const struct rte_intr_handle *intr_handle = &device->intr_handle; >>> > >>> > I'd suggest to reference this var inside pci_vfio_read/write_bar(), and >>> > pass device as the parmater instead. >>> > >>> >>> (Sorry for late reply, I was travelling on Monday.) >>> Make sense. >>> >>> >> + >>> >> + switch (device->kdrv) { >>> >> + case RTE_KDRV_VFIO: >>> >> + return pci_vfio_read_bar(intr_handle, buf, len, >>> >> + offset, bar_idx); >>> >> + default: >>> >> + RTE_LOG(ERR, EAL, "write bar not supported by driver\n"); >>> > ^^^^^ >>> > typo. >>> > >>> >>> Oh, r / write / read, right? sorry for typo error (:- >> >> Right. >> >>> >>> > >>> > BTW, I have a question about this API. Obviously, reading/writing bar >>> > space is supported with UIO (when memory resource is mmapped). And I >>> > know why you introduced such 2 APIs, for reading IO bar. >>> > >>> > So, here is the question: what are the 2 APIs for, for being gerneric >>> > APIs to read/write bar spaces, or just to read IO bar spaces? If it's >>> > former, the message is wrong; if it's later, you may better rename it >>> > to rte_eal_pci_read/write_io_bar()? >>> > >>> >>> 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. >> > Sorry typo > I agree.. But if UIO doesn't and need could, then I am confused what r / But if UIO doesn't and need could / But if UIO doesn't and vfio could > can be done? However we have a use-case for vfio so It make sense to > me use this api. Or else If we all agree then I can export api only > for VFIO.. but it will violate EAL abstraction. > > >> Anyway, it's just some thoughts from me. David, comments? >> >> --yliu