|
From: | Jonathan Larmour |
Subject: | Re: [lwip-users] Bug in pbuf.c regarding PBUF_POOL |
Date: | Fri, 17 Nov 2006 17:56:22 +0000 |
User-agent: | Thunderbird 1.5.0.8 (X11/20061107) |
Pettinato, Jim wrote:
Leon et al, I agree completely... If you have a pre-emptive OS, the interface need only signal it needs serviced; a high-priority task can handle feeding packets into the stack. Without such a prioritized platform though, performance would be severely degraded if handled any other way than directly in the ISR. I also agree that I wouldn't push a packet all the way up the stackdirectly in the ISR...
Just in case, no-one so far has been suggesting passing the packet into the stack from an ISR, but I think the rest of your mail shows you do know that :).
I'm not sure a high priority task is sufficient, if that task can block for an indeterminate time waiting for a lower priority task (semaphores suffer from priority inversion). So it really makes no difference whether it's called from a high priority thread or a bottom half - we don't want to block either way round.
If PBUF_POOL pbufs were only allocated from a single context (and different bottom halfs would be sufficient for this, for example), this could all be avoided; but they aren't. It's not clear to me why many of these calls are from PBUF_POOL, rather than PBUF_RAM.
Incidentally, having to have a bunch of threads around to handle these sorts of issues is a big waste due to the extra thread control blocks and thread stacks - precious memory in the context in which lwIP is intended to be used. Personally, I'm changing lwIP not to rely on such a model for ethernet at least - for me it's a simple change in fact.
Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts ------["The best things in life aren't things."]------ Opinions==mine
[Prev in Thread] | Current Thread | [Next in Thread] |