> -----Original Message-----
> From: fengchengwen <fengcheng...@huawei.com>
> Sent: Saturday, September 4, 2021 7:02 AM
> To: Gagandeep Singh <g.si...@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; Nipun Gupta
> <nipun.gu...@nxp.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; conor.wa...@intel.com
> Subject: Re: [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library
> public APIs
>
> On 2021/9/3 19:42, Gagandeep Singh wrote:
> > Hi,
> >
> > <snip>
> >> +
> >> +/**
> >> + * @warning
> >> + * @b EXPERIMENTAL: this API may change without prior notice.
> >> + *
> >> + * Close a DMA device.
> >> + *
> >> + * The device cannot be restarted after this call.
> >> + *
> >> + * @param dev_id
> >> + * The identifier of the device.
> >> + *
> >> + * @return
> >> + * 0 on success. Otherwise negative value is returned.
> >> + */
> >> +__rte_experimental
> >> +int
> >> +rte_dmadev_close(uint16_t dev_id);
> >> +
> >> +/**
> >> + * rte_dma_direction - DMA transfer direction defines.
> >> + */
> >> +enum rte_dma_direction {
> >> + RTE_DMA_DIR_MEM_TO_MEM,
> >> + /**< DMA transfer direction - from memory to memory.
> >> + *
> >> + * @see struct rte_dmadev_vchan_conf::direction
> >> + */
> >> + RTE_DMA_DIR_MEM_TO_DEV,
> >> + /**< DMA transfer direction - from memory to device.
> >> + * In a typical scenario, the SoCs are installed on host servers as
> >> + * iNICs through the PCIe interface. In this case, the SoCs works in
> >> + * EP(endpoint) mode, it could initiate a DMA move request from
> >> memory
> >> + * (which is SoCs memory) to device (which is host memory).
> >> + *
> >> + * @see struct rte_dmadev_vchan_conf::direction
> >> + */
> >> + RTE_DMA_DIR_DEV_TO_MEM,
> >> + /**< DMA transfer direction - from device to memory.
> >> + * In a typical scenario, the SoCs are installed on host servers as
> >> + * iNICs through the PCIe interface. In this case, the SoCs works in
> >> + * EP(endpoint) mode, it could initiate a DMA move request from device
> >> + * (which is host memory) to memory (which is SoCs memory).
> >> + *
> >> + * @see struct rte_dmadev_vchan_conf::direction
> >> + */
> >> + RTE_DMA_DIR_DEV_TO_DEV,
> >> + /**< DMA transfer direction - from device to device.
> >> + * In a typical scenario, the SoCs are installed on host servers as
> >> + * iNICs through the PCIe interface. In this case, the SoCs works in
> >> + * EP(endpoint) mode, it could initiate a DMA move request from device
> >> + * (which is host memory) to the device (which is another host memory).
> >> + *
> >> + * @see struct rte_dmadev_vchan_conf::direction
> >> + */
> >> +};
> >> +
> >> +/**
> >> ..
> > The enum rte_dma_direction must have a member RTE_DMA_DIR_ANY for a
> channel that supports all 4 directions.
>
> We've discussed this issue before. The earliest solution was to set up
> channels to
> support multiple DIRs, but
> no hardware/driver actually used this (at least at that time). they (like
> octeontx2_dma/dpaa) all setup one logic
> channel server single transfer direction.
>
> So, do you have that kind of desire for your driver ?
>
Both DPAA1 and DPAA2 drivers can support ANY direction on a channel, so we
would like to have this option as well.
>
> If you have a strong desire, we'll consider the following options:
>
> Once the channel was setup, there are no other parameters to indicate the copy
> request's transfer direction.
> So I think it is not enough to define RTE_DMA_DIR_ANY only.
>
> Maybe we could add RTE_DMA_OP_xxx marco
> (RTE_DMA_OP_FLAG_M2M/M2D/D2M/D2D), these macro will as the flags
> parameter
> passsed to enqueue API, so the enqueue API knows which transfer direction the
> request corresponding.
>
> We can easily expand from the existing framework with following:
> a. define capability RTE_DMADEV_CAPA_DIR_ANY, for those device which
> support it could declare it.
> b. define direction macro: RTE_DMA_DIR_ANY
> c. define dma_op: RTE_DMA_OP_FLAG_DIR_M2M/M2D/D2M/D2D which will
> passed as the flags parameters.
>
> For that driver which don't support this feature, just don't declare support
> it, and
> framework ensure that
> RTE_DMA_DIR_ANY is not passed down, and it can ignored
> RTE_DMA_OP_FLAG_DIR_xxx flag when enqueue API.
>
> For that driver which support this feature, application could create one
> channel
> with RTE_DMA_DIR_ANY or RTE_DMA_DIR_MEM_TO_MEM.
> If created with RTE_DMA_DIR_ANY, the RTE_DMA_OP_FLAG_DIR_xxx should be
> sensed in the driver.
> If created with RTE_DMA_DIR_MEM_TO_MEM, the
> RTE_DMA_OP_FLAG_DIR_xxx could be ignored.
>
Your design looks ok to me.
>
> > <snip>
> >
> >
> > Regards,
> > Gagan
> >
