On Wed, Jun 23, 2021 at 12:47 AM Bruce Richardson <bruce.richard...@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.richard...@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
