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

[Timmy Brolin]

address@hidden wrote:
> Timmy Brolin wrote:
>> 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).
> The risk for UDP-only should not be too high. TCP is more complicated
> because in some cases, the original thread is sent to sleep until the
> RX- or timer-thread finishes the work and wakes the application
> thread. UDP does not have these such situations.
That is interesting. Perhaps LWIP_TCPIP_CORE_LOCKING could be split to
two separate defines. One to enable locking for netconn UDP and one for TCP?
>>   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.
> I might be wrong, but using the raw API, the time to change the
> application might be higher, but both the time for testing and the
> risk should be lower. Using CORE_LOCKING and the raw API, you might
> even get away with no thread change at all. Given the fact that the
> netconn API is not really portable, too, you wouldn't even lose
> portability :-)
That is certainly a interesting possibility!

I had a look at the new lwip 1.4. It looks like
LWIP_TCPIP_CORE_LOCKING_INPUT is conditional on LWIP_TCPIP_CORE_LOCKING.
But that is not really necessary, is it?
I think it should be possible to enable only
LWIP_TCPIP_CORE_LOCKING_INPUT, without enabling CORE_LOCKING for the
netconn and socket APIs.
This would be a simple change with little risk, since as you already
pointed out, the highest potential risk is in the APIs.
In all, why not have three separate defines, such as:
LWIP_TCPIP_CORE_LOCKING_INPUT
LWIP_TCPIP_CORE_LOCKING_UDP
LWIP_TCPIP_CORE_LOCKING_TCP
And implement them so that they can be enabled individually. If _INPUT
and _UDP can be made stable without too much effort, then people could
start using those, and continue using the traditional mailbox system for
TCP until core locking for TCP becomes a bit more stable.

Regards,
Timmy Brolin