[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] Re: [task #7040] Work on tcp_enqueue
From: |
Jakob Stoklund Olesen |
Subject: |
[lwip-devel] Re: [task #7040] Work on tcp_enqueue |
Date: |
Sun, 01 Feb 2009 22:28:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Jonathan Larmour <address@hidden> writes:
> Jakob Stoklund Olesen wrote:
>> 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.
OK, so it should be possible. It was probably a bug on my side, 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.
Right, snd_buf is almost certainly bug-free. The thing is, snd_buf is
updated immediately after pcb->acked is calculated. TCP_EVENT_SENT is
invoked in another function, outside lots of scary if branches. Could
TCP_EVENT_SENT perhaps under unfortunate circumstances be called twice
with the same pcb->acked before it is cleared or recalculated?
I would feel safer if pcb->acked were cleared immediately after invoking
TCP_EVENT_SENT. It is not used for anything else, so that would be OK, I
think. Alternatively, you could move it into a global variable and clear
it before tcp_process.
I am not saying there is a problem, I just like to convince myself that
code works the way I expect.
/stoklund
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, (continued)
- RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, bill, 2009/02/02
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, address@hidden, 2009/02/02
- RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, bill, 2009/02/02
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, address@hidden, 2009/02/02
- RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, bill, 2009/02/02
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, address@hidden, 2009/02/02
- RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, bill, 2009/02/03
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, Jonathan Larmour, 2009/02/04
Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, Jonathan Larmour, 2009/02/01
- [lwip-devel] Re: [task #7040] Work on tcp_enqueue,
Jakob Stoklund Olesen <=
[lwip-devel] Re: [task #7040] Work on tcp_enqueue, Jakob Stoklund Olesen, 2009/02/01
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, Kieran Mansley, 2009/02/02
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, Kieran Mansley, 2009/02/03
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, Alain M., 2009/02/03
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, address@hidden, 2009/02/03
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, Alain M., 2009/02/03
- Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue, address@hidden, 2009/02/03