Re: [lwip-users] lwIP reentrancy issues and TCP

[FreeRTOS Info]

Just my 2 cents on this - which is probably not exactly helpful to the
subject being discussed.  Maybe I'm just griping...

This is a common "sub-optimal" design found in lots of TCP/IP
integrations, and not just designs that use lwIP.  In fact, I see it all
the time in USB drivers too, not even TCP/IP.

Something like lwIP, (correct me if I'm wrong) was originally designed
for use in resource constrained systems.  Systems where it might not be
practical or desirable to use multitasking.  Therefore, polling status
registers from a non-interrupt loop makes sense.  That does not prevent
it from being used with an RTOS of course - you just make the loop
execute in a task, and set the priority of the task as appropriate for
the application being developed - or do something more clever with
mutexes, etc.  Likewise, if you don't have an RTOS and the stack (be it
USB or TCP/IP or whatever else) has high priority, it can run in an
interrupt if the non-determinism that arises from that is not going to
break your real time requirements.

The problem comes when people mix these design patterns up.  Time and
time again people complain to me that something (i.e. middleware) is
'broken' or 'unusable' of 'not designed very well', and when you look at
it the problem stems from them not understanding how to perform
integration successfully, and creating a system that has the bad
characteristics of all design patters, and very few of the good
characteristics.  The classic case is running half the code in an
interrupt while simultaneously running some code out of an interrupt.
The classic symptom that raises the alarm is when somebody attempts to
use a critical section from code that runs in an interrupt.

Talking RTOS only, because that is what I do day to day, I would
normally have the interrupts do nothing other than send a message from
the MAC to the task running the stack.  The message would be "Rx end" so
you know something is there to process, or "Tx end" so you know a buffer
at the driver level can be re-allocated to be an Rx buffer again.  The
message would unblock the task that runs the stack so the message can be
processed, and the priority of the task is determined only by the
requirements of the system being developed.  It can pre-empt less
important tasks or just wait until higher priority tasks have nothing to do.

If you want your application to act as a client and initiate
communications you just extend the messaging system so messages can be
sent to the task running the stack from the application itself.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.



On 24/06/2011 23:30, Peter Montgomery wrote:
> Simon,
> 
> Sorry about new email vs. renamed email.  I didn't realize the mailer
> was doing some hidden JuJu in the email headers.  I was just
> re-subjecting a reply as a fast way to get the email address in the
> outgoing email.
> 
> I'm a bit confused by your answer, so I have some more questions.
> 
> You say that lwIP was designed to be run entirely from foreground (FG
> for short) code, with the Ethernet hardware interrupt handler merely
> setting a flag that the FG code polls.  So the entire system was
> designed to be run in a polled mode?  I guess this presupposes that the
> FG would never get stuck doing something that took a little too long,
> and fail to poll in a timely manner.  That seems awfully hard to guarantee.
> 
> You also say Stellaris is a bad example of an lwIP implementation.  I
> wish that was noted loudly somewhere, as this is the first time I have
> heard this information.  Clearly there are more people using lwIP on
> Stellaris than just me, so there must be solutions.  Unfortunately,
> since you are the first person (and only that I've found so far) to
> state that lwIP for Stellaris is bad, I'm turning to you for help.
> 
> Given that the Stellaris implementation is poor, what can I do to work
> within it?  Since Stellaris has lwIP running completely in interrupts,
> what's the best way for me to get messages from the FG to lwIP's
> interrupt code?
> 
>     Thanks,
>     PeterM
> 
> 
> On 6/24/2011 1:36 PM, Simon Goldschmidt wrote:
>> First, please make sure you create a mail for a new thread instead of
>> replying to an old mail and simply changing the subject: this confuses
>> my mail app since it sorts by thread Id, not by subject.
>>
>> Peter Montgomery<address@hidden>  wrote:
>>> Is lwIP really engineered so that the most logical situation
>>> (incoming TCP handled in the interrupt handler, "tcp_write" called
>>> from the foreground) is not allowed?
>>
>> Yes, it is. (BTW, it might be the most logical situation to you, but
>> that's not really an objective statement.) The reason for this is that
>> the core lwIP code is only supposed to implement the networking code,
>> not the interface to your hardware, OS, or timing requirements.
>> Depending on whether lwIP is the highest priority software in your
>> application or only low priority, you need to handle this differently.
>>
>> The original intention behind lwIP was to run without an OS and to let
>> the Ethernet RX interrupt set a flag when new packets arrive. Then,
>> the main loop has to check this flag and pull packets off the
>> hardware, feeding them into the stack. This way, you may also call
>> into the stack from the main code, as interrupts do not use lwIP.
>>
>> In this mode, timer functions are also executed from the main loop by
>> checking a timer value, not from a timer ISR.
>>
>> Unfortunately, the stellaris code is a bad example here in that it
>> calls into lwIP from interrupt level. This is confusing for lwIP
>> beginners, since it can easily lead to concurrency problems when using
>> lwIP from the main loop, too (or from other interrupt levels).
>>
>>> Even with "SYS_LIGHTWEIGHT_PROT " set to 1 ?  Shouldn't the
>>> lightweight protection be the kind of thing that handles this?  If
>>> not, what are the situations that "SYS_LIGHTWEIGHT_PROT" handles?
>>
>> Currently, it provides concurrency protection for allocating and
>> reallocating memory or pbufs only. By design, it cannot provide what
>> you want: you would have to disable the interrupt while calling into
>> lwIP to provide such kind of protection. To me, that's not
>> "LIGHTWEIGHT" :-)
>>
>> Passing received packets into lwIP at interrupt level is generally
>> only a good idea if you do need minimal latency between RX and TX. For
>> all other scenarios, the original approach should be favored.
>>
>>>
>> Simon
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>