Re: [lwip-devel] core/timers.c with NO_SYS?

[Leon Woestenberg]

Hello,

On Tue, Jun 14, 2011 at 6:16 PM, Bill Auerbach
<address@hidden> wrote:
>>That's why in an RTOS environment the interrupt handler must not do
>>the actual work; it must schedule a thread that takes the appropriate
>>lock, not an interrupt disable lock.
>>
>>Doing work in an interrupt handler is a common design mistake; the
>>interrupt handler should only make sure the interrupt is silenced
>>until serviced by a thread.
>
> Although we're getting off topic, I can't agree that it's a mistake to use
>
It's off-topic, but it's also because I'm looking forward to deal with
hard real-time systems, where neither the Ethernet interface or bad
synchronization designs impact badly on the preemptiveness of the
system. There are some industrial Ethernet standards around that are
real-time in nature, think in that scope.

> one methodology over another.  Interrupts are real-time and a designer does
> what he must to make the product stable and reliable (and work of course).

Workarounds everywhere :)

If the hardware does not buffer enough to deal with the worst case
interrupt latency, then yes, you can work around that by using
hardware scheduling (i.e. interrupt handlers running of the interrupt
vector), however you lose pre-emptiveness elsewhere. I would consider
that a design flaw - I have not seen GbE or 10 GbE adapters that
buffer less then the amount of packets that arrive during interrupt
latency, you?

> in the ISR itself.  At Gigabit high-throughput speeds the packet rate is
> impossible to *not* do inline.
>
In my practise, to the contrary; GbE and 10GbE designs typically use
interrupt mitigation, rather than handling things in interrupts. The
problem is that the per packet interrupt latency becomes larger than
the packet wire time.

lwIP might not be there yet, but I think the next line of SoC's come
with GbE alike wire or wireless speeds.

Regards,
-- 
Leon