On Tue, Feb 2, 2016 at 12:30 PM, Santosh Shukla <sshukla at mvista.com> wrote:
> On Tue, Feb 2, 2016 at 11:13 AM, Yuanhan Liu
> <yuanhan.liu at linux.intel.com> 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
