Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue

[Jonathan Larmour]

Jakob Stoklund Olesen wrote:
> In my first attempt at zero-copy TCP, I used the non-copying version of
> tcp_write. The adaptation layer code would hold on to the data until the
> tcp_sent callback indicated that it was safe to release the memory.
>
> It didn't work. I think I misunderstood the meaning of the len parameter
> to the tcp_sent callback. I did something like this:
>
> my_tcp_sent(arg, pcb, len)
> {
>   accu += len;
>   if (accu >= first_buffer.len) {
>     accu -= first_buffer.len
>     free (first_buffer)
>     first_buffer = next_buffer
>   }
> }
>
> It worked most of the time, but TCP retransmissions caused bad stuff to
> happen. It was either a bug in my code, or the sum of callback lengths
> did not match what had been actually sent.
>
> Has anybody used non-copy tcp_write with memory that must be reclaimed?
> Can it be done?

I'm going to have to reply to the rest of this thread when I have more 
time (lots of discussion to digest for a weekend!), but I can confirm from 
my zero copy implementations that I didn't see a problem in this area. 
However I can't guarantee how many retransmissions I've had. But it's been 
used in low memory situations, so I'd expect it ran out of pbufs some 
times and would have caused retransmissions occasionally then.

But given the 'sent' event handler is called according to pcb->acked, and 
pcb->snd_buf is also updated according to pcb->acked, if there was a bug 
in lwIP code, I'd expect the snd_buf to start drifting from reality and 
problems to show up fairly rapidly.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine