[RFC PATCH] dmadev: offload to free source buffer

[Morten Brørup]

> From: Amit Prakash Shukla [mailto:amitprakashs at marvell.com]
> Sent: Wednesday, 9 August 2023 16.27
> 
> > From: Morten Brørup <mb at smartsharesystems.com>
> > Sent: Wednesday, August 9, 2023 2:37 PM
> >
> > > From: Amit Prakash Shukla [mailto:amitprakashs at marvell.com]
> > > Sent: Wednesday, 9 August 2023 08.09
> > >
> > > This changeset adds support in DMA library to free source DMA buffer
> > > by hardware. On a supported hardware, application can pass on the
> > > mempool information as part of vchan config when the DMA transfer
> > > direction is configured as RTE_DMA_DIR_MEM_TO_DEV.
> >
> > Isn't the DMA source buffer a memory area, and what needs to be freed
> is
> > the mbuf holding the memory area, i.e. two different pointers?
> No, it is same pointer. Assume mbuf created via mempool, mempool needs to
> be given via vchan config and iova passed to
> rte_dma_copy/rte_dma_copy_sg's can be any address in mbuf area of given
> mempool element.
> For example, mempool element size is S. dequeued buff from mempool is at
> X. Any address in (X, X+S) can be given as iova to rte_dma_copy.

So the DMA library determines the pointer to the mbuf (in the given mempool) by looking at the iova passed to rte_dma_copy/rte_dma_copy_sg, and then calls rte_mempool_put with that pointer?

> 
> >
> > I like the concept. Something similar might also be useful for
> > RTE_DMA_DIR_MEM_TO_MEM, e.g. packet capture. Although such a use
> > case might require decrementing the mbuf refcount instead of freeing
> the
> > mbuf directly to the mempool.
> This operation is not supported in our hardware. It can be implemented in
> future if any hardware supports it.

OK, I didn't expect that - just floating the idea. :-)

> 
> >
> > PS: It has been a while since I looked at the DMA library, so ignore my
> > comments if I got this wrong.