On Wed, Jun 16, 2021 at 04:48:59PM +0000, Honnappa Nagarahalli wrote:

<snip>

quoted

On Wed, Jun 16, 2021 at 02:14:54PM +0200, David Marchand wrote:

quoted

On Tue, Jun 15, 2021 at 3:25 PM Chengwen Feng

[off-list ref] wrote:

quoted

quoted

+
+#define RTE_DMADEV_NAME_MAX_LEN        (64)
+/**< @internal Max length of name of DMA PMD */
+
+/** @internal
+ * The data structure associated with each DMA device.
+ */
+struct rte_dmadev {
+       /**< Device ID for this instance */
+       uint16_t dev_id;
+       /**< Functions exported by PMD */
+       const struct rte_dmadev_ops *dev_ops;
+       /**< Device info. supplied during device initialization */
+       struct rte_device *device;
+       /**< Driver info. supplied by probing */
+       const char *driver_name;
+
+       /**< Device name */
+       char name[RTE_DMADEV_NAME_MAX_LEN]; } __rte_cache_aligned;
+

I see no queue/channel notion.
How does a rte_dmadev object relate to a physical hw engine?

One queue, one device.
When looking to update the ioat driver for 20.11 release when I added the
idxd part, I considered adding a queue parameter to the API to look like one
device with multiple queues. However, since each queue acts completely
independently of each other, there was no benefit to doing so. It's just easier
to have a single id to identify a device queue.

Does it mean, the queue is multi thread safe? Do we need queues per core to avoid locking?

The design is for each queue to be like the queue on a NIC, not
thread-safe. However, if the hardware supports thread-safe queues too, that
can be supported. But the API should be like other data-plane ones and be
lock free.

For the DMA devices that I am working on, the number of queues
is not very large, and in most cases each queue appears as a separate
entity, e.g. for ioat each queue/channel appears as a separate PCI ID, and
when using idxd kernel driver each queue is a separate dev node to mmap.
For other cases right now we just create one rawdev instance per queue in
software.

/Bruce