netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ioana Ciornei <ioana.ciornei@nxp.com>
To: Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	David Miller <davem@davemloft.net>
Cc: "hch@lst.de" <hch@lst.de>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Leo Li <leoyang.li@nxp.com>,
	Diana Madalina Craciun <diana.craciun@nxp.com>,
	Madalin Bucur <madalin.bucur@nxp.com>,
	Camelia Alexandra Groza <camelia.groza@nxp.com>,
	Roy Pledge <roy.pledge@nxp.com>
Subject: RE: [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync variants
Date: Tue, 19 Nov 2019 14:09:30 +0000	[thread overview]
Message-ID: <VI1PR0402MB280097A09BC2CF202EF3004EE04C0@VI1PR0402MB2800.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <81b6e75b-a827-32e2-77bd-50220ddd66cc@nxp.com>

> Subject: Re: [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync
> variants
> 
> On 13.11.2019 22:11, David Miller wrote:
> > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > Date: Wed, 13 Nov 2019 12:24:17 +0000
> >
> >> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >>
> >> This series introduces a few new dma unmap and sync api variants
> >> that, on top of what the originals do, return the virtual address
> >> corresponding to the input dma address. In order to do that a new dma
> >> map op is added, .get_virt_addr that takes the input dma address and
> >> returns the virtual address backing it up.
> >> The second patch adds an implementation for this new dma map op in
> >> the generic iommu dma glue code and wires it in.
> >> The third patch updates the dpaa2-eth driver to use the new apis.
> >
> > The driver should store the mapping in it's private software state if
> > it needs this kind of conversion.
> 
> On this hardware there's no way of conveying additional frame information,
> such as original va/pa behind the dma address. We have also pondered on the
> idea of keeping this in some kind of data structure but could not find a lock-less
> solution which obviously would bring performance to the ground.
> I'll let my colleagues maintaining these ethernet drivers to get into more details,
> if required.
> 

As Laurentiu pointed out before, keeping a mapping in the driver's private data doesn't
seem feasible without a locking mechanism which in turn would be an immense impact
performance wise.

We also feel that instead of hacking our individual drivers we should extend the
core DMA API to also fit this use case, which is exactly what
Laurentiu's patch set is doing.

Our hope is to come to a common understanding of the next steps since this
would unblock some activities currently in the backlog.

Ioana

  reply	other threads:[~2019-11-19 14:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 12:24 [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync variants Laurentiu Tudor
2019-11-13 12:24 ` [PATCH v3 1/4] dma-mapping: introduce new dma unmap and sync api variants Laurentiu Tudor
2019-11-13 12:24 ` [PATCH v3 2/4] iommu/dma: wire-up new dma map op .get_virt_addr Laurentiu Tudor
2019-11-13 12:24 ` [PATCH v3 3/4] swiotlb: make new {unmap,sync}_desc dma apis work with swiotlb Laurentiu Tudor
2019-11-13 12:24 ` [PATCH v3 4/4] dpaa2_eth: use new unmap and sync dma api variants Laurentiu Tudor
2019-11-13 20:11 ` [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync variants David Miller
2019-11-14 11:13   ` Laurentiu Tudor
2019-11-19 14:09     ` Ioana Ciornei [this message]
2019-11-21  7:41   ` Christoph Hellwig
2019-12-02 14:58     ` Madalin Bucur

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=VI1PR0402MB280097A09BC2CF202EF3004EE04C0@VI1PR0402MB2800.eurprd04.prod.outlook.com \
    --to=ioana.ciornei@nxp.com \
    --cc=camelia.groza@nxp.com \
    --cc=davem@davemloft.net \
    --cc=diana.craciun@nxp.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=laurentiu.tudor@nxp.com \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=madalin.bucur@nxp.com \
    --cc=netdev@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=roy.pledge@nxp.com \
    --cc=ruxandra.radulescu@nxp.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).