lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Improving performance when using OS.


From: Timmy Brolin
Subject: [lwip-users] Improving performance when using OS.
Date: Tue, 26 Oct 2010 20:51:32 +0200
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

It seems to be known that the performance of lwip when used in a OS
environment is less than optimum.
Some tests done in this task: http://savannah.nongnu.org/task/?6935
showed that a few changes could improve performance by a factor 2,7 (!)
The performance penalty for using lwip in a OS environment seems to be
caused by additional function depth, multiple task switching, and
message passing using mailboxes. (It takes time to allocate, post,
fetch, and deallocate messages)
The proposed fix is to replace the mailbox message passing by a
semaphore lock.

Since there is currently no actual work being done on this, I am
wondering if perhaps some of the performance improvements can be made
without rewriting lwip.

One potential easy performance boost I see is that when the Ethernet
driver has received a frame, perhaps it could use
LWIP_TCPIP_CORE_LOCKING to lock lwip and call "ethernet_input" directly,
instead of passing each frame to the lwip task using the mailbox system.
As a side effect, it becomes possible to give different task priorites
to Rx and Tx. (Ethernet driver task executes Rx, lwip_thread executes Tx
and timers)

Judging from the measurements done in savannah task 6935, this simple
change should give a significant performance boost.
It is also possible to reduce the memory footprint of lwip a little: The
function "tcpip_input" could be removed, saving some ROM, and some RAM
is saved since no messages need to be allocated to pass the frames to lwip.

Does anyone see a problem with passing frames to lwip this way?

The only problem I can see so far is that the LWIP_TCPIP_CORE_LOCK is
marked as "EXPERIMENTAL", and is not to be used in production code. But
the lock is a simple enough feature, should be safe...

Regards,
Timmy Brolin



reply via email to

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