[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