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. 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 > >
