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

[Peter Montgomery]

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