All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: David Stevens <stevensd@chromium.org>,
	Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	David Stevens <stevensd@google.com>
Subject: Re: [PATCH 0/4] Add dynamic iommu backed bounce buffers
Date: Thu, 8 Jul 2021 11:29:18 +0200	[thread overview]
Message-ID: <YObFbqEk1nGVuHLF@8bytes.org> (raw)
In-Reply-To: <20210707075505.2896824-1-stevensd@google.com>

Adding Robin too.

On Wed, Jul 07, 2021 at 04:55:01PM +0900, David Stevens wrote:
> Add support for per-domain dynamic pools of iommu bounce buffers to the 
> dma-iommu API. This allows iommu mappings to be reused while still
> maintaining strict iommu protection. Allocating buffers dynamically
> instead of using swiotlb carveouts makes per-domain pools more amenable
> on systems with large numbers of devices or where devices are unknown.
> 
> When enabled, all non-direct streaming mappings below a configurable
> size will go through bounce buffers. Note that this means drivers which
> don't properly use the DMA API (e.g. i915) cannot use an iommu when this
> feature is enabled. However, all drivers which work with swiotlb=force
> should work.
> 
> Bounce buffers serve as an optimization in situations where interactions
> with the iommu are very costly. For example, virtio-iommu operations in
> a guest on a linux host require a vmexit, involvement the VMM, and a
> VFIO syscall. For relatively small DMA operations, memcpy can be
> significantly faster.
> 
> As a performance comparison, on a device with an i5-10210U, I ran fio
> with a VFIO passthrough NVMe drive with '--direct=1 --rw=read
> --ioengine=libaio --iodepth=64' and block sizes 4k, 16k, 64k, and
> 128k. Test throughput increased by 2.8x, 4.7x, 3.6x, and 3.6x. Time
> spent in iommu_dma_unmap_(page|sg) per GB processed decreased by 97%,
> 94%, 90%, and 87%. Time spent in iommu_dma_map_(page|sg) decreased
> by >99%, as bounce buffers don't require syncing here in the read case.
> Running with multiple jobs doesn't serve as a useful performance
> comparison because virtio-iommu and vfio_iommu_type1 both have big
> locks that significantly limit mulithreaded DMA performance.
> 
> This patch set is based on v5.13-rc7 plus the patches at [1].
> 
> David Stevens (4):
>   dma-iommu: add kalloc gfp flag to alloc helper
>   dma-iommu: replace device arguments
>   dma-iommu: expose a few helper functions to module
>   dma-iommu: Add iommu bounce buffers to dma-iommu api
> 
>  drivers/iommu/Kconfig          |  10 +
>  drivers/iommu/Makefile         |   1 +
>  drivers/iommu/dma-iommu.c      | 119 ++++--
>  drivers/iommu/io-buffer-pool.c | 656 +++++++++++++++++++++++++++++++++
>  drivers/iommu/io-buffer-pool.h |  91 +++++
>  include/linux/dma-iommu.h      |  12 +
>  6 files changed, 861 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/iommu/io-buffer-pool.c
>  create mode 100644 drivers/iommu/io-buffer-pool.h
> 
> -- 
> 2.32.0.93.g670b81a890-goog

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: David Stevens <stevensd@chromium.org>,
	Robin Murphy <robin.murphy@arm.com>
Cc: David Stevens <stevensd@google.com>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	iommu@lists.linux-foundation.org, Will Deacon <will@kernel.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 0/4] Add dynamic iommu backed bounce buffers
Date: Thu, 8 Jul 2021 11:29:18 +0200	[thread overview]
Message-ID: <YObFbqEk1nGVuHLF@8bytes.org> (raw)
In-Reply-To: <20210707075505.2896824-1-stevensd@google.com>

Adding Robin too.

