DPDK patches and discussions
 help / color / mirror / Atom feed
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 11:32:41 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87AE0@smartserver.smartshare.dk> (raw)
In-Reply-To: API-LINK-9d9d559e8d8bb3760944bc22b01de02cf850557b

> 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 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.


  reply	other threads:[~2023-08-10  9:32 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 [this message]
2023-08-10 10:27           ` Amit Prakash Shukla
2023-08-10 11:35             ` Morten Brørup
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=98CBD80474FA8B44BF855DF32C47DC35D87AE0@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).