Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region
From: Yuanhan Liu <hidden>
Date: 2016-02-02 08:48:04
On Tue, Feb 02, 2016 at 06:50:18AM +0100, David Marchand wrote:
On Tue, Feb 2, 2016 at 6:43 AM, Yuanhan Liu [off-list ref] wrote:quoted
On Tue, Feb 02, 2016 at 09:44:14AM +0530, Santosh Shukla wrote:quoted
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?quoted
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:
rte_eal_pci_ioport_read(dev, bar, buf, size)
{
return if not an IO bar;
if (has io)
return inb/w/l();
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?
--yliu