[dpdk-dev] [RFC 1/2] doc: introduction to prgdev

[Chen, Jing D]

Hi, Jan,


On 2/1/2017 7:41 PM, Jan Blunck wrote:
> On Fri, Jan 20, 2017 at 4:21 AM, Chen Jing D(Mark)
> <jing.d.chen at intel.com> wrote:
>> This is the documentation to describe what prgdev is, how to use
>> prgdev API and accomplish an image download.
>>
>> Signed-off-by: Chen Jing D(Mark) <jing.d.chen at intel.com>
>> ---
>>   doc/guides/prog_guide/prgdev_lib.rst |  457 ++++++++++++++++++++++++++++++++++
>>   1 files changed, 457 insertions(+), 0 deletions(-)
>>   create mode 100644 doc/guides/prog_guide/prgdev_lib.rst
>>
>> diff --git a/doc/guides/prog_guide/prgdev_lib.rst b/doc/guides/prog_guide/prgdev_lib.rst
>> new file mode 100644
>> index 0000000..3917c18
>> --- /dev/null
>> +++ b/doc/guides/prog_guide/prgdev_lib.rst
>> @@ -0,0 +1,457 @@
>> +Overview
>> +========
>> +
>> +More and more devices start to support on-die programming, which include
>> +NIC, GPU, FPGA, etc. This capability has a requirement to drivers that
>> +introduce a API for application to download/upload image to/from the HW.
>> +So, it's necessary to provide a generic API to perform image download, upload,
>> +validation, etc.
>> +
>> +This RFC patch intends to introduce a DPDK generic programming device layer,
>> +called prgdev below, to provide an abstract, generic APIs for applications to
>> +program hardware without knowing the details of programmable devices. From
>> +driver's perspective, they'll try to adapt their functions to the abstract
>> +APIs defined in prgdev.
>> +
>> +The major purpose of prgdev is to help DPDK users to load/upgrade RTL images
>> +for FPGA devices, or upgrade firmware for programmble NICs.
>> +
>> +But those devices that have the capability to do on-die programming may
>> +expose versatile talents to apps. Add/delete/update entries in flow table,
>> +update/overwrite the firmware/microcode, add a new algorithm, update profiles
>> +, etc, which is hard to be abstracted as generic behaviors. So, prgdev won't
>> +include the APIs to perform device-unique actions in current stage until it
>> +became popular. On the contratry, it only provides the simple capability to
>> +download a segment of buffer(image) from host to on-die device, or vice versa.
>> +The image could be an algorithm, a flow table in the on-die SRAM, a firmware
>> +image running in the device, a function within a pipeline, etc. prgdev won't
>> +try to inteprete the content and it's transparent to prgdev. Apps and devices
>> +can communicate with a language they can understand each other, which is not
>> +provided by prgdev to decide what needs to be programmed.
>> +
>> +When the set of APIs is introduced, a general question is why we need it in
>> +DPDK community? Why we can't use offline tool to perform same thing? The answer
>> +is the prgdev provide a generic, online API to applications, in the meanwile,
>> +offers a capability to switch driver dynamically when downloaded image changed
>> +personality and a new driver is required. Comparing offline tool, it have online
>> +programmability (see below examples); Comparing online tool, it provides a
>> +generic API for many HWs; Comparing generic online tool/API for many products,
>> +it provides a capability to switch driver dynamically.
>> +
>> +There are various means to reach same goal, we'll try to find the best/better
>> +way to approach. All above advantages will help prgdev to be a 'better choice'.
>> +
>  From my point of view this doesn't belong into the DPDK. On Linux this
> is traditionally handled by udev and you already have the freedom to
> use userspace applications to program a device requiring firmware in
> that case. I don't believe that modeling this in the DPDK explicitly
> is the right thing to do.

Can you kindly educate me what udev can do? It's for NIC firmware upgrade?
This prgdev is not only for NIC, the major use case is FPGA, but I found 
programmable
NIC is also applicable to the API model and can be added into the scope.

>
> Especially if the device supports changing personality it is required
> to unplug the existing personality before reprogramming. You can do
> this already today. Also writing OOB firmware data that changes
> configuration should be possible today by handling interrupts.

What if application is using DPDK, can we do in the same manner without 
leaving
DPDK instance?

> Maybe we can come up with an example application that demonstrates how
> the different infrastructure components could get orchestrated. Do you
> have a device in mind that supports this?

As Cunming suggested, the incoming FPGA is the desired device to use 
this API. OVS
that is using DPDK can benefit from the API and download personalities 
in running
time for blank FPGA, or upgrade for prior-programmed case.

>
> Regards,
> Jan