lwip-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]