From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id 9AA76AAC3 for ; Wed, 21 Mar 2018 21:47:35 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0BBCF412C2E0; Wed, 21 Mar 2018 20:47:35 +0000 (UTC) Received: from [10.36.112.43] (ovpn-112-43.ams2.redhat.com [10.36.112.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 440832166BDA; Wed, 21 Mar 2018 20:47:33 +0000 (UTC) To: "Wang, Xiao W" , "dev@dpdk.org" Cc: "Wang, Zhihong" , "yliu@fridaylinux.org" , "Liang, Cunming" , "Xu, Rosen" , "Chen, Junjie J" , "Daly, Dan" References: <20180309230809.63361-1-xiao.w.wang@intel.com> <7256d674-9ce6-ce8e-d6be-bcd368df25b3@redhat.com> From: Maxime Coquelin Message-ID: <8f3f90fe-6166-c750-2dcd-f4d1878b465c@redhat.com> Date: Wed, 21 Mar 2018 21:47:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 21 Mar 2018 20:47:35 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 21 Mar 2018 20:47:35 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'maxime.coquelin@redhat.com' RCPT:'' Subject: Re: [dpdk-dev] [PATCH 0/3] add ifcvf driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 20:47:35 -0000 Hi Xiao, On 03/15/2018 05:49 PM, Wang, Xiao W wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Sunday, March 11, 2018 2:24 AM >> To: Wang, Xiao W ; dev@dpdk.org >> Cc: Wang, Zhihong ; yliu@fridaylinux.org; Liang, >> Cunming ; Xu, Rosen ; Chen, >> Junjie J ; Daly, Dan >> 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 >>>