From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id A02DF56B7 for ; Tue, 2 Feb 2016 08:00:36 +0100 (CET) Received: by mail-pf0-f181.google.com with SMTP id w123so5371417pfb.0 for ; Mon, 01 Feb 2016 23:00:36 -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=cgFD7FCA0abgcnCiHc80b1YDjfpnsovYZO5H12TM4pw=; b=JaCUkRDyVKQaZ2bO8fsEj16bSbx0EhO7bBGDsbOwaWt+sST58dvJae5dYYo5qeWBRH qHhT3qD6NwYP79QBvweLn5UpmWR+ZnJJjlvVN3AhTubXg7Kit1n5a8HmagPSezeG5JUk iVrBHb0LgcXkEQTJq3H3YvmQ43C/B30fDJqOb1CvmPb5c/sD/P5UxC2XR951PVbUh9OO XAVBdL0YrY1svsA7TEo9sQJzgKqgHLPPjBPlAPIHKRzavBrJTw2U0krkI0n53xmd6vOy 5JR16j/PLiVCkWngytULY8oRSQe9keP20dYuSVT25rpEsycfTyzhkw8UR+aGPqu+xifQ rZ1A== 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=cgFD7FCA0abgcnCiHc80b1YDjfpnsovYZO5H12TM4pw=; b=FrF8sMhd6a6BGqmeOAQQS9m+e4Me5vu5QK98heIFDzfldHzLiJmFKEwb+nFnDEIROe SUANt1BeN70rRMc1YLfkds28seW8zkG7O4K6OQe6Vdrngoq6Mc0A1XLyT3g5Ke6TU8Oz 1+dBz5RQOFFF7PDHrtc/PYf33BFdjFn3hVThl9aSfRXViEn+VDViyYwtW6BzFqN896Wp Bg1yQBMpr/zxGYnMxcAeo9nXBHvYqfnN5bvMJsNPA2XMpunemwmkodW9xK+Nagb+LFrg cGeP4yN8mXFLiQ8D+tfgtnGwNJJfOS+x2x72WoUyar0zTEAWluCHruO0GBd0jwRUsThT Pf2Q== X-Gm-Message-State: AG10YOSYYPTY6AA+Utw7cfLroNuzJJTN31btn72Tq7bA9BxY+agwLx5AehcJFsUjoCrqZQDjSjPfa+b1QsF9D3Zq MIME-Version: 1.0 X-Received: by 10.98.34.198 with SMTP id p67mr35360202pfj.93.1454396436054; Mon, 01 Feb 2016 23:00:36 -0800 (PST) Received: by 10.66.12.132 with HTTP; Mon, 1 Feb 2016 23:00:35 -0800 (PST) In-Reply-To: <20160202054345.GI4257@yliu-dev.sh.intel.com> 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:30:35 +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:00:37 -0000 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. > I agree.. But if UIO doesn't and need could, then I am confused what 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