From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Amit Prakash Shukla" <amitprakashs@marvell.com>,
"Chengwen Feng" <fengchengwen@huawei.com>,
"Kevin Laatz" <kevin.laatz@intel.com>,
"Bruce Richardson" <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>, "Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
<conor.walsh@intel.com>,
"Vamsi Krishna Attunuru" <vattunuru@marvell.com>,
<g.singh@nxp.com>, <sachin.saxena@oss.nxp.com>,
<hemant.agrawal@nxp.com>, <cheng1.jiang@intel.com>,
"Nithin Kumar Dabilpuram" <ndabilpuram@marvell.com>,
"Anoob Joseph" <anoobj@marvell.com>
Subject: RE: [RFC PATCH] dmadev: offload to free source buffer
Date: Thu, 10 Aug 2023 13:35:23 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87AE1@smartserver.smartshare.dk> (raw)
In-Reply-To: <PH0PR18MB5167FB26D45AC41671518D9FC813A@PH0PR18MB5167.namprd18.prod.outlook.com>
> From: Amit Prakash Shukla [mailto:amitprakashs@marvell.com]
> Sent: Thursday, 10 August 2023 12.28
>
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Thursday, August 10, 2023 3:03 PM
> >
> > > From: Amit Prakash Shukla [mailto:amitprakashs@marvell.com]
> > > Sent: Wednesday, 9 August 2023 20.12
> > >
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > 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ørup <mb@smartsharesystems.com>
> > > > > > 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?
> > >
> > > 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?
>
> I think adding a comment, related to type of supported mempool, in dma
> library code might not be needed as it is driver implementation dependent.
> Call to dev->dev_ops->vchan_setup for the driver shall check and return
> error for unsupported type of mempool.
Makes sense. But I still think that it needs to be mentioned that RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE has some limitations, and doesn't mean that any type of mempool can be used.
I suggest you add a note to the description of the new "struct rte_mempool *mem_to_dev_src_buf_pool" field in the rte_dma_vchan_conf structure, such as:
Note: If the mempool is not supported by the DMA driver, rte_dma_vchan_setup() will fail.
You should also mention it with the description of RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE flag, such as:
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.
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > 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.
next prev parent reply other threads:[~2023-08-10 11:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 6:08 Amit Prakash Shukla
2023-08-09 9:07 ` Morten Brørup
2023-08-09 14:27 ` Amit Prakash Shukla
2023-08-09 14:48 ` Morten Brørup
2023-08-09 18:11 ` Amit Prakash Shukla
2023-08-10 9:32 ` Morten Brørup
2023-08-10 10:27 ` Amit Prakash Shukla
2023-08-10 11:35 ` Morten Brørup [this message]
2023-08-10 12:11 ` Amit Prakash Shukla
2023-08-10 16:53 ` [RFC PATCH v2] " Amit Prakash Shukla
2023-08-10 18:20 ` Morten Brørup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35D87AE1@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=amitprakashs@marvell.com \
--cc=anoobj@marvell.com \
--cc=bruce.richardson@intel.com \
--cc=cheng1.jiang@intel.com \
--cc=conor.walsh@intel.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=g.singh@nxp.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=kevin.laatz@intel.com \
--cc=ndabilpuram@marvell.com \
--cc=sachin.saxena@oss.nxp.com \
--cc=vattunuru@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).