Hi,

On 03/22/2018 09:22 AM, Wang, Zhihong wrote:


-----Original Message-----
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Thursday, March 22, 2018 5:08 AM
To: Wang, Zhihong <zhihong.w...@intel.com>; dev@dpdk.org
Cc: Tan, Jianfeng <jianfeng....@intel.com>; Bie, Tiwei
<tiwei....@intel.com>; y...@fridaylinux.org; Liang, Cunming
<cunming.li...@intel.com>; Wang, Xiao W <xiao.w.w...@intel.com>; Daly,
Dan <dan.d...@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.w...@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

Reply via email to