> -----Original Message-----
> From: Jerin Jacob <jerinjac...@gmail.com>
> Sent: Thursday, July 15, 2021 6:02 PM
> To: Bruce Richardson <bruce.richard...@intel.com>
> Cc: Nipun Gupta <nipun.gu...@nxp.com>; fengchengwen
> <fengcheng...@huawei.com>; tho...@monjalon.net; ferruh.yi...@intel.com;
> jer...@marvell.com; andrew.rybche...@oktetlabs.ru; dev@dpdk.org;
> m...@smartsharesystems.com; Hemant Agrawal <hemant.agra...@nxp.com>;
> maxime.coque...@redhat.com; honnappa.nagaraha...@arm.com;
> david.march...@redhat.com; sbu...@marvell.com; pkap...@marvell.com;
> konstantin.anan...@intel.com; Gagandeep Singh <g.si...@nxp.com>
> Subject: Re: [PATCH v3] dmadev: introduce DMA device library
>
> On Thu, Jul 15, 2021 at 5:41 PM Bruce Richardson
> <bruce.richard...@intel.com> wrote:
> >
> > On Thu, Jul 15, 2021 at 11:16:54AM +0000, Nipun Gupta wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: fengchengwen <fengcheng...@huawei.com>
> > > > Sent: Thursday, July 15, 2021 1:59 PM
> > > > To: Nipun Gupta <nipun.gu...@nxp.com>; tho...@monjalon.net;
> > > > ferruh.yi...@intel.com; bruce.richard...@intel.com; jer...@marvell.com;
> > > > jerinjac...@gmail.com; andrew.rybche...@oktetlabs.ru
> > > > Cc: dev@dpdk.org; m...@smartsharesystems.com; Hemant Agrawal
> > > > <hemant.agra...@nxp.com>; maxime.coque...@redhat.com;
> > > > honnappa.nagaraha...@arm.com; david.march...@redhat.com;
> > > > sbu...@marvell.com; pkap...@marvell.com;
> konstantin.anan...@intel.com;
> > > > Gagandeep Singh <g.si...@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.
Agree, adding config for the device makes sense.
>
>
> +1 to add in config param ie. for the device.
>
> >
> > /Bruce
