From: arnd@linaro.org (Arnd Bergmann)
Subject: NVMe vs DMA addressing limitations
Date: Tue, 10 Jan 2017 16:02:28 +0100 [thread overview]
Message-ID: <9020459.Ga31IGQ4TP@wuerfel> (raw)
In-Reply-To: <20170110144839.GB27156@lst.de>
On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017@12:01:05PM +0100, Arnd Bergmann wrote:
> > Another workaround me might need is to limit amount of concurrent DMA
> > in the NVMe driver based on some platform quirk. The way that NVMe works,
> > it can have very large amounts of data that is concurrently mapped into
> > the device.
>
> That's not really just NVMe - other storage and network controllers also
> can DMA map giant amounts of memory. There are a couple aspects to it:
>
> - dma coherent memoery - right now NVMe doesn't use too much of it,
> but upcoming low-end NVMe controllers will soon start to require
> fairl large amounts of it for the host memory buffer feature that
> allows for DRAM-less controller designs. As an interesting quirk
> that is memory only used by the PCIe devices, and never accessed
> by the Linux host at all.
Right, that is going to become interesting, as some platforms are
very limited with their coherent allocations.
> - size vs number of the dynamic mapping. We probably want the dma_ops
> specify a maximum mapping size for a given device. As long as we
> can make progress with a few mappings swiotlb / the iommu can just
> fail mapping and the driver will propagate that to the block layer
> that throttles I/O.
Good idea.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@linaro.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
Jens Axboe <axboe@fb.com>, Sagi Grimberg <sagi@grimberg.me>,
linux-pci@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
Keith Busch <keith.busch@intel.com>,
Simon Horman <horms@verge.net.au>,
linux-renesas-soc@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
artemi.ivanov@cogentembedded.com, Christoph Hellwig <hch@lst.de>
Subject: Re: NVMe vs DMA addressing limitations
Date: Tue, 10 Jan 2017 16:02:28 +0100 [thread overview]
Message-ID: <9020459.Ga31IGQ4TP@wuerfel> (raw)
In-Reply-To: <20170110144839.GB27156@lst.de>
On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> > Another workaround me might need is to limit amount of concurrent DMA
> > in the NVMe driver based on some platform quirk. The way that NVMe works,
> > it can have very large amounts of data that is concurrently mapped into
> > the device.
>
> That's not really just NVMe - other storage and network controllers also
> can DMA map giant amounts of memory. There are a couple aspects to it:
>
> - dma coherent memoery - right now NVMe doesn't use too much of it,
> but upcoming low-end NVMe controllers will soon start to require
> fairl large amounts of it for the host memory buffer feature that
> allows for DRAM-less controller designs. As an interesting quirk
> that is memory only used by the PCIe devices, and never accessed
> by the Linux host at all.
Right, that is going to become interesting, as some platforms are
very limited with their coherent allocations.
> - size vs number of the dynamic mapping. We probably want the dma_ops
> specify a maximum mapping size for a given device. As long as we
> can make progress with a few mappings swiotlb / the iommu can just
> fail mapping and the driver will propagate that to the block layer
> that throttles I/O.
Good idea.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@linaro.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Christoph Hellwig <hch@lst.de>,
Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
Keith Busch <keith.busch@intel.com>,
Sagi Grimberg <sagi@grimberg.me>, Jens Axboe <axboe@fb.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-renesas-soc@vger.kernel.org,
Simon Horman <horms@verge.net.au>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
artemi.ivanov@cogentembedded.com
Subject: Re: NVMe vs DMA addressing limitations
Date: Tue, 10 Jan 2017 16:02:28 +0100 [thread overview]
Message-ID: <9020459.Ga31IGQ4TP@wuerfel> (raw)
In-Reply-To: <20170110144839.GB27156@lst.de>
On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> > Another workaround me might need is to limit amount of concurrent DMA
> > in the NVMe driver based on some platform quirk. The way that NVMe works,
> > it can have very large amounts of data that is concurrently mapped into
> > the device.
>
> That's not really just NVMe - other storage and network controllers also
> can DMA map giant amounts of memory. There are a couple aspects to it:
>
> - dma coherent memoery - right now NVMe doesn't use too much of it,
> but upcoming low-end NVMe controllers will soon start to require
> fairl large amounts of it for the host memory buffer feature that
> allows for DRAM-less controller designs. As an interesting quirk
> that is memory only used by the PCIe devices, and never accessed
> by the Linux host at all.
Right, that is going to become interesting, as some platforms are
very limited with their coherent allocations.
> - size vs number of the dynamic mapping. We probably want the dma_ops
> specify a maximum mapping size for a given device. As long as we
> can make progress with a few mappings swiotlb / the iommu can just
> fail mapping and the driver will propagate that to the block layer
> that throttles I/O.
Good idea.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@linaro.org (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: NVMe vs DMA addressing limitations
Date: Tue, 10 Jan 2017 16:02:28 +0100 [thread overview]
Message-ID: <9020459.Ga31IGQ4TP@wuerfel> (raw)
In-Reply-To: <20170110144839.GB27156@lst.de>
On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> > Another workaround me might need is to limit amount of concurrent DMA
> > in the NVMe driver based on some platform quirk. The way that NVMe works,
> > it can have very large amounts of data that is concurrently mapped into
> > the device.
>
> That's not really just NVMe - other storage and network controllers also
> can DMA map giant amounts of memory. There are a couple aspects to it:
>
> - dma coherent memoery - right now NVMe doesn't use too much of it,
> but upcoming low-end NVMe controllers will soon start to require
> fairl large amounts of it for the host memory buffer feature that
> allows for DRAM-less controller designs. As an interesting quirk
> that is memory only used by the PCIe devices, and never accessed
> by the Linux host at all.
Right, that is going to become interesting, as some platforms are
very limited with their coherent allocations.
> - size vs number of the dynamic mapping. We probably want the dma_ops
> specify a maximum mapping size for a given device. As long as we
> can make progress with a few mappings swiotlb / the iommu can just
> fail mapping and the driver will propagate that to the block layer
> that throttles I/O.
Good idea.
Arnd
next prev parent reply other threads:[~2017-01-10 15:02 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 20:45 [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Nikita Yushchenko
2016-12-29 20:45 ` Nikita Yushchenko
2016-12-29 20:45 ` [PATCH 2/2] rcar-pcie: set host bridge's " Nikita Yushchenko
2016-12-29 20:45 ` Nikita Yushchenko
2016-12-29 21:18 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit " Arnd Bergmann
2017-02-16 16:12 ` Arnd Bergmann
2016-12-29 21:18 ` Arnd Bergmann
2016-12-30 9:46 ` Sergei Shtylyov
2016-12-30 9:46 ` Sergei Shtylyov
2016-12-30 10:06 ` Sergei Shtylyov
2016-12-30 10:06 ` Sergei Shtylyov
2017-01-03 18:44 ` Will Deacon
2017-01-03 18:44 ` Will Deacon
2017-01-03 19:00 ` Nikita Yushchenko
2017-01-03 19:00 ` Nikita Yushchenko
2017-01-03 19:01 ` Nikita Yushchenko
2017-01-03 19:01 ` Nikita Yushchenko
2017-01-03 19:01 ` Nikita Yushchenko
2017-01-03 20:13 ` Grygorii Strashko
2017-01-03 20:13 ` Grygorii Strashko
2017-01-03 20:13 ` Grygorii Strashko
2017-01-03 20:23 ` Nikita Yushchenko
2017-01-03 20:23 ` Nikita Yushchenko
2017-01-03 20:23 ` Nikita Yushchenko
2017-01-03 23:13 ` Arnd Bergmann
2017-01-03 23:13 ` Arnd Bergmann
2017-01-03 23:13 ` Arnd Bergmann
2017-01-04 6:24 ` Nikita Yushchenko
2017-01-04 6:24 ` Nikita Yushchenko
2017-01-04 6:24 ` Nikita Yushchenko
2017-01-04 13:29 ` Arnd Bergmann
2017-01-04 13:29 ` Arnd Bergmann
2017-01-04 13:29 ` Arnd Bergmann
2017-01-04 14:30 ` Nikita Yushchenko
2017-01-04 14:30 ` Nikita Yushchenko
2017-01-04 14:30 ` Nikita Yushchenko
2017-01-04 14:46 ` Arnd Bergmann
2017-01-04 14:46 ` Arnd Bergmann
2017-01-04 15:29 ` Nikita Yushchenko
2017-01-04 15:29 ` Nikita Yushchenko
2017-01-04 15:29 ` Nikita Yushchenko
2017-01-06 11:10 ` Arnd Bergmann
2017-01-06 11:10 ` Arnd Bergmann
2017-01-06 11:10 ` Arnd Bergmann
2017-01-06 13:47 ` Nikita Yushchenko
2017-01-06 13:47 ` Nikita Yushchenko
2017-01-06 13:47 ` Nikita Yushchenko
2017-01-06 14:38 ` [PATCH] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko
2017-01-06 14:38 ` Nikita Yushchenko
2017-01-06 14:45 ` Nikita Yushchenko
2017-01-06 14:45 ` Nikita Yushchenko
2017-01-08 7:09 ` Sergei Shtylyov
2017-01-08 7:09 ` Sergei Shtylyov
2017-01-09 6:56 ` Nikita Yushchenko
2017-01-09 6:56 ` Nikita Yushchenko
2017-01-09 14:05 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Arnd Bergmann
2017-01-09 14:05 ` Arnd Bergmann
2017-01-09 14:05 ` Arnd Bergmann
2017-01-09 20:34 ` Nikita Yushchenko
2017-01-09 20:34 ` Nikita Yushchenko
2017-01-09 20:34 ` Nikita Yushchenko
2017-01-09 20:34 ` Nikita Yushchenko
2017-01-09 20:57 ` Christoph Hellwig
2017-01-09 20:57 ` Christoph Hellwig
2017-01-09 20:57 ` Christoph Hellwig
2017-01-09 20:57 ` Christoph Hellwig
2017-01-10 6:47 ` NVMe vs DMA addressing limitations Nikita Yushchenko
2017-01-10 7:07 ` Christoph Hellwig
2017-01-10 7:07 ` Christoph Hellwig
2017-01-10 7:07 ` Christoph Hellwig
2017-01-10 7:07 ` Christoph Hellwig
2017-01-10 7:31 ` Nikita Yushchenko
2017-01-10 7:31 ` Nikita Yushchenko
2017-01-10 7:31 ` Nikita Yushchenko
2017-01-10 7:31 ` Nikita Yushchenko
2017-01-10 11:01 ` Arnd Bergmann
2017-01-10 11:01 ` Arnd Bergmann
2017-01-10 11:01 ` Arnd Bergmann
2017-01-10 11:01 ` Arnd Bergmann
2017-01-10 14:48 ` Christoph Hellwig
2017-01-10 14:48 ` Christoph Hellwig
2017-01-10 14:48 ` Christoph Hellwig
2017-01-10 14:48 ` Christoph Hellwig
2017-01-10 15:02 ` Arnd Bergmann [this message]
2017-01-10 15:02 ` Arnd Bergmann
2017-01-10 15:02 ` Arnd Bergmann
2017-01-10 15:02 ` Arnd Bergmann
2017-01-12 10:09 ` Sagi Grimberg
2017-01-12 10:09 ` Sagi Grimberg
2017-01-12 10:09 ` Sagi Grimberg
2017-01-12 10:09 ` Sagi Grimberg
2017-01-12 11:56 ` Arnd Bergmann
2017-01-12 11:56 ` Arnd Bergmann
2017-01-12 11:56 ` Arnd Bergmann
2017-01-12 11:56 ` Arnd Bergmann
2017-01-12 13:07 ` Christoph Hellwig
2017-01-12 13:07 ` Christoph Hellwig
2017-01-12 13:07 ` Christoph Hellwig
2017-01-12 13:07 ` Christoph Hellwig
2017-01-10 10:54 ` Arnd Bergmann
2017-01-10 10:54 ` Arnd Bergmann
2017-01-10 10:54 ` Arnd Bergmann
2017-01-10 10:54 ` Arnd Bergmann
2017-01-10 10:47 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Arnd Bergmann
2017-01-10 10:47 ` Arnd Bergmann
2017-01-10 10:47 ` Arnd Bergmann
2017-01-10 10:47 ` Arnd Bergmann
2017-01-10 14:44 ` Christoph Hellwig
2017-01-10 14:44 ` Christoph Hellwig
2017-01-10 14:44 ` Christoph Hellwig
2017-01-10 14:44 ` Christoph Hellwig
2017-01-10 15:00 ` Arnd Bergmann
2017-01-10 15:00 ` Arnd Bergmann
2017-01-10 15:00 ` Arnd Bergmann
2017-01-10 15:00 ` 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=9020459.Ga31IGQ4TP@wuerfel \
--to=arnd@linaro.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.