> > > > > > > > No. DMA hardware would determine the pointer to the mbuf using > > > > iova address and mempool. Hardware will free the buffer, on > > > > completion of > > > data transfer. > > > > > > OK. If there are any requirements to the mempool, it needs to be > > > documented in the source code comments. E.g. does it work with > > > mempools where the mempool driver is an MP_RTS/MC_RTS ring, or a > stack? > > > > I think adding a comment, related to type of supported mempool, in dma > > library code might not be needed as it is driver implementation dependent. > > Call to dev->dev_ops->vchan_setup for the driver shall check and > > return error for unsupported type of mempool. > > Makes sense. But I still think that it needs to be mentioned that > RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE has some > limitations, and doesn't mean that any type of mempool can be used. > > I suggest you add a note to the description of the new "struct rte_mempool > *mem_to_dev_src_buf_pool" field in the rte_dma_vchan_conf structure, > such as: > > Note: If the mempool is not supported by the DMA driver, > rte_dma_vchan_setup() will fail. > > You should also mention it with the description of > RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE flag, such as: > > Note: Even though the DMA driver has this capability, it may not support all > mempool drivers. If the mempool is not supported by the DMA driver, > rte_dma_vchan_setup() will fail.
Sure, I will add a note in next version of the patch. Thanks.
