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.c...@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.
[...]
