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 3C5855F21 for ; Sun, 25 Mar 2018 11:51:31 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6B2BF401DEA0; Sun, 25 Mar 2018 09:51:30 +0000 (UTC) Received: from [10.36.112.12] (unknown [10.36.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 122521C71A; Sun, 25 Mar 2018 09:51:26 +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> <8f3f90fe-6166-c750-2dcd-f4d1878b465c@redhat.com> From: Maxime Coquelin Message-ID: <3798273b-1d5e-8399-6bbb-f0242a65c977@redhat.com> Date: Sun, 25 Mar 2018 11:51:24 +0200 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: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Sun, 25 Mar 2018 09:51:30 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Sun, 25 Mar 2018 09:51:30 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.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: Sun, 25 Mar 2018 09:51:31 -0000 On 03/23/2018 11:27 AM, Wang, Xiao W wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Thursday, March 22, 2018 4:48 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/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? > > 1. With the vdev representation we could use it to talk to PF kernel driver to do flow configuration, we can implement > flow API on the vdev in future for this purpose. Using a vdev allows introducing this kind of control plane thing. > > 2. When port representor is ready, we would integrate it into ifcvf driver, then each VF will have a > Representor port. For now we don’t have port representor, so this patch set manages VF resource internally. Ok, we may need to have a vdev to represent the PF, but we need to be able to bind at VF level anyway. Else, how do you support passing two VFs of the same PF to different DPDK applications? Or have some VFs managed by Kernel or QEMU and some by the DPDK application? My feeling is that current implementation is creating an artificial constraint. Isn't there a possibility to have the virtual representation for the PF to be probed separately? Or created automatically when the first VF of a PF is probed (and later VFs attach to the PF rep when probed)? Doing this, we could use the generic device probing. For IFCVF, to specify we want it to be probed as an offload device instead of a virtio device, we could have a new EAL parameter to specify for a given device if we want it to be probed as an offload device (for example --offload=00:01.1). Offload drivers would register by passing a flag that specifies they are an offload driver. This new argument would be optional and only used to force the device to being probed in offload mode. For devices that have their own device IDs for offload mode, then it would be automatic. Regards, Maxime > BRs, > Xiao >