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

Bruce Richardson bruce.richardson at intel.com
Thu Jul 15 14:11:46 CEST 2021


On Thu, Jul 15, 2021 at 11:16:54AM +0000, Nipun Gupta wrote:
> 
> 
> > -----Original Message-----
> > From: fengchengwen <fengchengwen at huawei.com>
> > Sent: Thursday, July 15, 2021 1:59 PM
> > To: Nipun Gupta <nipun.gupta at nxp.com>; thomas at monjalon.net;
> > ferruh.yigit at intel.com; bruce.richardson at intel.com; jerinj at marvell.com;
> > jerinjacobk at gmail.com; andrew.rybchenko at oktetlabs.ru
> > Cc: dev at dpdk.org; mb at smartsharesystems.com; Hemant Agrawal
> > <hemant.agrawal at nxp.com>; maxime.coquelin at redhat.com;
> > honnappa.nagarahalli at arm.com; david.marchand at redhat.com;
> > sburla at marvell.com; pkapoor at marvell.com; konstantin.ananyev at intel.com;
> > Gagandeep Singh <G.Singh at 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.
> 
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.

/Bruce


More information about the dev mailing list