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

[Liang, Cunming]

On 1/20/2017 11:21 AM, Chen Jing D(Mark) 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
> +========
> +
[...]
> +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'.
> +
>
One more notes.
DPDK takes over the devices in user space. The legacy tools usually 
download the personality by kernel driver. They runs out of DPDK 
context. When a DPDK process is running on top of the device, operation 
to the device by the solo tool during the time causes resource conflict. 
It's one of the motivations to have the native API allowing programming 
the personality within DPDK context. Otherwise, it has to exit the 
process if any personality change is required. Manually detaching the 
device before using the solo tool may ease the conflict. However it 
still limits the situation if the device allows multiple programmable 
instances(e.g. AFUs in FPGA) which are working independently and 
shouldn't be impact by each other.


[...]