[dpdk-dev] [PATCH 0/3] add ifcvf driver

Maxime Coquelin maxime.coquelin at redhat.com
Wed Mar 21 21:47:31 CET 2018


Hi Xiao,

On 03/15/2018 05:49 PM, Wang, Xiao W wrote:
> Hi Maxime,
> 
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com]
>> Sent: Sunday, March 11, 2018 2:24 AM
>> To: Wang, Xiao W <xiao.w.wang at intel.com>; dev at dpdk.org
>> Cc: Wang, Zhihong <zhihong.wang at intel.com>; yliu at fridaylinux.org; Liang,
>> Cunming <cunming.liang at intel.com>; Xu, Rosen <rosen.xu at intel.com>; Chen,
>> Junjie J <junjie.j.chen at intel.com>; Daly, Dan <dan.daly at intel.com>
>> Subject: Re: [PATCH 0/3] add ifcvf driver
>>
>> Hi Xiao,
>>
>> On 03/10/2018 12:08 AM, Xiao Wang wrote:
>>> This patch set has dependency on
>> http://dpdk.org/dev/patchwork/patch/35635/
>>> (vhost: support selective datapath);
>>>
>>> ifc VF is compatible with virtio vring operations, this driver implements
>>> vDPA driver ops which configures ifc VF to be a vhost data path accelerator.
>>>
>>> ifcvf driver uses vdev as a control domain to manage ifc VFs that belong
>>> to it. It registers vDPA device ops to vhost lib to enable these VFs to be
>>> used as vhost data path accelerator.
>>>
>>> Live migration feature is supported by ifc VF and this driver enables
>>> it based on vhost lib.
>>>
>>> vDPA needs to create different containers for different devices, thus this
>>> patch set adds APIs in eal/vfio to support multiple container.
>> Thanks for this! That will avoind having to duplicate these functions
>> for every new offload driver.
>>
>>
>>>
>>> Junjie Chen (1):
>>>     eal/vfio: add support for multiple container
>>>
>>> Xiao Wang (2):
>>>     bus/pci: expose sysfs parsing API
>>
>> Still, I'm not convinced the offload device should be a virtual device.
>> It is a real PCI device, why not having a new device type for offload
>> devices, and let the device to be probed automatically by the existing
>> device model?
> 
> IFC VFs are generated from SRIOV, with the PF driven by kernel driver.
> In DPDK we need to have something to represent PF, to register itself as
> a vDPA engine, so a virtual device is used for this purpose.
I went through the code, and something is not clear to me.

Why do we need to have a representation of the PF in DPDK?
Why cannot we just bind at VF level?


> The VFs are used for vhost net offload, and we could implement exception traffic
> Rx/Tx function on the VFs in future via port-representor mechanism. So this patch
> keeps the device type as net.
> 
> BRs,
> Xiao
> 
>>
>> Thanks,
>> Maxime
>>
>>
>>>     net/ifcvf: add ifcvf driver
>>>
>>>    config/common_base                       |    6 +
>>>    config/common_linuxapp                   |    1 +
>>>    drivers/bus/pci/linux/pci.c              |    9 +-
>>>    drivers/bus/pci/linux/pci_init.h         |    8 +
>>>    drivers/bus/pci/rte_bus_pci_version.map  |    8 +
>>>    drivers/net/Makefile                     |    1 +
>>>    drivers/net/ifcvf/Makefile               |   40 +
>>>    drivers/net/ifcvf/base/ifcvf.c           |  329 ++++++++
>>>    drivers/net/ifcvf/base/ifcvf.h           |  156 ++++
>>>    drivers/net/ifcvf/base/ifcvf_osdep.h     |   52 ++
>>>    drivers/net/ifcvf/ifcvf_ethdev.c         | 1241
>> ++++++++++++++++++++++++++++++
>>>    drivers/net/ifcvf/rte_ifcvf_version.map  |    4 +
>>>    lib/librte_eal/bsdapp/eal/eal.c          |   51 +-
>>>    lib/librte_eal/common/include/rte_vfio.h |  117 ++-
>>>    lib/librte_eal/linuxapp/eal/eal_vfio.c   |  553 ++++++++++---
>>>    lib/librte_eal/linuxapp/eal/eal_vfio.h   |    2 +
>>>    lib/librte_eal/rte_eal_version.map       |    7 +
>>>    mk/rte.app.mk                            |    1 +
>>>    18 files changed, 2480 insertions(+), 106 deletions(-)
>>>    create mode 100644 drivers/net/ifcvf/Makefile
>>>    create mode 100644 drivers/net/ifcvf/base/ifcvf.c
>>>    create mode 100644 drivers/net/ifcvf/base/ifcvf.h
>>>    create mode 100644 drivers/net/ifcvf/base/ifcvf_osdep.h
>>>    create mode 100644 drivers/net/ifcvf/ifcvf_ethdev.c
>>>    create mode 100644 drivers/net/ifcvf/rte_ifcvf_version.map
>>>


More information about the dev mailing list