On Wed, Mar 21, 2018 at 7:05 PM, Bruce Richardson <bruce.richard...@intel.com> wrote: > 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 <rosen...@intel.com> >> > --- > <snip> >> + >> > +/* >> > + * 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.
In my opinion, its' not a problem that a heirarchichal bus model like this is implemented in DPDK. That's being creative :) But, here the issue is that same work can be done by a driver which can create devices of multiple types (bbdev, cryptodev, ethdev etc) and then use hotplugging (assuming that is supported by relevant driver) over respective bus. I don't think we necessarily need a bus for that. Is there some technical hurdle in following that model? Or, is there some cases which cannot be handled by not having a dependency bus? Then, there is another problem of modifying the rte_bus code so that this bus initialization can be delayed. That is something which is not right in my opinion. That puts a fixed constraint on the EAL to look for a bus as being special (like vdev). If that is a blocking problem, it too needs to be solved - maybe separately. Frankly, its not about 'can't-do-this' - but, I think this does warrant a good thought before being mainlined. > > 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
