[dpdk-dev] [PATCH v3 3/5] vhost: add apis for datapath configuration

[Maxime Coquelin]

Hi,

On 03/22/2018 09:22 AM, Wang, Zhihong wrote:
> 
> 
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com]
>> Sent: Thursday, March 22, 2018 5:08 AM
>> To: Wang, Zhihong <zhihong.wang at intel.com>; dev at dpdk.org
>> Cc: Tan, Jianfeng <jianfeng.tan at intel.com>; Bie, Tiwei
>> <tiwei.bie at intel.com>; yliu at fridaylinux.org; Liang, Cunming
>> <cunming.liang at intel.com>; Wang, Xiao W <xiao.w.wang at intel.com>; Daly,
>> Dan <dan.daly at intel.com>
>> Subject: Re: [PATCH v3 3/5] vhost: add apis for datapath configuration
>>
>>
>>
>> On 02/27/2018 11:13 AM, Zhihong Wang wrote:
>>> This patch adds APIs for datapath configuration. The eid and did of the
>>> vhost-user socket can be configured to identify the actual device.
>>>
>>> When the default software datapath is used, eid and did are set to -1.
>>> When alternative datapath is used, eid and did are set by app to specify
>>> which device to use. Each vhost-user socket can have only 1 connection in
>>> this case.
>>>
>>> Signed-off-by: Zhihong Wang <zhihong.wang at intel.com>
>>> ---
>>>    lib/librte_vhost/rte_vhost.h           | 70
>> ++++++++++++++++++++++++++++++++++
>>>    lib/librte_vhost/rte_vhost_version.map |  6 +++
>>>    lib/librte_vhost/socket.c              | 65
>> +++++++++++++++++++++++++++++++
>>>    lib/librte_vhost/vhost.c               | 50 ++++++++++++++++++++++++
>>>    lib/librte_vhost/vhost.h               | 10 +++++
>>>    5 files changed, 201 insertions(+)
>>>
>>
>> Isn't the notion of EID & DID Intel specifics?
>> At vhost API level, shouldn't we only care of the offload device ID?
> 
> It's not vendor specific: Engine id refers to an engine which is a device
> on a bus, the engine could have multiple queue pairs or virtual functions.
> The driver can manage them to present multiple vhost ports with vDPA to
> application, so logically the concept of device id exists.
> 
> In a lot of acceleration cases, application needs to be able to choose the
> exact port to use instead of letting the driver to decide (because it does
> make a difference), therefore it's necessary to expose the device id here.

Yes, but if I understood correctly with the IFCVF driver, we could pass 
directly the virtual function to the vhost-user lib, no need to specify
the engine. We would just need to register one device per VF, but that 
looks like the right think to do looking at how IFCVF manages MAC
addresses and link status for example.

Thanks,
Maxime