From: "hch@lst.de" <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "davidm@hpl.hp.com" <davidm@hpl.hp.com>,
"ralf@oss.sgi.com" <ralf@oss.sgi.com>,
Linuxarm <linuxarm@huawei.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"sailer@ife.ee.ethz.ch" <sailer@ife.ee.ethz.ch>,
"Jay.Estabrook@compaq.com" <Jay.Estabrook@compaq.com>,
"dagum@barrel.engr.sgi.com" <dagum@barrel.engr.sgi.com>,
"andrea@suse.de" <andrea@suse.de>,
"grundler@cup.hp.com" <grundler@cup.hp.com>,
"jens.axboe@oracle.com" <jens.axboe@oracle.com>,
"hch@lst.de" <hch@lst.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Constantly map and unmap of streaming DMA buffers with IOMMU backend might cause serious performance problem
Date: Fri, 15 May 2020 16:45:22 +0200 [thread overview]
Message-ID: <20200515144522.GA25652@lst.de> (raw)
In-Reply-To: <36d67d68-4381-c7a7-dcf1-6383bd9ae0ad@arm.com>
On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
>> Meanwhile, for the safety of buffers, lower-layer drivers need to make certain the buffers have already been unmapped in iommu before those buffers go back to buddy for other users.
>
> That sounds like it would only have benefit in a very small set of specific
> circumstances, and would be very difficult to generalise to buffers that
> are mapped via dma_map_page() or dma_map_single(). Furthermore, a
> high-level API that affects a low-level driver's interpretation of
> mid-layer API calls without the mid-layer's knowledge sounds like a hideous
> abomination of anti-design. If a mid-layer API lends itself to inefficiency
> at the lower level, it would seem a lot cleaner and more robust to extend
> *that* API for stateful buffer reuse. Failing that, it might possibly be
> appropriate to approach this at the driver level - many of the cleverer
> network drivers already implement buffer pools to recycle mapped SKBs
> internally, couldn't the "zip driver" simply try doing something like that
> for itself?
Exactly. If you upper consumer of the DMA API keeps reusing the same
pages just map them once and use dma_sync_* to transfer ownership as
needed.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-05-15 14:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 8:19 Constantly map and unmap of streaming DMA buffers with IOMMU backend might cause serious performance problem Song Bao Hua
2020-05-15 12:10 ` Robin Murphy
2020-05-15 14:45 ` hch [this message]
2020-05-15 21:33 ` Song Bao Hua
2020-05-15 22:12 ` Robin Murphy
2020-05-15 22:45 ` Song Bao Hua
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=20200515144522.GA25652@lst.de \
--to=hch@lst.de \
--cc=Jay.Estabrook@compaq.com \
--cc=andrea@suse.de \
--cc=dagum@barrel.engr.sgi.com \
--cc=davidm@hpl.hp.com \
--cc=grundler@cup.hp.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxarm@huawei.com \
--cc=ralf@oss.sgi.com \
--cc=robin.murphy@arm.com \
--cc=sailer@ife.ee.ethz.ch \
/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).