Re: [PATCH V2 3/5] Add Intel FPGA BUS Lib Code

[Shreyansh Jain <shreyansh.jain@nxp.com>]

On Wed, Mar 21, 2018 at 7:05 PM, Bruce Richardson
<bruce.richardson@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.xu@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