Re: [MirageOS-devel] towards a common Mirage 'FLOW' signature

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

On 20 Jun 2014, at 20:49, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:

> 
> On 18 Jun 2014, at 21:21, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
>> On 18 Jun 2014, at 18:46, David Scott <scott.dj@xxxxxxxxx> wrote:
>> 
>>> More stuff to think about for v2: the 'shared-memory-ring' code exposes 
>>> more detail. It's possible to 'read' data without acknowledging it, such 
>>> that it'll still be there if you crash and restart.
> 
> apologies for not knowing the ring api better -- do you mean it will always 
> be there in this case, or it will be there unless the "sender" has 
> overwritten it?

The data has been ‘produced’ (and a producer pointer has been incremented) but 
won’t be overwritten by the sender until the receiver ‘consumes’ it (by 
advancing a consumer pointer). I’m exploiting this in xenstore to make sure I 
never lose data— I only advance the consumer pointer when I’ve written the data 
to somewhere persistent.

Separately I’ve seen problems where block writes from VMs have been sent over 
NFS/TCP and then the buffers freed, before the TCP ACKs have been received. 
Seeing that made me whether ACKing data would be a good thing to expose in 
every FLOW.

>>> This is a bit like TCP retransmitting data you haven't ACKed. We could 
>>> expose this somewhere. Also, each FLOW probably has some amount of 
>>> buffering built-into it, for example vchan is limited by the size of the 
>>> ring set at create time. Perhaps that could be exposed? If a particular 
>>> FLOW implementation is prepared to allocate buffers it would be good to be 
>>> able to control that, and apply back pressure etc. Perhaps we could draw 
>>> some inspiration from somewhere-- JS core's pipes maybe?
>> 
>> Hm, the point of FLOWs is that they shouldn't have buffering, and that's in 
>> the CHANNEL type instead.  Having said that, some buffering of in-flight 
>> requests is of course inescapable,
> 
> ...given that, how should a FLOW end up differing from a CHANNEL in practice? 
> is it simply the amount of buffering allowed, in which case isn't this an 
> application level decision?  or is it who allocates and manages those buffers?

I think it would help (me anyway) if we could clearly differentiate FLOW and 
CHANNEL.

> 
>> and we could expose TCP buffers or the vchan ring size.  What use would this 
>> information be to an application, though?
> 
> if i'm following this correctly, couldn't the application use this to do 
> things like customise TCP congestion control behaviour by fiddling with the 
> receive window? 

Maybe we should start by cataloging our current buffer management and see if we 
can see any nice patterns? We have a nice set of protocols now.

Cheers,
Dave


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel