Hi Xiao,
On 03/15/2018 05:49 PM, Wang, Xiao W wrote:
Hi Maxime,
-----Original Message-----
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Sunday, March 11, 2018 2:24 AM
To: Wang, Xiao W <xiao.w.w...@intel.com>; dev@dpdk.org
Cc: Wang, Zhihong <zhihong.w...@intel.com>; y...@fridaylinux.org; Liang,
Cunming <cunming.li...@intel.com>; Xu, Rosen <rosen...@intel.com>; Chen,
Junjie J <junjie.j.c...@intel.com>; Daly, Dan <dan.d...@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