On Wed, Jul 07, 2021 at 04:55:01PM +0900, David Stevens wrote:
> Add support for per-domain dynamic pools of iommu bounce buffers to the 
> dma-iommu API. This allows iommu mappings to be reused while still
> maintaining strict iommu protection. Allocating buffers dynamically
> instead of using swiotlb carveouts makes per-domain pools more amenable
> on systems with large numbers of devices or where devices are unknown.
> 
> When enabled, all non-direct streaming mappings below a configurable
> size will go through bounce buffers. Note that this means drivers which
> don't properly use the DMA API (e.g. i915) cannot use an iommu when this
> feature is enabled. However, all drivers which work with swiotlb=force
> should work.
> 
> Bounce buffers serve as an optimization in situations where interactions
> with the iommu are very costly. For example, virtio-iommu operations in
> a guest on a linux host require a vmexit, involvement the VMM, and a
> VFIO syscall. For relatively small DMA operations, memcpy can be
> significantly faster.
> 
> As a performance comparison, on a device with an i5-10210U, I ran fio
> with a VFIO passthrough NVMe drive with '--direct=1 --rw=read
> --ioengine=libaio --iodepth=64' and block sizes 4k, 16k, 64k, and
> 128k. Test throughput increased by 2.8x, 4.7x, 3.6x, and 3.6x. Time
> spent in iommu_dma_unmap_(page|sg) per GB processed decreased by 97%,
> 94%, 90%, and 87%. Time spent in iommu_dma_map_(page|sg) decreased
> by >99%, as bounce buffers don't require syncing here in the read case.
> Running with multiple jobs doesn't serve as a useful performance
> comparison because virtio-iommu and vfio_iommu_type1 both have big
> locks that significantly limit mulithreaded DMA performance.
> 
> This patch set is based on v5.13-rc7 plus the patches at [1].
> 
> David Stevens (4):
>   dma-iommu: add kalloc gfp flag to alloc helper
>   dma-iommu: replace device arguments
>   dma-iommu: expose a few helper functions to module
>   dma-iommu: Add iommu bounce buffers to dma-iommu api
> 
>  drivers/iommu/Kconfig          |  10 +
>  drivers/iommu/Makefile         |   1 +
>  drivers/iommu/dma-iommu.c      | 119 ++++--
>  drivers/iommu/io-buffer-pool.c | 656 +++++++++++++++++++++++++++++++++
>  drivers/iommu/io-buffer-pool.h |  91 +++++
>  include/linux/dma-iommu.h      |  12 +
>  6 files changed, 861 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/iommu/io-buffer-pool.c
>  create mode 100644 drivers/iommu/io-buffer-pool.h
> 
> -- 
> 2.32.0.93.g670b81a890-goog
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2021-07-08  9:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07  7:55 [PATCH 0/4] Add dynamic iommu backed bounce buffers David Stevens
2021-07-07  7:55 ` David Stevens
2021-07-07  7:55 ` [PATCH 1/4] dma-iommu: add kalloc gfp flag to alloc helper David Stevens
2021-07-07  7:55   ` David Stevens
2021-07-08 17:22   ` Robin Murphy
2021-07-08 17:22     ` Robin Murphy
2021-07-07  7:55 ` [PATCH 2/4] dma-iommu: replace device arguments David Stevens
2021-07-07  7:55   ` David Stevens
2021-07-07  7:55 ` [PATCH 3/4] dma-iommu: expose a few helper functions to module David Stevens
2021-07-07  7:55   ` David Stevens
2021-07-07  7:55 ` [PATCH 4/4] dma-iommu: Add iommu bounce buffers to dma-iommu api David Stevens
2021-07-07  7:55   ` David Stevens
2021-07-08  9:29 ` Joerg Roedel [this message]
2021-07-08  9:29   ` [PATCH 0/4] Add dynamic iommu backed bounce buffers Joerg Roedel
2021-07-08 17:14   ` Robin Murphy
2021-07-08 17:14     ` Robin Murphy
2021-07-09  7:25     ` David Stevens
2021-07-09  7:25       ` David Stevens
2021-07-08 13:38 ` Lu Baolu
2021-07-08 13:38   ` Lu Baolu
2021-07-09  6:04   ` David Stevens
2021-07-09  6:04     ` David Stevens

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=YObFbqEk1nGVuHLF@8bytes.org \
    --to=joro@8bytes.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=senozhatsky@chromium.org \
    --cc=stevensd@chromium.org \
    --cc=stevensd@google.com \
    --cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.