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

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 20 Jun 2014, at 21:19, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:

> 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.

wonder how this would work with the fable magic -- could you end up with a bad 
receiver causing sender to block?  (though i guess this is solved by having a 
clear idea of whether something is an external receiver or just another module 
of your server that may have been moved between physical hosts.)

>>> 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.

sure; what i meant was, if a FLOW has to have some buffering in anyway, but 
it's the presence of buffering that distinguishes CHANNEL from FLOW, then 
what's the difference?

>>> 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.

sounds like a good idea (though how many of them have been stressed enough to 
be reasonably sure they're good implementations?)

-- 
Cheers,

R.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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