From: Eli Billauer <eli.billauer@gmail.com>
To: shuah.kh@samsung.com
Cc: devel@driverdev.osuosl.org, discuss@x86-64.org,
Greg KH <gregkh@linuxfoundation.org>,
Joerg Roedel <joro@8bytes.org>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>,
iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
bhelgaas@google.com
Subject: Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single()
Date: Sat, 07 Jun 2014 14:23:39 +0300 [thread overview]
Message-ID: <5392F63B.6050708@gmail.com> (raw)
In-Reply-To: <5391F438.90703@samsung.com>
Hello Shuah,
We agree that the streaming API was originally *intended* for short
map-unmap DMA sessions, and that dma_alloc_noncoherent() was the
*intended* API for those who want to hold the DMA during a device's
lifetime.
We also agree that on some platforms, DMA mappings are precious, and
therefore any driver should unmap a region as soon as it's not needed
anymore.
But if we stick to the citation you gave, it says "...unmapped right
after it (unless you use dma_sync_* below)". So even in the streaming
API's definition, there's an understanding, that the "streaming" DMA
buffer can be held for more than a single session. And a good sync tool
for that is made available.
Using cross-reference on Linux' code, I get a strong impression, that
dma_alloc_NONcoherent() is pretty much unused (I counted 8 drivers). The
streaming API's sync functions are heavily used, on the other hand. So
one gets a hunch, that there's a lot of use of the streaming API in the
kernel tree for long-term DMA mappings.
This wasn't the original intention -- we agree on that. But why is it
wrong? Assuming that a driver needs to hold a DMA mapping for a long
while, why does it matter if it was done with dma_alloc_noncoherent() or
with dma_map_*()? They are equally wasteful, aren't they?
Why maintaining two API sets doing the same thing? Or is there a subtle
functional difference I'm not aware of?
Thanks,
Eli
On 06/06/14 20:02, Shuah Khan wrote:
>
> dma_map_single() and dma_unmap_single() are streaming DMA APIs. These
> are intended for one DMA transfer and unmapped right after it is done.
>
> dma buffers are limited shared resources for streaming that are
> shared by several drivers. Hence the need for use and release
> model.
>
> Please refer to the Using Streaming DMA mappings in DMA-API-HOWTO.txt
>
> "- Streaming DMA mappings which are usually mapped for one DMA
> transfer, unmapped right after it (unless you use dma_sync_* below)
> and for which hardware can optimize for sequential accesses.
>
> This of "streaming" as "asynchronous" or "outside the coherency
> domain".
>
> Good examples of what to use streaming mappings for are:
>
> - Networking buffers transmitted/received by a device.
> - Filesystem buffers written/read by a SCSI device."
>
>
> If I understand your intended usage correctly, you are looking to
> allocate and hold the buffers for the lifetime of the driver. For
> such cases, dma_alloc_*() interfaces are the ones to use.
>
> Please also refer to DMA-API.txt as well. Hope this helps.
>
> -- Shuah
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Eli Billauer <eli.billauer@gmail.com>
To: shuah.kh@samsung.com
Cc: Greg KH <gregkh@linuxfoundation.org>,
Joerg Roedel <joro@8bytes.org>,
devel@driverdev.osuosl.org, discuss@x86-64.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single()
Date: Sat, 07 Jun 2014 14:23:39 +0300 [thread overview]
Message-ID: <5392F63B.6050708@gmail.com> (raw)
In-Reply-To: <5391F438.90703@samsung.com>
Hello Shuah,
We agree that the streaming API was originally *intended* for short
map-unmap DMA sessions, and that dma_alloc_noncoherent() was the
*intended* API for those who want to hold the DMA during a device's
lifetime.
We also agree that on some platforms, DMA mappings are precious, and
therefore any driver should unmap a region as soon as it's not needed
anymore.
But if we stick to the citation you gave, it says "...unmapped right
after it (unless you use dma_sync_* below)". So even in the streaming
API's definition, there's an understanding, that the "streaming" DMA
buffer can be held for more than a single session. And a good sync tool
for that is made available.
Using cross-reference on Linux' code, I get a strong impression, that
dma_alloc_NONcoherent() is pretty much unused (I counted 8 drivers). The
streaming API's sync functions are heavily used, on the other hand. So
one gets a hunch, that there's a lot of use of the streaming API in the
kernel tree for long-term DMA mappings.
This wasn't the original intention -- we agree on that. But why is it
wrong? Assuming that a driver needs to hold a DMA mapping for a long
while, why does it matter if it was done with dma_alloc_noncoherent() or
with dma_map_*()? They are equally wasteful, aren't they?
Why maintaining two API sets doing the same thing? Or is there a subtle
functional difference I'm not aware of?
Thanks,
Eli
On 06/06/14 20:02, Shuah Khan wrote:
>
> dma_map_single() and dma_unmap_single() are streaming DMA APIs. These
> are intended for one DMA transfer and unmapped right after it is done.
>
> dma buffers are limited shared resources for streaming that are
> shared by several drivers. Hence the need for use and release
> model.
>
> Please refer to the Using Streaming DMA mappings in DMA-API-HOWTO.txt
>
> "- Streaming DMA mappings which are usually mapped for one DMA
> transfer, unmapped right after it (unless you use dma_sync_* below)
> and for which hardware can optimize for sequential accesses.
>
> This of "streaming" as "asynchronous" or "outside the coherency
> domain".
>
> Good examples of what to use streaming mappings for are:
>
> - Networking buffers transmitted/received by a device.
> - Filesystem buffers written/read by a SCSI device."
>
>
> If I understand your intended usage correctly, you are looking to
> allocate and hold the buffers for the lifetime of the driver. For
> such cases, dma_alloc_*() interfaces are the ones to use.
>
> Please also refer to DMA-API.txt as well. Hope this helps.
>
> -- Shuah
>
>
next prev parent reply other threads:[~2014-06-07 11:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-01 7:01 [PATCH v2 0/4] devres: dma-mapping: Introducing new functions Eli Billauer
2014-06-01 7:01 ` [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single() Eli Billauer
2014-06-01 7:01 ` Eli Billauer
2014-06-03 21:24 ` Shuah Khan
[not found] ` <538E3D04.9060808-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-06-03 23:39 ` Joerg Roedel
2014-06-03 23:39 ` Joerg Roedel
2014-06-04 14:04 ` Tejun Heo
2014-06-04 14:04 ` Tejun Heo
[not found] ` <20140604140408.GC5004-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2014-06-04 14:12 ` Joerg Roedel
2014-06-04 14:12 ` Joerg Roedel
2014-06-04 14:14 ` Tejun Heo
2014-06-04 14:14 ` Tejun Heo
2014-06-04 15:03 ` Eli Billauer
2014-06-04 15:03 ` Eli Billauer
[not found] ` <538F3548.4050101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-04 21:25 ` Joerg Roedel
2014-06-04 21:25 ` Joerg Roedel
[not found] ` <20140604212525.GE23880-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-06-06 11:45 ` Eli Billauer
2014-06-06 11:45 ` Eli Billauer
[not found] ` <5391A9C2.3040602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-06 16:01 ` Greg KH
2014-06-06 16:01 ` Greg KH
[not found] ` <20140606160103.GG15110-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-06-06 16:21 ` Eli Billauer
2014-06-06 16:21 ` Eli Billauer
2014-06-06 17:02 ` Shuah Khan
2014-06-07 11:23 ` Eli Billauer [this message]
2014-06-07 11:23 ` Eli Billauer
2014-06-01 7:01 ` [PATCH v2 2/4] dma-mapping: Add devm_ interface for dma_map_single_attrs() Eli Billauer
2014-06-01 7:01 ` Eli Billauer
2014-06-01 7:01 ` [PATCH v2 3/4] dma-mapping: pci: Add devm_ interface for pci_map_single Eli Billauer
2014-06-01 7:01 ` [PATCH v2 4/4] staging: xillybus: Use devm_ API for memory allocation and DMA mapping Eli Billauer
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=5392F63B.6050708@gmail.com \
--to=eli.billauer@gmail.com \
--cc=bhelgaas@google.com \
--cc=devel@driverdev.osuosl.org \
--cc=discuss@x86-64.org \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=shuah.kh@samsung.com \
--cc=tj@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.