Re: TCP wait_for transmit question

[Haris Rotsos <cr409@xxxxxxxxxxxx>]

On 11 July 2012 16:48, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 11 Jul 2012, at 22:06, Balraj Singh wrote:
>
>> This is what the write buffer is supposed to do and it definitely
>> improves overall performance.  It allows the app and tcp to not be in
>> lock step.  The app can dump a chunk of data to be sent in the write
>> buffer, when tcp gets acks that open up the window it has data ready
>> to be sent.  This buffer also needed to implement Nagle's algorithm.
>>
>> This is what was implemented:
>>
>> When the app does a write:
>>
>>    if (write buffer is not empty) {
>>        if (adding pkt to buffer will make the total bytes buffered
>> more than a configured max value) {
>>          block till buffer becomes available, then attempt a write again
>
> It's this above logic (blocking until the buffer becomes available) that I was
> trying to spot.  The code excerpt from user_buffer.ml is:
>
>     match Lwt_sequence.is_empty t.buffer &&
>       (l = mss || not (Window.tx_inflight t.wnd)) with
>     | false ->
>         t.bufbytes <- Int32.add t.bufbytes l;
>         List.iter (fun data -> ignore(Lwt_sequence.add_r data t.buffer)) 
> datav;
>         if t.bufbytes < mss then
>           return ()
>         else
>           clear_buffer t
>
> So if the buffer is not empty and we have enough, it clears the buffer.  
> However,
> where is the check against max_size if the amount of total buffered data 
> increases
> to a large amount? I can't see any path where the t.writers blocking set is 
> appended
> to except in the wait_for_* functions.
>
> Haris, was your test case just calling Tcp.Pcb.write continuously and finding 
> that
> it ran out of memory?

yes. And by the way, because the code is written over the ns3
simulation platform, I think the a call that that pushed packets to a
network interface will never block. The simulation hasn't got this
requirement fixed yet.

This I guess in the case of xen or unix, will be handled with more
care as the write may block and create naturally a context switch in
the thread scheduler.

>
> In that case, it may be a regression that is the same problem as the ARP race
> condition (the OS.Netif.write is now too asynchronous).

why would that affect the arp functionality?

>
> -anil



-- 
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@xxxxxxxxxxxx