> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jerin Jacob > Sent: Thursday, 24 June 2021 09.03 > > On Wed, Jun 23, 2021 at 9:20 AM fengchengwen <fengcheng...@huawei.com> > wrote: > > > > > > > > > prototype like the following works for us: > > > rte_dmadev_enq_sg(void **src, void **dest, unsigned int **length, > int > > > nb_segments, cookie, ,,,) > > > > OK, we could define one scatter-list struct to wrap src/dest/length. > > > Inspired from following system call [1] > > [1] > https://man7.org/linux/man-pages/man2/process_vm_readv.2.html > > I propose the following style syntax for the sg list > > struct rte_dma_iovec { > void *iov_base; /* Starting address */ > size_t iov_len; /* Number of bytes to transfer */ > }; > > rte_dmadev_enq_sg(const struct rte_dma_iovec *src_iov, unsigned int > srcvcnt, > const struct rte_dma_iovec *dst_iov, unsigned int dstvcnt, ....) > > The reason for separating iov_len for src and dest is the many to one > case and > one to many cases. Example: > Copy of Multiple 2MB of 15 source segments to one 30MB dest. Quite use > full in storage use cases.
The process_vm_readv system call can do more than many-to-one and one-to-many. It allows copying three 4 MB source segments into four 3 MB destination segments or vice versa. I don't know if that is really necessary to support. We should consider limiting the DMA device API to only provide functions where we can present realistic DPDK application use cases. Otherwise it will be like the NIC device API, were every NIC vendor adds all sorts of exotic functions, only to expose their new and shiny NIC features in DPDK. (I'm exaggerating here - you get the point!) The main purpose of the DMA device API is to provide a common interface, so an application can call the same function, regardless of the different underlying hardware. If the API becomes too hardware specific, the API will just become a set of wrappers to specific hardware, and the application will need to consider which DMA device hardware is present and adapt its behavior accordingly. Just like RSS hash functions on the NICs; the application needs to adapt to which RSS hash functions the underlying NICs support. -Morten
