TCP/UDP input/output functions are not guaranteed to be threadsafe. Only memory management and pbuf functions have that guarantee. Therefore, the ethernet driver should defer all packet processing to thread context via scheduled events, since a race condition could easily occur.
TCP/UDP input/output functions are not guaranteed to be threadsafe. Only memory management and pbuf functions have that guarantee. Therefore, the ethernet driver should defer all packet processing to thread context via scheduled events, since a race condition could easily occur.
See here: http://lwip.wikia.com/wiki/Raw/native_API
The
k64f_enetif_input
function is probably the prime candidate for deferring.This function calls through to
ethernet_input
inetharp.c
, which performs many functions that are not guaranteed to be irq safe.I suggest making the following change:
This is greatly oversimplified, since it k64f_emac.c is not C++