[dpdk-dev] [PATCH v1 0/2] Virtio-net PMD Extension to work on host
jianfeng.tan at intel.com
Wed Jan 6 06:42:40 CET 2016
On 1/6/2016 11:57 AM, Tetsuya Mukawa wrote:
> On 2015/12/28 20:06, Tetsuya Mukawa wrote:
>> On 2015/12/24 23:05, Tan, Jianfeng wrote:
>>> Hi Tetsuya,
>>> After several days' studying your patch, I have some questions as follows:
>>> 1. Is physically-contig memory really necessary?
>>> This is a too strong requirement IMHO. IVSHMEM doesn't require this in its original meaning. So how do you think of
>>> Huawei Xie's idea of using virtual address for address translation? (In addition, virtual address of mem_table could be
>>> different in application and QTest, but this can be addressed because SET_MEM_TABLE msg will be intercepted by
>> Hi Jianfeng,
>> Thanks for your suggestion.
>> Huawei's idea may solve contig-mem restriction.
>> Let me have time to check it more.
> Hi Jianfeng,
> I made sure we can remove the restriction with Huawei's idea.
> One thing I concern is below.
> If we don't use contiguous memory, this PMD will not work with other
> 'physical' PMDs like e1000 PMD, virtio-net PMD, and etc.
> (This is because allocated memory may not be physically contiguous.)
> One of examples is that if we implement like above, in QEMU guest, we
> can handle a host NIC directly, but in container, we will not be able to
> handle the device.
> This will be a restriction for this virtual addressing changing.
> Do you know an use case that the user wants to handle 'physical' PMD and
> 'virtual' virtio-net PMD together?
I have no use case in hand, which handles 'physical' PMDs and 'virtual'
virtio-net PMD together.
(Pavel Fedin once tried to run ovs in container, but that case just uses
virtual virtio devices, I
don't know if he has plan to add 'physical' PMDs as well.)
Actually, it's not completely contradictory to make them work together.
a. containers with root privilege
We can initialize memory as legacy way. (TODO: besides
physical-contiguous, we try allocate
virtual-contiguous big area for all memsegs as well.)
a.1 For vhost-net, before sending memory regions into kernel, we can
merge those virtual-contiguous regions into one region.
a.2 For vhost-user, we can merge memory regions in the vhost. The
blocker is that for now, maximum fd num was restricted
by VHOST_MEMORY_MAX_NREGIONS=8 (so in 2M-hugepage's case, 16M shared
memory is not nearly enough).
b. containers without root privilege
No need to worry about this problem, because it lacks of privilege to
construct physical-contiguous memory.
More information about the dev