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

[Jerin Jacob]

On Wed, Jun 23, 2021 at 12:47 AM Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> 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 at 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.

Ack

>
> /Bruce