Re: [lwip-users] Improving performance when using OS.

[address@hidden]

Timmy Brolin wrote:
> It seems to be known that the performance of lwip when used in a OS
> environment is less than optimum.
Well, that depends on the API used: the raw API is quite fast even if 
you are using an OS... :-)
> 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 (!)
As far as I know, these tests were *not* executed on a general-purpose 
API but based on improved code that did exactly what Frédéric wanted. 
I'm not saying the code was bad (I didn't see it), but it might at the 
end not yield exactly the performance gain he has seen after including 
all those ifs (etc.) we need to implement the (rather unperformant) 
socket API.
> [..] 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.
There's not much need in rewriting lwIP: all that needs to be rewritten 
is the API layer.
> 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)
That's what tcpip_input() already does with 
LWIP_TCPIP_CORE_LOCKING_INPUT==1 :-)
> [..] 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...
That's what you think... Sadly, there have been some issues reported 
since we introduced the locking code: in some cases it does have an 
impact after all. I do think it would be nice to have that part of the 
code stable for production code, but at the moment, I would at the least 
very strongly suggest to thoroughly test your device or review the lwIP 
code when setting LWIP_TCPIP_CORE_LOCKING_INPUT==1.

Simon