> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > On Mon, Jun 7, 2021 at 4:13 PM Thomas Monjalon <tho...@monjalon.net> > wrote: > > > > 07/06/2021 09:20, Wang, Haiyue: > > > From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > > > > 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 > > > An implementation may decide to have "in tree" or "out of tree" > drivers or rte_device implementaion. > But generic DPDK applications should not use devices directly. i.e rte_device > need to have this callback and mlx ethdev/crypto driver use this driver to > implement public API. > Otherwise, it is the same as rawdev in DPDK. > So not sure what it brings other than raw dev here if we are not taking the > above architecture. Agree, I think it is important to hide the device under the APIs for the application to benefit.
> > > > > 2/ Implementation must be done in a driver. > > Should it be a callback defined at rte_device level? > > IMO, Yes and DPDK subsystem drivers to use it. > > > > > > then looks like we need to enhance the 'struct rte_device' with some > > > new ops as: > > > > > > eal: move DMA mapping from bus-specific to generic driver > > > > > > > https://patchwork.dpdk.org/project/dpdk/patch/20210331224547.2217759 > > > -1-tho...@monjalon.net/ > > > > Not sure the above patch is a good idea. > > Let's discuss this DMA detail later :) > > > > > >
