Re: [lwip-users] CORE_LOCKING

[timmy brolin]

		From: Simon Goldschmidt address@hidden Sent: 15/7/2011 11:26:07 AM To: address@hidden Subject: Re: [lwip-users] CORE_LOCKING  Kieran Mansley <address@hidden> wrote: > > As far as I can tell, there would not be any actual code changes in lwIP > > to support individual configuration of CORE_LOCKING. > > All that is needed is: > > Replace "LWIP_TCPIP_CORE_LOCKING" with "LWIP_TCPIP_CORE_LOCKING_NETCONN" > > in all netconn files. > > Replace "LWIP_TCPIP_CORE_LOCKING" with "LWIP_TCPIP_CORE_LOCKING_SOCKET" > > in all socket files. > > Replace "LWIP_TCPIP_CORE_LOCKING" with > > "LWIP_TCPIP_CORE_LOCKING_NETIFAPI" in all netif files. > > I would be (pleasantly) surprised if that was all that was needed. > Wouldn't there be problems if for example the netconn API was configured > to use core locking, but another task was using the raw API and it had > not been configured to use core locking? Technically, it should work: the task that does not use core locking uses message passing: it passes a message to the tcpip_thread to process. Before the tcpip_thread processes the message, it locks the core and thus waits for other threads to unlock it. However, from the coding point of view, I'd be surprised, too, if the above changes would be enough to make it work. I guess we would need some more ifdef'ed defines since some macros are changed based on core locking mode. It can be done, but it requires work. Being like that, I'd rather fix things that don't work instead of adding these defines. One main question I have here is: why do people want to use core locking? The benefits I see are priority inversion (as one locking mutex is used instead of multiple "message-passing" mutexes) and speed (no task change). Anything else? Simon --
		Speed is one important factor (no task change, no mbx communication, no msg applocation/deallocation). Secondly, I think there is a big opportunity to reduce the memory footprint of lwIP here. There is one additional function depth for every function in the APIs just to handle the message allocation/deallocation, mbx posting/fetching, and error handling. All those extra functions could basically be removed if calls can instead be made right into the lwIP stack. The Ethernet driver could for example perhaps call etharp_input directly instead of tcpip_input, which saves function depths as well as message allocation/posting/fetching/deallocation/error handling. netconn and raw could perhaps even be merged into a single API, saving lots of API functions. All messages passed are dynamically allocated RAM. I think that for systems with limited RAM, dynamic RAM allocation should be kept to a minimum. It saves RAM, improves the determinism of lwIP (reduced chance of a failure due to empty dynamic memory pool), and simplifies lwIP (no need for error handling in case message could not be allocated or posted) /Timmy Brolin

_______________________________________________________________
Hitta ditt drömjobb - Turism Försäljning Vårdjobb Ekonomi Design Bank Media