DMA-BUF Heaps BoF notes (Re: [RFC] Experimental DMA-BUF Device Heaps)

[Ezequiel Garcia <ezequiel@collabora.com>]

Dear all,

Here are the notes we took during the BoF.

I believe the meeting was super interesting.

Although it felt a bit short for the topic,
we left with a few interesting ideas.

Thanks everyone!
Ezequiel

---
LPC 2020 BoF: Negotiating DMA-BUF Heaps

Attendees:
* Brian Starkey
* Daniel Stone
* Ezequiel Garcia
* James Jones
* John Reitan
* Laura Abbott
* Laurent Pinchart
* Sumit Semwal
* Robert Beckett

# Replacing subsystem memory allocators with dma-buf heaps

* Laurent: we should not have subsystem implement their own allocator.
  Using heaps could be a good idea.

* Laura: Wary to add too much support to heaps,
  from the ION experience.

* Laurent: V4L2: most drivers use videobuf2,
  which is a fairly complex piece of code.
  Three constraints, sg, contig, and vmalloc:
  these are fairly generic and not video-specific, why can't these just use heaps?

* Brian: In-kernel API will most likely just care of dma-buf
  not necessarily FDs. This was discussed recently, see "Role of DMA Heaps
  vs GEM in allocation",https://www.spinics.net/lists/dri-devel/msg268103.html

* Do we expect to get a non-file descriptor identifier for a dma-buf? No.

* Laurent proposes a two steps API (similar to existing GEM API),
  where we have one interface to allocate a buffer, with an identifier
  local to a process, and then another interface to wrap the buffer
  on a dma-buf (fd).

* If devices are not meant to be shared, then we might want to avoid
  the DMA-BUF design entirely. As Sumit mentioned, the fundamental
  idea behind DMA-BUF is that they are expected to be shared.
  OTOH, it was mentioned that sometimes we don't know if a buffer
  will be shared or not, so that's why the ability to wrap a buffer
over dma-buf is useful.

* New subsytems would possibly want to avoid implementing
  its own allocator interface. But unfortunately, we don't want
  to produce a fd per buffer, so that will mean a new subsystem
  will eventually require its own API (GEM-like).
  If a subsystem doesn't need many buffers, and the FD semantic is fine,
  then it would be acceptable to avoid a subsystem-specific API.

* It would be interesting to experiment replacing videobuf2-dma-contig
  with just dma-buf heap usage, and see what kind of code save we'd save.

* John Stultz has ideas around providing in-kernel accessors
  for the heaps - the idea is for drivers to not have to implement
  full exporter functionality for an already existing dma-buf heap type.

* Drawback to this idea of reusing dma-buf heaps to allocate buffers,
  is that it means marking every buffer that gets exported as shareable.

* The benefits in having a centralized implementation would be in unifying
  the semantics, reusable concepts that can be used to build future APIs around,
  rather than trying to created unified APIs around disparate kernel allocation
  APIs at only the userspace level.

* Robert: Is there an in-kernel user for the in-kernel dma-buf request?
  A possible answer would be for scratch buffers. The idea would be
  to avoid getting details wrong. However, doing this would allow every
  buffer to be exportable. Also, it sounds like this means
  re-implementing DMA-API?

* DMA-BUF are designed to be shared, not necessarily an allocator.

* Want something to expose device-local memory to rest of kernel.
Could be a dma-buf heap?