Xen project Mailing List

Hi,

On Fri, Jun 20, 2014 at 11:53 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

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

>>>

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

The buffers all take different forms though -- unless the application specifically knows that it's a TCP flow, it can't take any sensible action based on predicted congestion behaviour. ÂAnd this would be entirely wrong behaviour if the buffer size it gets back is actually a (lossless) vchan ring buffer size instead.

So my point is that rather than exposing the buffer size as an integer, it would be worth figuring out some use cases for when applications would need to know the buffer size (as opposed to, for example, having a high level "sendfile"-style API that provides more declarative knowledge to the lower levels of the communications stack).

I think I'm confused about 2 separate questions :-)

I wonder whether we should extend flow to have all 4 of {read,write}{,_ack} Âso that we can control when data is acked/consumed. The TCP implementation would then only call the _ack function when it had received confirmation the data had been processed. If the TCP implementation needed to resend (possibly after a crash) it could call 'read' again and get back the same data it had before. So the result of 'read' would be an int64 stream offset * Cstruct.t, and 'read_ack' would mark an int64 offset as being consumed. This is what I'm doing in xenstore and shared-memory-ring: I don't know if anyone else wants this kind of behaviour. In the case where a VM sends a block write, which is then sent over NFS/TCP it would allow us to call write_ack on the flow to the guest when the TCP acks are received.

Separately, in the case of vchan the buffer size is set at ring setup time. If you connected a vhan ring to a TCP transmitter then the TCP transmitter, presumably with it's higher latency link, would try to keep its link full by buffering more. If the vchan ring size is smaller then the TCP window size (likely), TCP would have to copy into temporary buffers. If we knew we were going to need more buffered data then we could make the vchan ring larger and avoid the copying? Perhaps that wouldn't work due to alignment requirements. Anyway, this is more of a 'flow setup' issue than a during-the-flow issue. Perhaps a CHANNEL would be where we could close and re-open flows in order to adjust their parameters.

Cheers,

Dave

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