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

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Jun 22, 2021 at 11:01:47PM +0530, Jerin Jacob wrote:
> On Fri, Jun 18, 2021 at 3:25 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > >
> > Taking the case of a simple copy op, the parameters we need are:
> >
> > * src
> > * dst
> > * length
> 
> OK. Is it the case where no other attribute that supported in HW or
> you are not planning to
> expose that through DPDK generic DMA API.
> 
Only other parameters that might be needed can all be specified as flags,
so all we need for a copy op is a general flags field for future expansion.

> >
> > Depending on the specific hardware there will also be passed in the
> > descriptor a completion address, but we plan for these cases to always have
> > the completions written back to a set location so that we have essentially
> > ring-writeback, as with the hardware which doesn't explicitly have a
> > separate completion address. Beyond that, I believe the only descriptor
> > fields we will use are just the flags field indicating the op type etc.
> 
> OK. In HW, we need to have IOVA for completion address that's only the
> constraint. rest looks good to me.
> 
That's like what we have, but I was not planning on exposing the completion
address through the API at all, but have it internal to the driver and let
the "completion" APIs just inform the app what is done or not. If we expose
completion addresses, then that leaves the app open to having to parse
different completion formats, so it needs to be internal IMHO.

/Bruce