goldsi...@gmx.de 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 _______________________________________________ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
