> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of fengchengwen > Sent: Friday, 2 July 2021 15.45 > > On 2021/7/1 23:01, Jerin Jacob wrote: > >> [key point]: > >> ----------- ----------- > >> | channel | | channel | > >> ----------- ----------- > >> \ / > >> \ / > >> \ / > >> ------------ > >> | HW-queue | > >> ------------ > >> | > >> -------- > >> |rawdev| > >> -------- > >> 1) User could create one channel by init > context(dpi_dma_queue_ctx_s), > >> this interface is not standardized and needs to be > implemented by > >> users. > >> 2) Different channels can support different transmissions, > e.g. one for > >> inner m2m, and other for inbound copy. > >> > >> Overall, I think the 'channel' is similar the 'virt-queue' of > dpaa2_qdma. > >> The difference is that dpaa2_qdma supports multiple hardware > queues. The > >> 'channel' has following > > > > If dpaa2_qdma supports more than one HW queue, I think, it is good to > > have the queue notion > > in DPDK just like other DPDK device classes. It will be good to have > > confirmation from dpaa2 folks, @Hemant Agrawal, > > if there are really more than 1 HW queue in dppa device. > > > > > > IMO, Channel is a better name than a virtual queue. The reason is, > > virtual queue is more > > implementation-specific notation. No need to have this in API > specification. > > > > In the DPDK framework, many data-plane API names contain queues. e.g. > eventdev/crypto.. > The concept of virt queues has continuity.
I was also wondering about the name "virtual queue". Usually, something "virtual" would be an abstraction of something physical, e.g. a software layer on top of something physical. Back in the days, a "DMA channel" used to mean a DMA engine on a CPU. If a CPU had 2 DMA channels, they could both be set up simultaneously. The current design has the "dmadev" representing a CPU or other chip, which has one or more "HW-queues" representing DMA channels (of the same type), and then "virt-queue" as a software abstraction on top, for using a DMA channel in different ways through individually configured contexts (virt-queues). It makes sense to me, although I would consider renaming "HW-queue" to "channel" and perhaps "virt-queue" to "queue". These names are not important to me. You can keep them or change them; I am happy any way. But the names used for functions, types and parameters need to be cleaned up and match the names used in the documentation. E.g. rte_dmadev_queue_setup() does not set up a queue, it sets up a virt-queue, so that function name needs to be corrected. Also, the rte_ prefix is missing in a few places, e.g. struct dma_scatterlist and enum dma_address_type. Obviously not important for this high level discussion based on draft source code, but important for the final implementation. -Morten
