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 8D7D54301B; Thu, 10 Aug 2023 11:32:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 275F040DFB; Thu, 10 Aug 2023 11:32:49 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 6D7EB40DD8 for ; Thu, 10 Aug 2023 11:32:47 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 394CE205F5; Thu, 10 Aug 2023 11:32:46 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC PATCH] dmadev: offload to free source buffer Date: Thu, 10 Aug 2023 11:32:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87AE0@smartserver.smartshare.dk> In-Reply-To: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC PATCH] dmadev: offload to free source buffer Thread-Index: AQHZyof4Da72IaSPrUSnTi7I079uxa/hrKoAgABV8CCAAAcykIAANhOggAEDhCA= References: <20230809060835.2030833-1-amitprakashs@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35D87AD9@smartserver.smartshare.dk> A <98CBD80474FA8B44BF855DF32C47DC35D87ADF@smartserver.smartshare.dk> A From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Amit Prakash Shukla" , "Chengwen Feng" , "Kevin Laatz" , "Bruce Richardson" Cc: , "Jerin Jacob Kollanukkaran" , , "Vamsi Krishna Attunuru" , , , , , "Nithin Kumar Dabilpuram" , "Anoob Joseph" 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 > From: Amit Prakash Shukla [mailto:amitprakashs@marvell.com] > Sent: Wednesday, 9 August 2023 20.12 >=20 > > From: Morten Br=F8rup > > Sent: Wednesday, August 9, 2023 8:19 PM > > > > > From: Amit Prakash Shukla [mailto:amitprakashs@marvell.com] > > > Sent: Wednesday, 9 August 2023 16.27 > > > > > > > From: Morten Br=F8rup > > > > Sent: Wednesday, August 9, 2023 2:37 PM > > > > > > > > > From: Amit Prakash Shukla [mailto:amitprakashs@marvell.com] > > > > > Sent: Wednesday, 9 August 2023 08.09 > > > > > > > > > > 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. > > > > > > > > Isn't the DMA source buffer a memory area, and what needs to be > > > > freed > > > is > > > > the mbuf holding the memory area, i.e. two different pointers? > > > No, it is same pointer. Assume mbuf created via mempool, mempool = needs > > > to be given via vchan config and iova passed to > > > rte_dma_copy/rte_dma_copy_sg's can be any address in mbuf area of > > > given mempool element. > > > For example, mempool element size is S. dequeued buff from mempool = is > > > at X. Any address in (X, X+S) can be given as iova to = rte_dma_copy. > > > > So the DMA library determines the pointer to the mbuf (in the given > > mempool) by looking at the iova passed to = rte_dma_copy/rte_dma_copy_sg, > > and then calls rte_mempool_put with that pointer? >=20 > No. DMA hardware would determine the pointer to the mbuf using iova = address > and mempool. Hardware will free the buffer, on completion of data = transfer. OK. If there are any requirements to the mempool, it needs to be = documented in the source code comments. E.g. does it work with mempools = where the mempool driver is an MP_RTS/MC_RTS ring, or a stack? >=20 > > > > > > > > > > > > > I like the concept. Something similar might also be useful for > > > > RTE_DMA_DIR_MEM_TO_MEM, e.g. packet capture. Although such a use > > > > case might require decrementing the mbuf refcount instead of = freeing > > > the > > > > mbuf directly to the mempool. > > > This operation is not supported in our hardware. It can be = implemented > > > in future if any hardware supports it. > > > > OK, I didn't expect that - just floating the idea. :-) > > > > > > > > > > > > > PS: It has been a while since I looked at the DMA library, so = ignore > > > > my comments if I got this wrong.