[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.
Jeff
- [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Kieran Mansley, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation,
Jeff Barber <=
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, address@hidden, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, address@hidden, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/02
- RE: [lwip-users] tcp_poll(), event handlers and possible misinformation, Bill Auerbach, 2009/07/01
RE: [lwip-users] tcp_poll(), event handlers and possible misinformation, Bill Auerbach, 2009/07/01