-----Original Message-----
From: Jerin Jacob <redacted>
Sent: Thursday, July 15, 2021 6:02 PM
To: Bruce Richardson <redacted>
Cc: Nipun Gupta <redacted>; fengchengwen
[off-list ref]; thomas@monjalon.net; ferruh.yigit@intel.com;
jerinj@marvell.com; andrew.rybchenko@oktetlabs.ru; dev@dpdk.org;
mb@smartsharesystems.com; Hemant Agrawal [off-list ref];
maxime.coquelin@redhat.com; honnappa.nagarahalli@arm.com;
david.marchand@redhat.com; sburla@marvell.com; pkapoor@marvell.com;
konstantin.ananyev@intel.com; Gagandeep Singh [off-list ref]
Subject: Re: [PATCH v3] dmadev: introduce DMA device library

On Thu, Jul 15, 2021 at 5:41 PM Bruce Richardson
[off-list ref] wrote:

quoted

On Thu, Jul 15, 2021 at 11:16:54AM +0000, Nipun Gupta wrote:

quoted

quoted

-----Original Message-----
From: fengchengwen <redacted>
Sent: Thursday, July 15, 2021 1:59 PM
To: Nipun Gupta <redacted>; thomas@monjalon.net;
ferruh.yigit@intel.com; bruce.richardson@intel.com; jerinj@marvell.com;
jerinjacobk@gmail.com; andrew.rybchenko@oktetlabs.ru
Cc: dev@dpdk.org; mb@smartsharesystems.com; Hemant Agrawal
[off-list ref]; maxime.coquelin@redhat.com;
honnappa.nagarahalli@arm.com; david.marchand@redhat.com;
sburla@marvell.com; pkapoor@marvell.com;

konstantin.ananyev@intel.com;

quoted

quoted

quoted

Gagandeep Singh [off-list ref]
Subject: Re: [PATCH v3] dmadev: introduce DMA device library

On 2021/7/14 20:22, Nipun Gupta wrote:

quoted

<snip>

quoted

+/**
+ * A structure used to configure a virtual DMA channel.
+ */
+struct rte_dmadev_vchan_conf {
+        uint8_t direction;
+        /**< Set of supported transfer directions
+         * @see RTE_DMA_MEM_TO_MEM
+         * @see RTE_DMA_MEM_TO_DEV
+         * @see RTE_DMA_DEV_TO_MEM
+         * @see RTE_DMA_DEV_TO_DEV
+         */
+        /** Number of descriptor for the virtual DMA channel */
+        uint16_t nb_desc;
+        /** 1) Used to describes the port parameter in the device-to-

memory

quoted

quoted

quoted

quoted

quoted

+         * transfer scenario.
+         * 2) Used to describes the source port parameter in the
+         * device-to-device transfer scenario.
+         * @see struct rte_dmadev_port_parameters
+         */

There should also be a configuration to support no response (per Virtual

Channel),

quoted

And if that is enabled, user will not be required to call

'rte_dmadev_completed'

quoted

quoted

quoted

API.

quoted

This shall also be part of capability.

Do you mean some silent mode? The application only needs to submit

requests

quoted

quoted

quoted

to the
hardware.

Could you briefly describe the working principles and application scenarios

of

quoted

quoted

quoted

the
corresponding device?

It is kind of a silent mode w.r.t. the command completion from QDMA.

There could be level of synchronization in the applications at a higher level

due

quoted

quoted

To which QDMA status dequeue would not be necessary and be an overhead.
In this mode extra data/bytes could be passed with DMA which would

indirectly

quoted

quoted

indicate if DMA is complete or not.

I'm wondering if such a setting could be per-device (i.e. per HW queue)
rather than per virtual channel? Something like this would be easier to
support in that way, because we could use different function pointers for
the fastpath operations depending on whether completions are to be tracked
or not. For example: only occasional descriptors will need completion
addresses specified in the "enqueue" calls, and the "submit" function would
also do any ring cleanup that would otherwise be done by "completed" call.
Having separate function calls would reduce the number of branches that
need to be evaluated in this mode, as well as simplifying the code.

Agree, adding config for the device makes sense.

+1 to add in config param ie. for the device.

quoted

/Bruce