[dpdk-dev] dmadev discussion summary

[Morten Brørup]

> From: dev [mailto:dev-bounces at 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