[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] lwIP reentrancy issues and TCP
From: |
Simon Goldschmidt |
Subject: |
Re: [lwip-users] lwIP reentrancy issues and TCP |
Date: |
Fri, 24 Jun 2011 22:36:06 +0200 |
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] Data sending problem over TCP, Sanchayan, 2011/06/22
- Re: [lwip-users] Data sending problem over TCP, Tim Lambrix, 2011/06/22
- Re: [lwip-users] Data sending problem over TCP, Sanchayan, 2011/06/22
- Re: [lwip-users] Data sending problem over TCP, Tim Lambrix, 2011/06/22
- Re: [lwip-users] Data sending problem over TCP, Sanchayan, 2011/06/22
- [lwip-users] lwIP reentrancy issues and TCP, Peter Montgomery, 2011/06/24
- Re: [lwip-users] lwIP reentrancy issues and TCP,
Simon Goldschmidt <=
- Re: [lwip-users] lwIP reentrancy issues and TCP, Peter Montgomery, 2011/06/24
- Re: [lwip-users] lwIP reentrancy issues and TCP, Simon Goldschmidt, 2011/06/25
- Re: [lwip-users] lwIP reentrancy issues and TCP, FreeRTOS Info, 2011/06/25
- Re: [lwip-users] lwIP reentrancy issues and TCP, FreeRTOS Info, 2011/06/25
- Re: [lwip-users] lwIP reentrancy issues and TCP, AjK, 2011/06/25
- Re: [lwip-users] lwIP reentrancy issues and TCP, FreeRTOS Info, 2011/06/27
- Re: [lwip-users] lwIP reentrancy issues and TCP, AjK, 2011/06/27
Re: [lwip-users] Data sending problem over TCP, Kieran Mansley, 2011/06/23