On 6/8/2021 7:34 AM, Thomas Monjalon wrote:

08/06/2021 06:10, Jerin Jacob:

quoted

On Mon, Jun 7, 2021 at 10:17 PM Thomas Monjalon [off-list ref] wrote:

quoted

07/06/2021 15:54, Jerin Jacob:

quoted

On Mon, Jun 7, 2021 at 4:13 PM Thomas Monjalon [off-list ref] wrote:

quoted

07/06/2021 09:20, Wang, Haiyue:

quoted

From: Honnappa Nagarahalli <redacted>

quoted

If we keep CXL in mind, I would imagine that in the future the devices on PCIe could have their own
local memory. May be some of the APIs could use generic names. For ex: instead of calling it as
"rte_gpu_malloc" may be we could call it as "rte_dev_malloc". This way any future device which hosts
its own memory that need to be managed by the application, can use these APIs.

"rte_dev_malloc" sounds a good name,

Yes I like the idea.
2 concerns:

1/ Device memory allocation requires a device handle.
So far we avoided exposing rte_device to the application.
How should we get a device handle from a DPDK application?

Each device behaves differently at this level. In the view of the
generic application, the architecture should like

< Use DPDK subsystem as rte_ethdev, rte_bbdev etc for SPECIFIC function >
^
|
< DPDK driver>
^
|
<rte_device with this new callbacks >

I think the formatting went wrong above.

I would add more to the block diagram:

class device API      - computing device API
        |            |              |
class device driver -   computing device driver
        |                           |
       EAL device with memory callback

The idea above is that the class device driver can use services
of the new computing device library.

Yes. The question is, do we need any public DPDK _application_ APIs for that?

To have something generic!

quoted

If it is public API then the scope is much bigger than that as the application
can use it directly and it makes it non portable.

It is a non-sense. If we make an API, it will be better portable.
The only part which is non-portable is the program on the device
which may be different per computing device.
The synchronization with the DPDK application should be portable
if we define some good API.

quoted

if the scope is only, the class driver consumption then the existing
"bus"  _kind of_
abstraction/API makes sense to me.

Where it abstracts,
-FW download of device
-Memory management of device
-Opaque way to enq/deque jobs to the device.

And above should be consumed by "class driver" not "application".

If the application doing do that, we are in rte_raw device territory.

I'm sorry I don't understand what you make such assertion.
It seems you don't want generic API (which is the purpose of DPDK).

The FW/kernel/"computing tasks" in the co-processor can be doing anything, as it
has been in FPGA/rawdev.

If there is no defined input & output of that computing task, an application
developed using it will be specific to that computing task, this is not portable
and feels like how rawdev works.

It is possible to have a generic API for control, to start the task and get
completion notification, but not having common input/output interface with
computing task still has same problem I think.

If the application is strictly depends to what computing task does, why not
extending rawdev to have the control APIs? Instead of new library.
And as you already said for memory, generic APIs can be used with additional
flags and using rawdev handler.

Or another option can be defining computing task a little more, have a common
interface, like mbuf, and add some capabilities/flags to let application know
more about computing task and give decision based on it, is this the intention?