03/06/2021 10:47, Jerin Jacob:

On Thu, Jun 3, 2021 at 2:13 PM Thomas Monjalon [off-list ref] wrote:

quoted

03/06/2021 10:41, Jerin Jacob:

quoted

On Thu, Jun 3, 2021 at 1:58 PM Thomas Monjalon [off-list ref] wrote:

quoted

03/06/2021 09:47, Jerin Jacob:

quoted

On Thu, Jun 3, 2021 at 2:05 AM Thomas Monjalon [off-list ref] wrote:

quoted

--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md

@@ -21,6 +21,7 @@ The public API headers are grouped by topics:
   [compressdev]        (@ref rte_compressdev.h),
   [compress]           (@ref rte_comp.h),
   [regexdev]           (@ref rte_regexdev.h),
+  [gpudev]             (@ref rte_gpudev.h),

Since this device does not have a queue etc? Shouldn't make it a
library like mempool with vendor-defined ops?
Any specific reason for making it a device? The reason why I am asking
this is, as other DPDK devices as symmetry in queue(s), configure,
start, stop operation etc.

quoted

+
+struct rte_gpu_dev {
+       /* Backing device. */
+       struct rte_device *device;

See above?

There is a PCI device probed.
I don't understand why it would not be represented as a device.

All other DPDK device has symmetry in structures like queue and
symmetry in operation like it has configure, start, stop etc.
This one seems more like mempool to me all we want set of
vendor-defined ops. So any justification on
make it a device ? why not like mempool library?
(driver/mempool/octeontx2 Mempool HW is also PCI device, but
we don't take device path for mempool. So I would like to understand
any technical reason for making it a device).

I don't understand what you mean by "symmetry".

The common attributes. or similarity

The common attributes of a device are:
	- driver
	- bus
	- devargs
We have these attributes for a GPU.

About configure/start/stop usual functions,
I think we'll have something similar in the second step
for running tasks.