> > > > > > > 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.
