Re: [dpdk-dev] [PATCH v19 1/7] dmadev: introduce DMA device library public APIs

[fengchengwen <fengchengwen@huawei.com>]

I think we can add support for DIR_ANY.
@Bruce @Jerin Would you please take a look at my proposal?

On 2021/9/6 14:48, Gagandeep Singh wrote:
> 
> 
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Saturday, September 4, 2021 7:02 AM
>> To: Gagandeep Singh <G.Singh@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; Nipun Gupta
>> <nipun.gupta@nxp.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; conor.walsh@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
>>>