Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

On Tue, Feb 2, 2016 at 12:30 PM, Santosh Shukla [off-list ref] wrote:

On Tue, Feb 2, 2016 at 11:13 AM, Yuanhan Liu
[off-list ref] wrote:

quoted

On Tue, Feb 02, 2016 at 09:44:14AM +0530, Santosh Shukla wrote:

quoted

quoted

quoted

+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.

quoted

quoted

+
+     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.

quoted

quoted

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.

quoted

Anyway, it's just some thoughts from me. David, comments?

        --yliu