Wayland intermediate sized data transfer

[Simon Ser]

On Monday, November 12, 2018 2:54 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 12 Nov 2018 14:48:19 +0200
> Pekka Paalanen ppaalanen at gmail.com wrote:
>
> > Quite likely we need to revisit this in any case. Using shared memory
> > feels complicated, but OTOH it is relatively lot of data. Even the
> > kernel UABI does not use a flat list of format+modifier but a fairly
> > "interesting" bitfield encoding. That's probably not appropriate for
> > Wayland though, so maybe we have to use shared memory for it.
>
> Hi,
>
> having thought about this, I have the feeling that Wayland handles well
> tiny bits of data as protocol messages and large chunks of data as
> shared memory file descriptors, but it seems we lack a good solution
> for intermediate sized bits of data in the range 1 kB - 8 kB, just to
> throw some random numbers up.
>
> It is too risky to put these through the protocol messages in line, but
> the trouble of setting up a shared memory file seems disproportionate
> to the amount of data. Yet, it seems that setting up a shared memory
> file is the only solution since the in line data is too risky.
>
> I started wondering if we should have a generic shared memory
> interface, something like the following sketch of a Wayland extension.
>
> interface shm_factory
> Is the global.
>
> -   request: create_shm_file(new shm_file, fd, size, seals, direction)
>     Creates a new shm_file object that refers to the memory backing
>     the fd, of the given size, and being sealed with the mentioned
>     seals. Direction means whether the server or the client will be
>     the writer, so this will be a one-way street but a re-usable
>     one.
>
>     (This is a good chance to get memfd and seals properly used.)
>
>     interface shm_file
>     Represents a piece of shared memory. Comes in two mutually
>     exclusive flavours:
>     -   server-writable
>     -   client-writable
>         Has a fixed size.
>
>         The usage pattern is that the writer signals the reader when it
>         needs to copy the data out. This is done by a custom protocol
>         message carrying a shm_file as an argument, which makes the
>         shm_file read-locked. The reader copies the data out of the
>         shared memory and sends client_read_done or server_read_done
>         ASAP, releasing the read-lock. While the shm_file is
>         read-locked, the writer may not write into it. While the
>         shm_file is not read-locked, the reader may not read it.
>
> -   request: client_read_done
>     Sent by the client when it has copied the data out. Releases
>     the read-lock.
>
> -   event: server_read_done
>     Sent by the server when it has copied the data out. Releases
>     the read-lock.
>
>     When e.g. zwp_linux_dmabuf would provide the list of pixel formats and
>     modifiers, the server needs to first send the required shared memory
>     size to the client, the client creates a server-writable shm_file, and
>     sends it to the server. The server fills in the data and sends an event
>     with the shm_file as an argument that tell the client to read it (sets
>     the read-lock). The rest goes according to the the generic protocol
>     above.
>
>     Why all the roundtripping to get the shm_file created?
>
>     Because I would prefer the memory allocation is always
>     accounted to the client, not the server. We should try to keep
>     server allocations on behalf of clients to a minimum so that
>     OOM killer etc. can find the right culprit.
>
>     Why so much copying?
>
>     Because the amount of data should be small enough that copying
>     it is insignificant. By assuming that readers maintain their
>     own copy, the protocol is simpler. No need to juggle multiple
>     shm_files like we do with wl_buffers.
>
>     Why unidirectional?
>
>     To keep it simple. Need bidirectional transfers? Make one
>     shm_file for each direction.
>
>     Isn't creating and tearing down shared memory relatively expensive?
>
>     Yes, but shm_file is meant to be repeatedly re-used. After
>     reader has read, the writer can write again. No need to tear it
>     down, if you expect repeated transfers.
>
>     While writing this, I have a strong feeling I am reinventing the wheel
>     here...
>
>     Just throwing this idea out there, not sure if it was a good one.
>
>     Thanks,
>     pq
>

Hi,

I've been thinking about this for a while, and I've been wondering: if we do
a copy, why not use a pipe directly?

Thanks,

Simon