[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver
Tetsuya Mukawa
mukawa at igel.co.jp
Mon Jan 18 10:04:50 CET 2016
On 2016/01/14 15:41, Tetsuya Mukawa wrote:
>
>>> 2. Abstraction of read/write accesses.
>>>
>>> It may be difficult to cleanly rebase my patches on this patches,
>>> because virtio_read_caps() is not abstracted.
>>> Let me describe it more.
>>> So far, we need to handle below 3 virtio-net devices..
>>> - physical virtio-net device.
>>> - virtual virtio-net device in virtio-net PMD. (Jianfeng's patch)
>>> - virtual virtio-net device in QEMU. (my patch)
>>>
>>> Almost all code of the virtio-net PMD can be shared between above
>>> different cases.
>>> Probably big difference is how to access to configuration space.
>>>
>>> Yuanhan's patch introduces an abstraction layer to hide configuration
>>> space layout and how to access it.
>>> Is it possible to separate?
>>> I guess "access method" will be nice to be abstracted separately from
>>> "configuration space layout".
>>> Probably access method will be defined by "eth_dev->dev_type" and the
>>> PMD name like "eth_cvio".
>>> And "configuration space layout" will be defined by capability list of
>>> PCI configuration layout.
>>>
>>> For example, if access method like below are abstracted separately and
>>> current "virtio_pci.c" is implemented on this abstraction, we can easily
>>> re-use virtio_read_caps().
>>> - how to read/write virtio configuration space.
>>> - how to mmap PCI configuration space.
>>> - how to read/(write) PCI configuration space.
>>
>> I basically agree with you. We have two dimensions here:
>>
>> legacy modern
>> physical virtio device: Use
>> virtio_read_caps_phys() to distinguish
>> virtual virtio device (Tetsuya): Use virtio_read_caps_virt() to
>> distinguish
>> virtual virtio device (Jianfeng): does not need a "configuration
>> space layout", no need to distinguish
>>
>> So in vtpci_init(), we needs to test "eth_dev->dev_type" firstly
>>
>> vtpci_init() {
>> if (eth_dev->dev_type == RTE_ETH_DEV_PCI) {
>> if (virtio_read_caps_phys()) {
>> // modern
>> } else {
>> // legacy
>> }
>> } else {
>> if (Tetsuya's way) {
>> if (virtio_read_caps_virt()) {
>> // modern
>> } else {
>> // legacy
>> }
>> } else {
>> // Jianfeng's way
>> }
>> }
>> }
>>
>> And from Yuanhan's angle, I think he does not need to address this
>> problem. How do you think?
> Yes, I agree he doesn't need.
>
> Firstly, I have implemented like above, then I noticed that
> virtio_read_caps_phy() and virtio_read_caps_virt() are same except for
> access method.
> Anyway, I guess abstracting access method is not so difficult.
> If you are OK, I want to send RFC on Yuanhan's patch. Is it OK?
Hi Jianfeng,
I will submit patches to abstract pci access method.
The patches will be on Yuanhan's latest virtio-1.0 patches.
I guess your container patches also can be on the patches.
Could you please check it?
Thanks,
Tetsuya
More information about the dev
mailing list