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: > > > > 1) You need to fix your userspace to not constantly re-establish the sharing. > > > > 2) 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. > > > > 3) 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: > > > > 1) We need some way to figure out which iommu serves which devices. > > > > 2) 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
