Re: [dpdk-dev] [PATCH v3 0/9] GPU library

[Jerin Jacob <jerinjacobk@gmail.com>]

>
> >
>
> > > He wants only feature-specific API.
>
> >
>
> > To re-reiterate, feature-specific "application" API. A device-specific
>
> > bit can be
>
> > driver API and accessible to the out-of-tree driver if needed.
>
> >
>
> > IMO, if we take this path, DPU, XPU, GPU, etc we need N different libraries to
>
> > get the job done for a specific feature for the dataplane.
>
> > Instead, Enabling public feature APIs will make the application
>
> > portable and does not
>
> > need to worry about which type of *PU it runs.
>
> >
>
>
>
> As I stated multiple times, let’s start with something simple that works and
>
> then think about how to enhance the library/driver.

I have submitted RFC[1] to abstract in a generic way so that
workload-specific _driver_ aspects are NOT EXPOSED to the application.

The RFC explains with application code, how any workload can be used
by the application without exposing the driver details.
Also, shows how to enable a framework to abstract a different form of
workload acceletor(DPU, GPU, XPU, IPU....)

In order to map to this discussion with RFC:
You may need to add a new host port for GPU which as
lib/dwa/rte_dwa_port_host_xxxxx.h and adding new workload as
lib/dwa/rte_dwa_profile_xxxx.h(Which can be reused by
all dataplane workload accelerator)



[1]
http://mails.dpdk.org/archives/dev/2021-October/226070.html


>
> IMHO it doesn’t make sense to address all the use-cases now.
>
> This is a completely new scenario we’re opening in the DPDK context, let’s start
>
> from the basis.