> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of fengchengwen > Sent: Wednesday, 16 June 2021 12.17 > > On 2021/6/16 15:09, Morten Brørup wrote: > > I would like to share a couple of ideas for further discussion: > > > > 1. API for bulk operations. > > The ability to prepare a vector of DMA operations, and then post it > to the DMA driver. > > We consider bulk operation and final decide not to support: > 1. The DMA engine don't applicable to small-packet scenarios which have > high PPS. > PS: The vector is suitable for high PPS. > 2. To support post bulk ops, we need define standard struct like > rte_mbuf, and > application may nned init the struct field and pass them as pointer > array, > this may cost too much CPU. > 3. The post request was simple than process completed operations, The > CPU write > performance is also good. ---driver could use vectors to accelerate > the process > of completed operations.
OK. Thank you for elaborating. > > > > 2. Prepare the API for more complex DMA operations than just > copy/fill. > > E.g. blitter operations like "copy A bytes from the source starting > at address X, to the destination starting at address Y, masked with the > bytes starting at address Z, then skip B bytes at the source and C > bytes at the destination, rewind the mask to the beginning of Z, and > repeat D times". This is just an example. > > I'm suggesting to use a "DMA operation" union structure as parameter > to the command enqueue function, rather than having individual > functions for each possible DMA operation. > > There are many sisution which may hard to define such structure, I > prefer separates API like copy/fill/... > PS: I saw struct dma_device (Linux dmaengine.h) also support various > prep_xxx API. OK. Separate functions make sense if the DMA driver does not support a large variety of operations, but only copy and fill.
