|
From: | Jonathan Larmour |
Subject: | Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue |
Date: | Sun, 01 Feb 2009 20:01:36 +0000 |
User-agent: | Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |