[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver
Tan, Jianfeng
jianfeng.tan at intel.com
Thu Jan 14 07:09:18 CET 2016
Hi Tetsuya,
On 1/14/2016 12:27 PM, Tetsuya Mukawa wrote:
> On 2016/01/12 15:58, Yuanhan Liu wrote:
> Hi Yuanhan and Jianfeng,
>
> Thanks for great patches.
> I want to use VIRTIO-1.0 feature for my virtio container patch, because
> it will solve 44 bit memory address limitation.
> (So far, legacy virtio-net device only receives queue address under (1
> << (32 + 12)).)
I suppose you are specifying the code below:
/*
* Virtio PCI device VIRTIO_PCI_QUEUE_PF register is 32bit,
* and only accepts 32 bit page frame number.
* Check if the allocated physical memory exceeds 16TB.
*/
if ((mz->phys_addr + vq->vq_ring_size - 1) >>
(VIRTIO_PCI_QUEUE_ADDR_SHIFT + 32)) {
PMD_INIT_LOG(ERR, "vring address shouldn't be above
16TB!");
rte_free(vq);
return -ENOMEM;
}
So you don't need to add extra cmd option, right?
>
> I have a few comments to rebase virtio container patches on this patches.
>
> 1. VIRTIO_READ_REG_X
>
> So far, VIRTIO_READ_REG_1/2/4 are defined in virtio_pci.h.
> But these macros are only referred by virtio_pci.c.
> How about moving the macros to virtio_pci.c?
+1 for this.
>
> 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?
Thanks,
Jianfeng
>
> Thanks,
> Tetsuya
More information about the dev
mailing list