On Mon, Jun 09, 2025 at 10:03:33AM +0000, Pavan Nikhilesh Bhagavatula wrote: > Hi Bruce, > > >On Sat, May 24, 2025 at 02:43:10PM +0530, [email protected] wrote: > >> From: Pavan Nikhilesh <[email protected]> > >> > >> Introduce DMA enqueue/dequeue operations to the DMA device library. > >> > >> Add configuration flags to rte_dma_config instead of boolean for > >> individual features. > >> > >> The enqueue/dequeue operations allow applications to communicate with the > >> DMA device using the rte_dma_op structure, providing a more flexible and > >> efficient way to manage DMA operations. > >> > > > >While I have no really strong objections to this addition to the dmadev > >API, I'd appreciate if you could explain WHY or how this method of working > >is more efficient in your usecase? When designing the dmadev APIs > >originally, we looked at using both an enqueue-type API as well as the > >implemented individual-op-based APIs. IIRC at that time testing showed that > >using the single ops directly was faster than using the enqueue APIs, so > >I'm wondering what exactly has changed, or is different about your usecase? > > > > Here is an example where we see enqueue/dequeue ops to be useful especially > when > integrating with Graph library. > > We had to write an entire wrapper[1] for tracking sges with the current > implementation > making our nodes[2] very complex. >
Can you explain a bit more here. Why do you need the wrapper rather than just tracking in a circular ring all the copies offloaded? How does having an enqueue API make this better? Can you perhaps give a trivial example showing the difference it makes here? The examples you give below are rather long to understand quickly. Thanks, /Bruce > [1]https://github.com/MarvellEmbeddedProcessors/dao/blob/dao-devel/lib/common/dao_dma.h > [2]https://github.com/MarvellEmbeddedProcessors/dao/blob/3f364261de91e355699bd9af20d60ea6459f7d67/lib/virtio_net/virtio_net_deq_ext.c#L51 > > >/Bruce > > Thanks, > Pavan. >
