From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH V2 3/5] Add Intel FPGA BUS Lib Code Date: Wed, 21 Mar 2018 13:35:09 +0000 Message-ID: <20180321133509.GA15364@bricha3-MOBL.ger.corp.intel.com> References: <1521618694-140757-1-git-send-email-rosen.xu@intel.com> <1521618694-140757-4-git-send-email-rosen.xu@intel.com> <20180321102025.v2zeijxrsauuvkss@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Rosen Xu , dev@dpdk.org, declan.doherty@intel.com, shreyansh.jain@nxp.com, tianfei.zhang@intel.com, hao.wu@intel.com To: =?iso-8859-1?Q?Ga=EBtan?= Rivet Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 0DA365F34 for ; Wed, 21 Mar 2018 14:35:17 +0100 (CET) Content-Disposition: inline In-Reply-To: <20180321102025.v2zeijxrsauuvkss@bidouze.vm.6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Mar 21, 2018 at 11:20:25AM +0100, Gaëtan Rivet wrote: > Hi, > > I have had issues compiling a few things here, have you checked > build status before submitting? > > On Wed, Mar 21, 2018 at 03:51:32PM +0800, Rosen Xu wrote: > > Signed-off-by: Rosen Xu > > --- > + > > +/* > > + * Scan the content of the FPGA bus, and the devices in the devices > > + * list > > + */ > > So you seem to scan your bus by reading parameters > given to the --ifpga EAL option. > > Can you justify why you cannot use the PCI bus, have your FPGA be probed > by a PCI driver, that would take those parameters as driver parameters, > and spawn raw devices (one per bitstream) as needed as a result? > > I see no reason this is not feasible. Unless you duly justify this > approach, it seems unacceptable to me. You are subverting generic EAL > code to bend things to your approach, without clear rationale. > While I agree with the comments in other emails about avoiding special-cases in the code that makes things not-scalable, I would take the view that using a bus-type is the correct choice for this. While you could have a single device that creates other devices, that is also true for all other buses as well. [Furthermore, I think it is incorrect assume that all devices on the FPGA bus would be raw devices, it's entirely possible to have cryptodevs, bbdevs or compress devs implemented in the AFUs]. Consider what a bus driver provides: it's a generic mechanism for scanning for devices - which all use a common connection method - for DPDK use, and mapping device drivers to those devices. For an FPGA device which presents multiple AFUs, this seems to be exactly what is required - a device driver to scan for devices and present them to DPDK. The FPGA bus driver will have to check each AFU and match it against the set of registered AFU device drivers to ensure that the crypto AFU gets the cryptodev driver, etc. Logically, therefore, it is a bus - which just happens to be a sub-bus of PCI, i.e. presented as a PCI device. Consider also that it may be possible or even desirable, to use blacklisting and whitelisting for those AFU devices so that some AFUs could be used by one app, while others by another. If we just have a single PCI device, I think we'll find ourselves duplicating a lot of bus-related functionality inside the driver in that case. Regards, /Bruce