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