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

[Liang, Cunming]

Hi,


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
[...]
>  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.
Good point, but not sure udev has user space device driver support or not.
>
> 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.

It's going to allow changing personality in DPDK user space runtime.

If the personality is not belong to a device but part of the component, 
unplug isn't helpful too much.

>
> 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?

The coming Purley platform has SKU for Xeon-FPGA.

The FPGA connecting with Xeon has dedicated pcie device id.

The AFU personality for packet I/O depends on the RTL image.

Changing the personality in runtime could be one of the situation.



Regards,

Cunming

>
> Regards,
> Jan
>
[...]