mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <jbottomley@parallels.com>
To: "bhelgaas@google.com" <bhelgaas@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2 4/5] iommu: Use dma_addr_t for IOVA arguments
Date: Fri, 9 May 2014 20:25:40 +0000	[thread overview]
Message-ID: <1399667139.2166.71.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <CAErSpo5bPvaATcptz3wGdLWOG-1thHKCHDK5D8K=D9wy+NDomA@mail.gmail.com>

On Fri, 2014-05-09 at 14:19 -0600, Bjorn Helgaas wrote:
> On Fri, May 9, 2014 at 1:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 09 May 2014 09:32:26 Bjorn Helgaas wrote:
> >> > There are people who care deeply about the performance of IOMMU API
> >> > map/unmap. It isn't used *just* for virtual machines any more. See
> >> > drivers/infiniband/hw/usnic/usnic_uiom.c for example.
> >>
> >> Of course we should care about IOMMU API performance.  We should also
> >> care about interface consistency, and it seems there's a tradeoff in
> >> this case.  I said "relatively" because I expect map/unmap to be less
> >> frequent than read/write operations that use the mapping.  I don't
> >> know anything about infiniband, so maybe that assumption is false
> >> there.
> >
> > In most drivers using the streaming DMA API, every mapping is used
> > exactly once. Think of network or block drivers: they rarely send
> > the same data twice to the device, and it usually comes from or
> > goes to some user space buffer.
> 
> Oh, good point.  I don't work that high up in the stack, so thanks for
> reminding me of that.

To round this out, for most devices we have two types of mappings: the
mailbox ones, which designate regions of communication memory between
the kernel and the device which are usually permanent mappings, and the
transmission mappings: every bit of data we send to the device is
mapped, sent/received and then unmapped.  The setup and teardown costs
factor into the throughput.  Some high iops devices (like SSD or high
speed net) are peculiarly sensitive to this.

James


  reply	other threads:[~2014-05-09 20:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-06 22:48 [PATCH v2 0/5] Clean up DMA API & IOMMU dma_addr_t usage Bjorn Helgaas
2014-05-06 22:48 ` [PATCH v2 1/5] DMA-API: Clarify physical/bus address distinction Bjorn Helgaas
2014-05-07  7:37   ` Arnd Bergmann
2014-05-07 18:43     ` Bjorn Helgaas
2014-05-08  9:24   ` Greg Kroah-Hartman
2014-05-06 22:48 ` [PATCH v2 2/5] DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t Bjorn Helgaas
2014-05-07  7:38   ` Arnd Bergmann
2014-05-06 22:48 ` [PATCH v2 3/5] sh/PCI: Pass GAPSPCI_DMA_BASE CPU address to dma_declare_coherent_memory() Bjorn Helgaas
2014-05-07  7:55   ` Arnd Bergmann
2014-05-07  8:15     ` Arnd Bergmann
2014-05-07 23:18       ` Bjorn Helgaas
2014-05-08 11:36         ` Arnd Bergmann
2014-05-06 22:48 ` [PATCH v2 4/5] iommu: Use dma_addr_t for IOVA arguments Bjorn Helgaas
2014-05-07  7:58   ` Arnd Bergmann
2014-05-08  0:18     ` Bjorn Helgaas
2014-05-08 10:44       ` Arnd Bergmann
2014-05-08 20:30         ` Bjorn Helgaas
2014-05-09  9:58           ` David Woodhouse
2014-05-09 15:32             ` Bjorn Helgaas
2014-05-09 19:52               ` Arnd Bergmann
2014-05-09 20:19                 ` Bjorn Helgaas
2014-05-09 20:25                   ` James Bottomley [this message]
2014-05-06 22:48 ` [PATCH v2 5/5] iommu/exynos: Remove unnecessary "&" from function pointers Bjorn Helgaas
2014-05-07  7:59   ` Arnd Bergmann

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=1399667139.2166.71.camel@dabdike.int.hansenpartnership.com \
    --to=jbottomley@parallels.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /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

all inboxes | Powered by JetHome®