Improving next_buffer() rpc

[Daniel van Vugt]

Sounds better to just pass buffers around although I'm not keen on any 
change that doesn't make progress on the performance bottleneck LP: 
#1253868. The bottleneck is the swapping/exchanging approach which 
limits the client to holding only one buffer, so I don't think it's a 
good idea for new designs to still have that problem.

In order to improve parallelism per LP: #1253868 you'd really have to 
receive new buffers as soon as they're free, which means getting them as 
MirEvents. Then you only need an RPC function to release them back to 
the server:

    rpc release_buffer(Buffer) returns (Void);

Keep in mind the inter-process communication is the bottleneck here. If 
you allow a context switch between the server and client then that's 
half to one millisecond (see mirping) per RPC round trip. More than 
double that for nested servers and you see the protocol delay could be a 
significant factor. So I think any protocol enhancement should have 
parallelism designed in.

I also think we need to be careful about not landing any protocol 
changes to RTM candidate series' 0.4-0.5, so the foundation for RTM is 
maximally mature (albeit not yet optimal).

- Daniel


On 08/07/14 21:10, Kevin DuBois wrote:
> Hello mir team,
>
> In order to get the next buffer for the client, we currently have:
>
> rpc next_buffer(SurfaceId) returns (Buffer);
>
> which is problematic for me in working on [1] because this implicitly
> releases the buffer from the client side, whereas in working on that
> performance improvement, I have to send a fd back to the server. So I
> was thinking of adding an rpc method more like:
>
> rpc exchange_buffer(Buffer) returns (Buffer);
>
> This would be sufficient to pass the fd fence back, and the buffer id in
> the Buffer protocol message would be sufficient for the server to figure
> out which surface has sent back its buffer. (given the global buffer
> id's we're using)
>
> This does not address the problem noted in:
> https://bugs.launchpad.net/mir/+bug/1253868
> but I think that might be better addressed by having an exchange type
> rpc call (explicit or implicit) and negotiating/increasing how many
> buffers the client owns somehow else.
>
> This seems like something that could have diverse opinions, so I'm
> hoping to get some input on the protocol change here first.
>
> Thanks!
> Kevin
>
> [1]
> https://blueprints.launchpad.net/ubuntu/+spec/client-1410-mir-performance item:
> "[kdub] fencing improvements for clients add the ipc plumbing"
>
>