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

[Nipun Gupta <nipun.gupta@nxp.com>]

> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Thursday, July 15, 2021 1:59 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; 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
> <hemant.agrawal@nxp.com>; maxime.coquelin@redhat.com;
> honnappa.nagarahalli@arm.com; david.marchand@redhat.com;
> sburla@marvell.com; pkapoor@marvell.com; konstantin.ananyev@intel.com;
> Gagandeep Singh <G.Singh@nxp.com>
> Subject: Re: [PATCH v3] dmadev: introduce DMA device library
> 
> On 2021/7/14 20:22, Nipun Gupta wrote:
> > <snip>
> >
> >> +/**
> >> + * 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),
> > And if that is enabled, user will not be required to call 'rte_dmadev_completed'
> API.
> > 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.

> 
> >
> >> +	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>
> >
> >> +/**
> >> + * @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
> 
> >
> >> + *
> >> + * @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
> >> *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);
> >> +}
> >> +
> >
> > .
> >