From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of fengchengwen
Sent: Friday, 2 July 2021 15.45

On 2021/7/1 23:01, Jerin Jacob wrote:

quoted

quoted

  [key point]:
      -----------    -----------
      | channel |    | channel |
      -----------    -----------
             \           /
              \         /
               \       /
             ------------
             | HW-queue |
             ------------
                   |
                --------
                |rawdev|
                --------
      1) User could create one channel by init

context(dpi_dma_queue_ctx_s),

quoted

quoted

         this interface is not standardized and needs to be

implemented by

quoted

quoted

         users.
      2) Different channels can support different transmissions,

e.g. one for

quoted

quoted

         inner m2m, and other for inbound copy.

      Overall, I think the 'channel' is similar the 'virt-queue' of

dpaa2_qdma.

quoted

quoted

      The difference is that dpaa2_qdma supports multiple hardware

queues. The

quoted

quoted

      '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.

quoted

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