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

[Jerin Jacob]

On Thu, Jul 15, 2021 at 5:41 PM Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> 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.


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

>
> /Bruce