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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 18 Jun 2014, at 18:46, David Scott <scott.dj@xxxxxxxxx> wrote:

> Quick update:
> 
> mirage-types.1.1.3 has the FLOW signature (with the errors on write that Anil 
> suggested).
> 
> vchan.0.9.7 now exports FLOW rather than the old string-y extra-copying 
> interface. Jon: to make this work with cohttp we're going to need some kind 
> of FLOW -> cohttp adapter.

I'm looking into that as part of my Conduit hacking (update on that as soon as 
it fits together again).

> 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. 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, and we could expose TCP buffers or the vchan ring 
size.  What use would this information be to an application, though?

If you noticed the recent DNS Io_page fix, I do like the model of allocating 
write-path buffers from the Flow itself.  This would give a future vchan the 
option of allocating buffers directly into the shared ring, thus avoiding a 
copy.  For most Flows like TCP, the memory allocator would just pass through to 
Io_page (but could also hook into a memory pool/logging library)

-anil


> 
> Cheers,
> Dave
> 
> 
> On Mon, Jun 16, 2014 at 10:33 AM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> 
> wrote:
> I'm a bit late in the discussion, but:
> 
> > * consoles
> > * xen inter-domain vchan connections
> > * plain TCP
> > * (hopefully) TLS connections
> 
> For git, we also need in/out channels over the execution of an SSH program 
> execution (ssh <url> git-fetch-pack <args>). I think your change will also 
> allow to do that so that's good :-)
> 
> Thomas
> 
> 
> 
> -- 
> Dave Scott
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


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