From: Christoph Hellwig <hch@lst.de>
To: Jonathan Lemon <jonathan.lemon@gmail.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
"Björn Töpel" <bjorn.topel@intel.com>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] dma-mapping: add a new dma_need_sync API
Date: Tue, 7 Jul 2020 17:14:40 +0200 [thread overview]
Message-ID: <20200707151440.GA23816@lst.de> (raw)
In-Reply-To: <20200707151109.qui5uzzzq4dihfie@bsd-mbp>
On Tue, Jul 07, 2020 at 08:11:09AM -0700, Jonathan Lemon wrote:
> > You need to check every mapping. E.g. this API pairs with a
> > dma_map_single/page call. For S/G mappings you'd need to call it for
> > each entry, although if you have a use case for that we really should
> > add a dma_sg_need_sync helper instea of open coding the scatterlist walk.
>
> My use case is setting up a pinned memory area, and caching the dma
> mappings. I'd like to bypass storing the DMA addresses if they aren't
> needed. For example:
>
> setup()
> {
> if (dma_need_sync(dev, addr, len)) {
> kvmalloc_array(...)
> cache_dma_mappings(...)
> }
>
>
> dev_get_dma(page)
> {
> if (!cache)
> return page_to_phys(page)
>
> return dma_cache_lookup(...)
>
>
>
> The reason for doing it this way is that the page in question may be
> backed by either system memory, or device memory such as a GPU. For the
> latter, the GPU provides a table of DMA addresses where data may be
> accessed, so I'm unable to use the dma_map_page() API.
dma_need_sync doesn't tell you if the unmap needs the dma_addr_t.
I've been think about replacing CONFIG_NEED_DMA_MAP_STATE with a runtime
for a while, which would give you exattly what you need. For now it
isn't very useful as there are very few configs left that do not have
CONFIG_NEED_DMA_MAP_STATE set.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jonathan Lemon <jonathan.lemon@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, bpf@vger.kernel.org,
"Björn Töpel" <bjorn.topel@intel.com>,
"Christoph Hellwig" <hch@lst.de>,
"Magnus Karlsson" <magnus.karlsson@intel.com>
Subject: Re: [PATCH 1/4] dma-mapping: add a new dma_need_sync API
Date: Tue, 7 Jul 2020 17:14:40 +0200 [thread overview]
Message-ID: <20200707151440.GA23816@lst.de> (raw)
In-Reply-To: <20200707151109.qui5uzzzq4dihfie@bsd-mbp>
On Tue, Jul 07, 2020 at 08:11:09AM -0700, Jonathan Lemon wrote:
> > You need to check every mapping. E.g. this API pairs with a
> > dma_map_single/page call. For S/G mappings you'd need to call it for
> > each entry, although if you have a use case for that we really should
> > add a dma_sg_need_sync helper instea of open coding the scatterlist walk.
>
> My use case is setting up a pinned memory area, and caching the dma
> mappings. I'd like to bypass storing the DMA addresses if they aren't
> needed. For example:
>
> setup()
> {
> if (dma_need_sync(dev, addr, len)) {
> kvmalloc_array(...)
> cache_dma_mappings(...)
> }
>
>
> dev_get_dma(page)
> {
> if (!cache)
> return page_to_phys(page)
>
> return dma_cache_lookup(...)
>
>
>
> The reason for doing it this way is that the page in question may be
> backed by either system memory, or device memory such as a GPU. For the
> latter, the GPU provides a table of DMA addresses where data may be
> accessed, so I'm unable to use the dma_map_page() API.
dma_need_sync doesn't tell you if the unmap needs the dma_addr_t.
I've been think about replacing CONFIG_NEED_DMA_MAP_STATE with a runtime
for a while, which would give you exattly what you need. For now it
isn't very useful as there are very few configs left that do not have
CONFIG_NEED_DMA_MAP_STATE set.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-07 15:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 13:03 add an API to check if a streamming mapping needs sync calls Christoph Hellwig
2020-06-29 13:03 ` Christoph Hellwig
2020-06-29 13:03 ` [PATCH 1/4] dma-mapping: add a new dma_need_sync API Christoph Hellwig
2020-06-29 13:03 ` Christoph Hellwig
2020-07-06 19:42 ` Jonathan Lemon
2020-07-06 19:42 ` Jonathan Lemon
2020-07-07 6:47 ` Christoph Hellwig
2020-07-07 6:47 ` Christoph Hellwig
2020-07-07 15:11 ` Jonathan Lemon
2020-07-07 15:11 ` Jonathan Lemon
2020-07-07 15:14 ` Christoph Hellwig [this message]
2020-07-07 15:14 ` Christoph Hellwig
2020-06-29 13:03 ` [PATCH 2/4] xsk: replace the cheap_dma flag with a dma_need_sync flag Christoph Hellwig
2020-06-29 13:03 ` Christoph Hellwig
2020-06-29 13:03 ` [PATCH 3/4] xsk: remove a double pool->dev assignment in xp_dma_map Christoph Hellwig
2020-06-29 13:03 ` Christoph Hellwig
2020-06-29 13:03 ` [PATCH 4/4] xsk: use dma_need_sync instead of reimplenting it Christoph Hellwig
2020-06-29 13:03 ` Christoph Hellwig
2020-06-29 13:39 ` add an API to check if a streamming mapping needs sync calls Björn Töpel
2020-06-29 13:39 ` Björn Töpel
2020-06-29 14:22 ` Christoph Hellwig
2020-06-29 14:22 ` Christoph Hellwig
2020-07-08 7:44 ` Christoph Hellwig
2020-07-08 7:44 ` Christoph Hellwig
2020-07-08 9:01 ` Daniel Borkmann
2020-07-08 9:01 ` Daniel Borkmann
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=20200707151440.GA23816@lst.de \
--to=hch@lst.de \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathan.lemon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.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.