Re: [dpdk-dev] [RFC PATCH] dmadev: introduce DMA device library

["Morten Brørup" <mb@smartsharesystems.com>]

> From: dev [mailto:dev-bounces@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.