On Tue, Mar 25, 2014 at 06:21:34PM +0900, Seung-Woo Kim wrote:
Hi all,
On 2014년 03월 24일 16:35, Daniel Vetter wrote:
Hi all,
Adding piles more people.
For the first case of caching the iommu mapping there's different answers, depening upon the exact case:
You need to fix your userspace to not constantly re-establish the sharing.
We need to add streaming dma support for real to dma-bufs so that
the mapping can be kept while we transfer ownership around. Thus far no one really needed this though since usually you don't actually do cpu access.
- You need opportunistic caching of imported/exported buffer objects
and their mappings. For this you need a) subsystem import/export support which guarantees you to hand out the same dma-buf/native object again upon re-export or re-import (drm has it) b) some opportunistic caching of buffer objects (pretty much are real gpu drm drivers have it). No need of any metadata scheme, and given how much fun I've had implemented this for drm I don't you can make your metadata scheme work in a sane or correct way wrt lifetimes.
For caching the iommu mapping if the iommu is the same for multiple devices:
We need some way to figure out which iommu serves which devices.
The exporter needs to consult this and might just hand out the same
sg mapping out again if it wants to.
No need for importers to do fancy stuff, or attach any importer-visible metadata to dma-bufs. Of course duplicating this code all over the place is a but uncool, so I expect that eventually we'll have a generic exporter implementation, at least for non-swappable buffers. drm/gem is a bit special here ...
In general I don't like the idea of arbitrary metadata at all, sounds prone to abuse with crazy lifetime/refcounting rules for the objects involved. Also I think for a lot of your examples (like debugging) it would be much better if we have a standardized piece of metadata so that all drivers/platforms can use the same tooling.
And it feels like I'm writing such a mail every few months ...
I posted concept about importer priv of dma-buf, and it seems that this patch is partly from similar requirement - iommu map/unmap.
And at that time, Daniel agreed at least the issue, that unnecessary map/unmap can repeatedly called, is also in the drm gem. http://lists.freedesktop.org/archives/dri-devel/2013-June/039469.html
So I agree about the necessary of some data of dma-buf for general importer even though the data can be shared between different subsystems.
Oh right, I guess someone has to implement this eventually ;-) -Daniel