Re: [dpdk-dev] [PATCH v3] dmadev: introduce DMA device library

-----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;
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
+	 * 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'

API.

quoted

This shall also be part of capability.

Do you mean some silent mode? The application only needs to submit requests
to the
hardware.

Could you briefly describe the working principles and application scenarios of
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
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
indicate if DMA is complete or not.

quoted

quoted

+	struct rte_dmadev_port_parameters src_port;
+	/** 1) Used to describes the port parameter in the memory-to-device-to
+	 * transfer scenario.
+	 * 2) Used to describes the destination port parameter in the
+	 * device-to-device transfer scenario.
+	 * @see struct rte_dmadev_port_parameters
+	 */
+	struct rte_dmadev_port_parameters dst_port;
+};
+

<snip>

quoted

+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Enqueue a scatter list copy operation onto the virtual DMA channel.
+ *
+ * This queues up a scatter list copy operation to be performed by hardware,
+ * but does not trigger hardware to begin that operation.

This would need update with the submit flag.
The statement should be true only when the flag is set?
Similar comment I see on 'rte_dmadev_copy_sg' and 'rte_dma_fill' APIs

OK, will fix in V4

quoted

quoted

+ *
+ * @param dev_id
+ *   The identifier of the device.
+ * @param vchan
+ *   The identifier of virtual DMA channel.
+ * @param sg
+ *   The pointer of scatterlist.
+ * @param flags
+ *   An flags for this operation.
+ *   @see RTE_DMA_OP_FLAG_*
+ *
+ * @return
+ *   - 0..UINT16_MAX: index of enqueued copy scatterlist job.
+ *   - <0: Error code returned by the driver copy scatterlist function.
+ */
+__rte_experimental
+static inline int
+rte_dmadev_copy_sg(uint16_t dev_id, uint16_t vchan, const struct

rte_dma_sg

quoted

quoted

*sg,
+		   uint64_t flags)
+{
+	struct rte_dmadev *dev = &rte_dmadevices[dev_id];
+#ifdef RTE_DMADEV_DEBUG
+	if (!rte_dmadev_is_valid_dev(dev_id) ||
+	    vchan >= dev->data->dev_conf.max_vchans ||
+	    sg == NULL)
+		return -EINVAL;
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->copy_sg, -ENOTSUP);
+#endif
+	return (*dev->copy_sg)(dev, vchan, sg, flags);
+}
+

.