> From: Amit Prakash Shukla [mailto:amitpraka...@marvell.com] > Sent: Wednesday, 9 August 2023 16.27 > > > From: Morten Brørup <m...@smartsharesystems.com> > > Sent: Wednesday, August 9, 2023 2:37 PM > > > > > From: Amit Prakash Shukla [mailto:amitpraka...@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.
