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

[Timmy Brolin]

address@hidden wrote:
> 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
>
Ok, thanks for the input.
That is why I posted on the mailing list. To get an impression of the
potential risks and problems involved.
We have a UDP-loop application using the netconn interface (it responds
to any UDP frame by sending another UDP frame). It takes approximately
500µs for a UDP frame to be received by the device, sent up to the
application layer, and then looped back out on the network.
I was hoping for a bit higher performance than that. (Running on a
100MHz 32bit system with zero copy Ethernet driver).
CORE_LOCKING should at the very least get rid of two memory allocations,
two deallocations, two task reschedules, and reduce function depth. That
has to make some kind of difference.
We'll probably do some tests to evaluate exactly how much performance
can be gained, and from that decide if it is worth the additional risk
and testing time.

Regards,
Timmy Brolin