[lwip-users] lwIP RAW API and "deferred processing" in different context

[Ueli Niederer]

Hi everyone

As the explaination for this question is a little bit longer, I just  
wanted to put my question at the beginning of my post. For the  
explaination see below:
  - Am I missing something if I wrap every tcp_*-call and the  
relevant portions of a callback in SYS_ARCH_PROTECT/SYS_ARCH_UNPROTECT  
calls if I want to cross a context border?
  - Is it correct, that pbuf_*-calls and memp_*-calls are already  
constructed thread-safe?
  - Are ther other pits, traps or mines to step on while trying to  
cross the context border using the RAW-API?

Why these questions?

I'm working on a project for a Stellaris controller, based on a demo  
project incorperating the lwIP Stack V1.3.2 ported by TI. Since there  
is no operating system in the project, NO_SYS is set to 1 and I have  
to use the raw API to implement the TCP server. As far as I  
understand, I have to do every call of tcp_* style functions (e.g.  
tcp_write, tcp_close, ...) from the same context as the callbacks are  
called to avoid race conditions.

In their Stellaris port TI's engineers decided to drive the whole lwIP  
Stack by the Interrupt generated through the MAC peripheral. This  
includes servicing the lwIP Timers and the tcpip_input function. (In  
my opinion this is a little bit crude as the handling of timeouts in  
lwIP is not guaranteed anymore if there is no ethernet traffic. But  
that's a different story) As a consequence all the callbacks are  
called from that ISR context too.

If I do all the server stuff in the callbacks, all the server side  
processing of the received data is done in the ethernet ISR. This  
seems a bad idea to me as processing the received data and computing  
the answers could be a bigger task, consuming a notable amount of  
processor cycles.
So what I wanted to do is to use the callbacks simply in a "interrupt  
style" where for example the received pbufs and events are just sort  
of queued up for a later processing in context of the main function  
where computing time is given to a "worker function". One could  
imagine the receive handler to be something like this:
    if (worker->received.data == NULL)
    {
        worker->received.data = p;
        worker->received.offset = 0;
    }
    else
    {
        pbuf_cat(worker->received.data, p);
    }

In case of error etc. something similar will happen: The events are  
handled but finally processed somewhere else. Somewhere else in the  
real worker function the data is then read, dequeued processed, an  
answer will be prepared sent using a (thread-safe) derrive of tcp_write.

As a result the processing of TCP/IP and the processing of the data  
stream are decoupled, giving the application designer full control  
over the context where the data processing happens and the speed of  
data processing.

Thank you in advance for your help

Regards
Ueli