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

[Timmy Brolin]

Simon Goldschmidt wrote:
> Timmy Brolin <address@hidden> wrote:
>   
>> 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.
>>     
>
> Well, that depends: there should be no problem with the socket/netconn API to 
> use message passing (as if CORE_LOCKING==0), but the main loop of 
> tcpip_thread (as well as the timer-processing mbox_wait function) will have 
> to "lock the core" or it might be active in the stack at the same time as the 
> input function. To achieve that, CORE_LOCKING must be splitted into "core 
> locking available" and "use core locking from netconn API".
>   
Yes, like this: (In tcpip.h)

#if LWIP_TCPIP_CORE_LOCKING || LWIP_TCPIP_CORE_LOCKING_INPUT
extern sys_mutex_t lock_tcpip_core;
#define LOCK_TCPIP_CORE()     sys_mutex_lock(&lock_tcpip_core)
#define UNLOCK_TCPIP_CORE()   sys_mutex_unlock(&lock_tcpip_core)
#else
#define LOCK_TCPIP_CORE()
#define UNLOCK_TCPIP_CORE()
#endif

>> [..] 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.
>>     
>
> Well, the problem of separating CORE_LOCKING between TCP and UDP might be 
> that the current code does not know (or care) at those places if a netconn is 
> UDP, TCP or RAW. This would introduce additional 'ifs', I guess (which might 
> again hurt performance).
>
> Simon
>   
True... Might not be worth it.
But lwip_sendto should be possible?

Regards,
Timmy Brolin