[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] tcp_poll(), event handlers and possible misinformation

From: Jeff Barber
Subject: Re: [lwip-users] tcp_poll(), event handlers and possible misinformation
Date: Wed, 1 Jul 2009 10:16:49 -0400

On Wed, Jul 1, 2009 at 9:17 AM, Lou Cypher<address@hidden> wrote:
>> I'm not sure why the timer handling functions would be raising
>> interrupts.
> Well, interrupt won't come from tcp_fasttmr(), but from the caller.
> It's quite usual having hardware timers, with an automatic reload, that
> interrupt processing at a predefined rate: from there I can call 
> tcp_fasttmr(),
> tcp_slowtmr() and all the the other timing functions.
> Yes, there are issues to keep in mind, like the requirement for secondary
> functions (called from handler), like tcp_fasttmr(); they shall execute "fast
> enough" to avoid missing next timer tick.
> If lwIP processing were slower than 250 ms (TCP_FAST_INTERVAL), well... I 
> should
> better change my processor...
> Once avoided all the downsides you can have the benefit of a well defined
> tick/interrupt rate (beside interrupt response).
>>> - The interrupt stops your handler in the middle, and the timer function 
>>> finds
>>> some PCBs that need processing, calling again the tcp_recv() handler: isn't 
>>> this
>>> kind of reentrancy fatal?
>> This shouldn't happen.  The "normal" way to avoid such things is to not
>> process packets in the interrupt handler, but instead to queue them for
>> processing by the stack.  This way there is only a single thread active
>> in the stack at any one time.
> And so I will do, to avoid contention.
> My drawback is that having a co-operative scheduler I can't guarantee a 
> constant
> timer call: from some call to the next I could have some jitter.
> I presume that having 250 ms on a cycle, and 255 on the next, won't kill 
> lwIP, true?

That jitter won't kill lwIP.  Re-entering it will though.  It's your
responsibility to
make sure you don't re-enter lwIP.  I don't see any reason why you couldn't
implement a model where lwIP can be entered from any of:
1. timer interrupt
2. NIC interrupt
3. <non-interrupt event>

However, in all cases, you must make sure you don't enter lwIP while you're
already in it.

>> i.e. The tcp_poll callback is not specific to sending data, it's just a
>> method for the application to retry anything that it thinks might be
>> necessary.
> That confirms what I've experienced.
> Now I'm just trying to understand what to do when poll calls for input: I just
> analyzed a PCB passed to my poll(), nothing to transmit, no pcb->refused_data 
> to
> process, and the call to poll() has no pbuf*
> How do I manage the received data? (and how do I reach it?)

Not sure I follow this:
Poll doesn't "call for input".  The poll mechanism is for your
convenience.  You don't
have to use it.  If you have no data to process, don't request a poll.

If your recv handler gets data that it cannot process right now for
some reason, you
could simply keep a pointer to the pbuf in your own data structure, rather than
"refusing" it.  Then you could request a poll and the pbuf would be
available to you
in your poll handler.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]