Re: TCP wait_for transmit question

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 12 Jul 2012, at 01:03, Haris Rotsos wrote:
>> 
>> 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.

Definitely; the Xen Netif has a fixed set of rings slots, and the Unix backend
just uses (slow) blocking tuntap I/O.  Both apply backpressure as a result.

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

Only because our ARP support is super-minimal, and doesn't have a retransmit
timer or anything.  So you get one ARP query transmitted, and if it is lost for
any reason, we never retransmit.  I saw a few cases where we got stuck as a
result.  It's a quick job to add a retransmission timer to make it more 
RFC-compliant
though.

-anil