[dpdk-dev] [RFC PATCH v2] vhost: Add VHOST PMD

Tetsuya Mukawa mukawa at igel.co.jp
Wed Oct 21 06:35:56 CEST 2015


On 2015/10/19 22:27, Richardson, Bruce wrote:
>> -----Original Message-----
>> From: Panu Matilainen [mailto:pmatilai at redhat.com]
>> Sent: Monday, October 19, 2015 2:26 PM
>> To: Tetsuya Mukawa <mukawa at igel.co.jp>; Richardson, Bruce
>> <bruce.richardson at intel.com>; Loftus, Ciara <ciara.loftus at intel.com>
>> Cc: dev at dpdk.org; ann.zhuangyanying at huawei.com
>> Subject: Re: [dpdk-dev] [RFC PATCH v2] vhost: Add VHOST PMD
>>
>> On 10/19/2015 01:50 PM, Tetsuya Mukawa wrote:
>>> On 2015/10/19 18:45, Bruce Richardson wrote:
>>>> On Mon, Oct 19, 2015 at 10:32:50AM +0100, Loftus, Ciara wrote:
>>>>>> On 2015/10/16 21:52, Bruce Richardson wrote:
>>>>>>> On Mon, Aug 31, 2015 at 12:55:26PM +0900, Tetsuya Mukawa wrote:
>>>>>>>> The patch introduces a new PMD. This PMD is implemented as thin
>>>>>> wrapper
>>>>>>>> of librte_vhost. It means librte_vhost is also needed to compile
>> the PMD.
>>>>>>>> The PMD can have 'iface' parameter like below to specify a path
>>>>>>>> to
>>>>>> connect
>>>>>>>> to a virtio-net device.
>>>>>>>>
>>>>>>>> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0' -- -i
>>>>>>>>
>>>>>>>> To connect above testpmd, here is qemu command example.
>>>>>>>>
>>>>>>>> $ qemu-system-x86_64 \
>>>>>>>>          <snip>
>>>>>>>>          -chardev socket,id=chr0,path=/tmp/sock0 \
>>>>>>>>          -netdev vhost-user,id=net0,chardev=chr0,vhostforce \
>>>>>>>>          -device virtio-net-pci,netdev=net0
>>>>>>>>
>>>>>>>> Signed-off-by: Tetsuya Mukawa <mukawa at igel.co.jp>
>>>>>>> With this PMD in place, is there any need to keep the existing
>>>>>>> vhost library around as a separate entity? Can the existing
>>>>>>> library be
>>>>>> subsumed/converted into
>>>>>>> a standard PMD?
>>>>>>>
>>>>>>> /Bruce
>>>>>> Hi Bruce,
>>>>>>
>>>>>> I concern about whether the PMD has all features of librte_vhost,
>>>>>> because librte_vhost provides more features and freedom than ethdev
>>>>>> API provides.
>>>>>> In some cases, user needs to choose limited implementation without
>>>>>> librte_vhost.
>>>>>> I am going to eliminate such cases while implementing the PMD.
>>>>>> But I don't have strong belief that we can remove librte_vhost now.
>>>>>>
>>>>>> So how about keeping current separation in next DPDK?
>>>>>> I guess people will try to replace librte_vhost to vhost PMD,
>>>>>> because apparently using ethdev APIs will be useful in many cases.
>>>>>> And we will get feedbacks like "vhost PMD needs to support like this
>> usage".
>>>>>> (Or we will not have feedbacks, but it's also OK.) Then, we will be
>>>>>> able to merge librte_vhost and vhost PMD.
>>>>> I agree with the above. One the concerns I had when reviewing the
>> patch was that the PMD removes some freedom that is available with the
>> library. Eg. Ability to implement the new_device and destroy_device
>> callbacks. If using the PMD you are constrained to the implementations of
>> these in the PMD driver, but if using librte_vhost, you can implement your
>> own with whatever functionality you like - a good example of this can be
>> seen in the vhost sample app.
>>>>> On the other hand, the PMD is useful in that it removes a lot of
>> complexity for the user and may work for some more general use cases. So I
>> would be in favour of having both options available too.
>>>>> Ciara
>>>>>
>>>> Thanks.
>>>> However, just because the libraries are merged does not mean that you
>>>> need be limited by PMD functionality. Many PMDs provide additional
>>>> library-specific functions over and above their PMD capabilities. The
>>>> bonded PMD is a good example here, as it has a whole set of extra
>>>> functions to create and manipulate bonded devices - things that are
>>>> obviously not part of the general ethdev API. Other vPMDs similarly
>> include functions to allow them to be created on the fly too.
>>>> regards,
>>>> /Bruce
>>> Hi Bruce,
>>>
>>> I appreciate for showing a good example. I haven't noticed the PMD.
>>> I will check the bonding PMD, and try to remove librte_vhost without
>>> losing freedom and features of the library.
>> Hi,
>>
>> Just a gentle reminder - if you consider removing (even if by just
>> replacing/renaming) an entire library, it needs to happen the ABI
>> deprecation process.
>>
>> It seems obvious enough. But for all the ABI policing here, somehow we all
>> failed to notice the two compatibility breaking rename-elephants in the
>> room during 2.1 development:
>> - libintel_dpdk was renamed to libdpdk
>> - librte_pmd_virtio_uio was renamed to librte_pmd_virtio
>>
>> Of course these cases are easy to work around with symlinks, and are
>> unrelated to the matter at hand. Just wanting to make sure such things
>> dont happen again.
>>
>> 	- Panu -
> Still doesn't hurt to remind us, Panu! Thanks. :-)

Hi,

Thanks for reminder. I've checked the DPDK documentation.
I will submit deprecation notice to follow DPDK deprecation process.
(Probably we will be able to remove vhost library in DPDK-2.3 or later.)

BTW, I will merge vhost library and PMD like below.
Step1. Move vhost library under vhost PMD.
Step2. Rename current APIs.
Step3. Add a function to get a pointer of "struct virtio_net device" by
a portno.

Last steps allows us to be able to convert a portno to the pointer of
corresponding vrtio_net device.
And we can still use features and freedom vhost library APIs provided.

Thanks,
Tetsuya


More information about the dev mailing list