[RFC] Experimental DMA-BUF Device Heaps

[John Stultz]

On Sun, Aug 16, 2020 at 10:23 AM Ezequiel Garcia <ezequiel at collabora.com> wrote:
>
> This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> which will allocate memory suitable for the given device.
>
> The implementation is mostly a port of the Contiguous Videobuf2
> memory allocator (see videobuf2/videobuf2-dma-contig.c)
> over to the DMA-BUF Heap interface.
>
> The intention of this allocator is to provide applications
> with a more system-agnostic API: the only thing the application
> needs to know is which device to get the buffer for.
>
> Whether the buffer is backed by CMA, IOMMU or a DMA Pool
> is unknown to the application.

My hesitancy here is that the main reason we have DMA BUF Heaps, and
ION before it, was to expose different types of memory allocations to
userspace. The main premise that often these buffers are shared with
multiple devices, which have differing constraints and it is userspace
that best understands the path a buffer will take through a series of
devices. So userspace is best positioned to determine what type of
memory should be allocated to satisfy the various devices constraints
(there were some design attempts to allow DMA BUFs to use multiple
attach with deferred alloc at map time to handle this constraint
solving in-kernel, but it was never adopted in practice).

This however, requires some system specific policy - implemented in
the Android userspace by gralloc which maps "usage" types (device
pipeline flows) to heaps. I liken it to fstab, which helps map mount
points to partitions - it's not going to be the same on every system.

What you seem to be proposing seems a bit contrary to this premise -
Userland doesn't know what type of memory it needs, but given a device
can somehow find the heap it should allocate for? This seems to assume
the buffer is only to be used with a single device?

There was at some point a discussion where folks (maybe it was
DanielV? I can't remember...) suggested having something like a sysfs
device node link from a device to a dma-buf heap chardev. This seems
like it would add a similar behavior as what you're proposing, however
without adding possibly a ton of new device specific heaps to the
/dev/dma_heap/ dir. However, we would potentially need any missing
heap types added first.

> I'm not really expecting this patch to be correct or even
> a good idea, but just submitting it to start a discussion on DMA-BUF
> heap discovery and negotiation.
>
> Given Plumbers is just a couple weeks from now, I've submitted
> a BoF proposal to discuss this, as perhaps it would make
> sense to discuss this live?

I do think it's an interesting idea. I agree that having every driver
implement a dmabuf exporter is a bit silly, but I also think Brian's
point that maybe we need some drm helper functions that provide
similar functionality along with a more standardized device ioctl for
single device allocations might be better.

thanks
-john