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

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

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?

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

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

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