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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
