From: "Xu, Rosen" <rosen.xu@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
Ga?tan Rivet <gaetan.rivet@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Doherty, Declan" <declan.doherty@intel.com>,
"shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>,
"Zhang, Tianfei" <tianfei.zhang@intel.com>,
"Wu, Hao" <hao.wu@intel.com>
Subject: Re: [dpdk-dev] [PATCH V2 3/5] Add Intel FPGA BUS Lib Code
Date: Wed, 21 Mar 2018 14:06:33 +0000 [thread overview]
Message-ID: <0E78D399C70DA940A335608C6ED296D739F216E2@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <20180321133509.GA15364@bricha3-MOBL.ger.corp.intel.com>
-----Original Message-----
From: Richardson, Bruce
Sent: Wednesday, March 21, 2018 21:35
To: Gaëtan Rivet <gaetan.rivet@6wind.com>
Cc: Xu, Rosen <rosen.xu@intel.com>; dev@dpdk.org; Doherty, Declan <declan.doherty@intel.com>; shreyansh.jain@nxp.com; Zhang, Tianfei <tianfei.zhang@intel.com>; Wu, Hao <hao.wu@intel.com>
Subject: Re: [PATCH V2 3/5] Add Intel FPGA BUS Lib Code
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.
>
> 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.
In our FPGA Usage Framework, each FPAG Bitstream is divided 2 parts,
one part is only one Blue AFU, another part consist of many Green AFUs.
Blue AFU includes PCIe Interface and FPGA PR Unit, Blue AFU is fixed after
OS Initialization, because if we change Blue AFU, the PCIe Interface needed to be
rescanned and the OS need to reboot.
Green AFUs can be dynamically PR by different Users.
The benefit of this FPGA Architecture is that we can dynamically change Green AFUs,
but OS don't need to rescan the FPGA PCIe Interface. For Cloud Scenario the FPGA
Device can be viewed a common resource pools such as DDR Memory, and it can be easily
assigned to different users at some time. For TelCom/NFV Scenario, we can easily
upgrade the Acceleration AFU but the server don't need to reboot.
For Software Usage, there many FPGA Device in one system, some have the same
Green AFUs and some have different Green AFUs, same Green AFUs means same Acceleration,
and it will use same driver. So we want to involve a new bus,
which can easily bind the same Green AFUs with its driver.
Regards,
/Bruce
next prev parent reply other threads:[~2018-03-21 14:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 7:51 [dpdk-dev] [PATCH V2 0/5] Introduce Intel FPGA BUS Rosen Xu
2018-03-21 7:51 ` [dpdk-dev] [PATCH V2 1/5] Add Intel FPGA BUS Command Parse Code Rosen Xu
2018-03-21 7:51 ` [dpdk-dev] [PATCH V2 2/5] Add Intel FPGA BUS Probe Code Rosen Xu
2018-03-21 9:07 ` Shreyansh Jain
2018-03-21 9:10 ` Shreyansh Jain
2018-03-21 10:05 ` Gaëtan Rivet
2018-03-21 7:51 ` [dpdk-dev] [PATCH V2 3/5] Add Intel FPGA BUS Lib Code Rosen Xu
2018-03-21 9:28 ` Shreyansh Jain
2018-03-21 10:20 ` Gaëtan Rivet
2018-03-21 13:35 ` Bruce Richardson
2018-03-21 14:02 ` Shreyansh Jain
2018-03-21 14:06 ` Xu, Rosen [this message]
2018-03-21 14:14 ` Gaëtan Rivet
2018-03-21 14:31 ` Gaëtan Rivet
2018-03-21 15:41 ` Bruce Richardson
2018-03-21 16:21 ` Gaëtan Rivet
2018-03-21 7:51 ` [dpdk-dev] [PATCH V2 4/5] Add Intel FPGA BUS Rawdev Code Rosen Xu
2018-03-21 7:51 ` [dpdk-dev] [PATCH V2 5/5] Add Intel OPAE Share Code Rosen Xu
2018-03-21 10:00 ` [dpdk-dev] [PATCH V2 0/5] Introduce Intel FPGA BUS Gaëtan Rivet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0E78D399C70DA940A335608C6ED296D739F216E2@SHSMSX104.ccr.corp.intel.com \
--to=rosen.xu@intel.com \
--cc=bruce.richardson@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=hao.wu@intel.com \
--cc=shreyansh.jain@nxp.com \
--cc=tianfei.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).