linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "hch@lst.de" <hch@lst.de>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "hch@lst.de" <hch@lst.de>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yong.zhi@intel.com" <yong.zhi@intel.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"bingbu.cao@intel.com" <bingbu.cao@intel.com>,
	"jian.xu.zheng@intel.com" <jian.xu.zheng@intel.com>,
	"tian.shu.qiu@intel.com" <tian.shu.qiu@intel.com>,
	"shiraz.saleem@intel.com" <shiraz.saleem@intel.com>,
	"sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>, "jgg@ziepe.ca" <jgg@ziepe.ca>
Subject: Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Date: Tue, 15 Jan 2019 19:31:33 +0100	[thread overview]
Message-ID: <20190115183133.GA12350@lst.de> (raw)
In-Reply-To: <41d0616e95fb48942404fb54d82249f5700affb1.camel@vmware.com>

On Tue, Jan 15, 2019 at 06:03:39PM +0000, Thomas Hellstrom wrote:
> In the graphics case, it's probably because it doesn't fit the graphics
> use-cases:
> 
> 1) Memory typically needs to be mappable by another device. (the "dma-
> buf" interface)

And there is nothing preventing dma-buf sharing of these buffers.
Unlike the get_sgtable mess it can actually work reliably on
architectures that have virtually tagged caches and/or don't
guarantee cache coherency with mixed attribute mappings.

> 2) DMA buffers are exported to user-space and is sub-allocated by it.
> Mostly there are no GPU user-space kernel interfaces to sync / flush
> subregions and these syncs may happen on a smaller-than-cache-line
> granularity.

I know of no architectures that can do cache maintainance on a less
than cache line basis.  Either the instructions require you to
specifcy cache lines, or they do sometimes more, sometimes less
intelligent rounding up.

Note that as long dma non-coherent buffers are devices owned it
is up to the device and the user space driver to take care of
coherency, the kernel very much is out of the picture.

  reply	other threads:[~2019-01-15 18:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-04 22:35 [PATCH] lib/scatterlist: Provide a DMA page iterator Jason Gunthorpe
2019-01-05  2:37 ` kbuild test robot
2019-01-05  3:21   ` Jason Gunthorpe
2019-01-10 23:42 ` Jason Gunthorpe
2019-01-14  9:48   ` Christoph Hellwig
2019-01-15 14:17     ` Thomas Hellstrom
2019-01-15 14:24       ` Christian König
2019-01-15 15:20         ` hch
2019-01-15 18:03           ` Thomas Hellstrom
2019-01-15 18:31             ` hch [this message]
2019-01-15 19:13               ` Koenig, Christian
2019-01-15 20:58                 ` hch
2019-01-16  7:09                   ` Thomas Hellstrom
2019-01-16  7:28                     ` Koenig, Christian
2019-01-16 10:14                       ` Daniel Vetter
2019-01-16 16:06                       ` hch
2019-01-16 16:36                         ` Daniel Stone
2019-01-15 21:25       ` Jason Gunthorpe
2019-01-16 10:40         ` Christian König
2019-01-16 16:11         ` hch
2019-01-16 17:24           ` Jason Gunthorpe
2019-01-17  9:30             ` hch
2019-01-17 10:47               ` Thomas Hellstrom
2019-01-17 15:54               ` Jason Gunthorpe
2019-01-12 18:27 ` Shiraz Saleem
2019-01-12 18:37   ` Jason Gunthorpe
2019-01-12 19:03     ` Shiraz Saleem
2019-01-14  9:46       ` Christoph Hellwig
2019-01-14 22:16       ` Jason Gunthorpe
2019-02-07 23:23 ` Sakari Ailus

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=20190115183133.GA12350@lst.de \
    --to=hch@lst.de \
    --cc=bingbu.cao@intel.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --cc=jian.xu.zheng@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shiraz.saleem@intel.com \
    --cc=thellstrom@vmware.com \
    --cc=tian.shu.qiu@intel.com \
    --cc=yong.zhi@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).