From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6590A426DE; Sat, 7 Oct 2023 11:00:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 054DA402DA; Sat, 7 Oct 2023 11:00:51 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 4722B40293 for ; Sat, 7 Oct 2023 11:00:48 +0200 (CEST) Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4S2fMt4NHfz1P7tC; Sat, 7 Oct 2023 16:58:18 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Sat, 7 Oct 2023 17:00:46 +0800 Subject: Re: [PATCH v3 1/2] dmadev: offload to free source buffer To: Amit Prakash Shukla , Kevin Laatz , Bruce Richardson CC: , , , , , , , , , , References: <20230926121747.4037154-1-amitprakashs@marvell.com> <20230928115031.259592-1-amitprakashs@marvell.com> <20230928115031.259592-2-amitprakashs@marvell.com> From: fengchengwen Message-ID: <655af04b-4410-79f4-8ea7-bfd8c56ef0fc@huawei.com> Date: Sat, 7 Oct 2023 17:00:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20230928115031.259592-2-amitprakashs@marvell.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Amit, On 2023/9/28 19:50, Amit Prakash Shukla wrote: > This changeset adds support in DMA library to free source DMA buffer by > hardware. On a supported hardware, application can pass on the mempool > information as part of vchan config when the DMA transfer direction is > configured as RTE_DMA_DIR_MEM_TO_DEV. > > Signed-off-by: Amit Prakash Shukla > Acked-by: Morten Brørup > Acked-by: Anoob Joseph > --- > lib/dmadev/rte_dmadev.h | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h > index b157ab7600..f7a6af2528 100644 > --- a/lib/dmadev/rte_dmadev.h > +++ b/lib/dmadev/rte_dmadev.h > @@ -278,6 +278,13 @@ int16_t rte_dma_next_dev(int16_t start_dev_id); > #define RTE_DMA_CAPA_OPS_COPY_SG RTE_BIT64(33) > /** Support fill operation. */ > #define RTE_DMA_CAPA_OPS_FILL RTE_BIT64(34) > +/** Support for source buffer free for mem to dev transfer. Support auto free source buffer once the M2D (memory-to-device) transfer completed. > + * > + * @note Even though the DMA driver has this capability, it may not support all > + * mempool drivers. If the mempool is not supported by the DMA driver, > + * rte_dma_vchan_setup() will fail. In addition to hardware support, there are requirements for buffer attribute (e.g. only specific mempool support it). > + **/ > +#define RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE RTE_BIT64(35) 1) this should follow RTE_DMA_CAPA_HANDLES_ERRORS, because it not new OPS. 2) the name is too long. how abort RTE_DMA_CAPA_AUTO_FREE_M2D_SBUF? I am not sure, suggest get better name. > /**@}*/ > > /** > @@ -581,6 +588,19 @@ struct rte_dma_vchan_conf { > * @see struct rte_dma_port_param > */ > struct rte_dma_port_param dst_port; > + /** Mempool from which source buffer is allocated. Mempool info is used > + * for freeing source buffer by hardware when configured direction is > + * RTE_DMA_DIR_MEM_TO_DEV. To free the source buffer by hardware, > + * RTE_DMA_OP_FLAG_FREE_SBUF must be set while calling rte_dma_copy and > + * rte_dma_copy_sg(). > + * > + * @note If the mempool is not supported by the DMA device, > + * rte_dma_vchan_setup() will fail. > + * > + * @see RTE_DMA_OP_FLAG_FREE_SBUF > + */ > + struct rte_mempool *mem_to_dev_src_buf_pool; > + > }; Suggest add one extra struct e.g. struct rte_dma_auto_free_param { union { struct rte_mempool *pool; } uint64_t reserved[2]; /**< Reserved for future fields. */ }; In the above conf, we could add a new field: struct rte_dma_auto_free_param m2d_buf > > /** > @@ -818,6 +838,13 @@ struct rte_dma_sge { > * capability bit for this, driver should not return error if this flag was set. > */ > #define RTE_DMA_OP_FLAG_LLC RTE_BIT64(2) > +/** Mem to dev source buffer free flag. > + * Used for freeing source DMA buffer by hardware when the transfer direction is > + * configured as RTE_DMA_DIR_MEM_TO_DEV. > + * > + * @see struct rte_dma_vchan_conf::mem_to_dev_src_buf_pool > + */ > +#define RTE_DMA_OP_FLAG_FREE_SBUF RTE_BIT64(3) Suggest RTE_DMA_OP_FLAG_AUTO_FREE_SBUF > /**@}*/ > > /** > The S in SBUF seem useless, because it should not auto free dstbuf in logically. Maybe we should direct use auto-free (just like silent)