lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] Assert failure


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] Assert failure
Date: Wed, 08 Jan 2003 22:06:30 -0000

Hi Kieran!

On Friday 04 January 2002 16.22, you wrote:
> I'm developing lwIP for what is, I expect, a rather different application
> to most - high performance low latency LANs.  I don't expect to be able to
> use lwIP as it stands (in fact I will probably have to reimplement large
> portions of it to achieve the performance we require) as it's been
> designed with very different applications in mind, but its clean code and
> lightweight nature make it an excellent choice (so far!) to base a new
> stack on.

It is interesting to see lwIP being used in new ways! I would be very 
interested in hearing what parts you need to reimplement to achieve your 
performance and what you need to do. I would assume that heap memory 
management could be made quicker if more memory is avaliable; block 
allocations and such could probably increase performance in particular for 
systems with MMUs. If you are planning to use Linux, you might as well 
#define the mem_ operations so that they map directly to kmalloc() and 
kfree(), which probably is faster than the generic lwIP heap memory manager. 

For the protocols, hashing is a good way to increase performance for lookups. 
In order to boost TCP performance, the RFC1323 extentions should probably be 
considered.

> I've grunged through the internals of the code, and think I may have found
> the cause of this.  I'm hoping it's a bug in the lwIP code anyway, as I
> don't see how I could misuse the stack to cause a inconsitency in its
> internal state such as this.
>
> The offending code is in tcp_process().  In the "case SYN_SENT" section an
> item from the pcb->unacked list is removed and freed, but snd_queuelen is
> not updated to reflect this.  Is this correct, or should it be updating
> its internal state at this point as I suspect?

You are right; it is a bug, thanks for spotting it! pcb->snd_queuelen should 
be decreased by one to reflect the fact that one segement is removed from the 
->unacked list.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]




reply via email to

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