From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: [PATCH V2 3/5] Add Intel FPGA BUS Lib Code
Date: Wed, 21 Mar 2018 19:32:45 +0530
Message-ID: <CAJ5mUsW6ZxpWzGUWd6Tb6e+oG-iLu4TWnaYuEEMwT_1_Xa9o2w@mail.gmail.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>
 <20180321133509.GA15364@bricha3-MOBL.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= <gaetan.rivet@6wind.com>,
 Rosen Xu <rosen.xu@intel.com>, dev@dpdk.org, declan.doherty@intel.com,
 tianfei.zhang@intel.com, hao.wu@intel.com
To: Bruce Richardson <bruce.richardson@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from EUR01-HE1-obe.outbound.protection.outlook.com
 (mail-he1eur01on0040.outbound.protection.outlook.com [104.47.0.40])
 by dpdk.org (Postfix) with ESMTP id 125BC5F1A
 for <dev@dpdk.org>; Wed, 21 Mar 2018 15:03:20 +0100 (CET)
Received: by mail-wr0-f181.google.com with SMTP id s10so5301094wra.13
 for <dev@dpdk.org>; Wed, 21 Mar 2018 07:03:18 -0700 (PDT)
In-Reply-To: <20180321133509.GA15364@bricha3-MOBL.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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=C4=97tan 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 th=
e
> view that using a bus-type is the correct choice for this. While you coul=
d
> have a single device that creates other devices, that is also true for al=
l
> other buses as well.  [Furthermore, I think it is incorrect assume that a=
ll
> 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 scannin=
g
> for devices - which all use a common connection method - for DPDK use, an=
d
> mapping device drivers to those devices. For an FPGA device which present=
s
> multiple AFUs, this seems to be exactly what is required - a device drive=
r
> to scan for devices and present them to DPDK. The FPGA bus driver will ha=
ve
> 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 possibl=
e
> 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 ourselve=
s
> duplicating a lot of bus-related functionality inside the driver in that
> case.
>
> Regards,
> /Bruce