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 stack directly in the ISR... but allocating a pbuf in the ISR to hold the packet (and getting it cleared from the hardware queue) prior to signaling the task level driver is a valuable ability. It makes the task-level driver code much simpler and avoids double-buffering input packets. I acually have a small array of type (pbuf *) used as a ring buffer - so if the non-deterministic scheduler holds up my task-level driver, all the packets can be processed without loss quite easily. Some of the reason I'm faced with doing this is the fact that my Ethernet hardware (SC91C111) only has 4 2K buffers in the hardware queue, so you don't have much time on a 100M link before they fill up. Now I could have used a permanently allocated array of packet buffers for the ISR... but you know how memory constraints go... - Jim __ James M. Pettinato, Jr. Software Engineer FMC Technologies Measurement Solutions Inc. 1602 Wagner Avenue | Erie PA | 16510 USA Phone: 814 898 5000 | Fax: 814 899-3414 www.fmctechnologies.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leon Woestenberg Sent: Thursday, November 16, 2006 2:15 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] Bug in pbuf.c regarding PBUF_POOL Hello all, On Sun, 2006-11-12 at 01:43 +0000, Jonathan Larmour wrote: > Leon Woestenberg wrote: > > The SYS_LIGHTWEIGHT_PROT protection was introduced by one of the > > developers using the stack to protect *ONLY* between interrupt > > context and single-thread user-space context if I am not mistaken. > > > > I am all for removing it, because the locking solution does not > > scale across different platforms. > > I was actually arguing the other way round I'm afraid :-). I was > arguing > As said, I have been away from the lwIP stack too long, so I should have shut up in the first place. However... > that it looks to me that SYS_LIGHTWEIGHT_PROT is essentially mandatory > because packets arrive asynchronously and so pbuf allocation needs to > have some protection no matter what since the allocation will take > place from a device driver. That would be true whatever the context, > or whether single or multi-threaded. > In a fully pre-emptive environment (like full-blown eCos), this light-weight locking mechanism must then disable the Ethernet chip receive interrupt, to prevent concurrent access to the pbufs, during LIGHTWEIGHT_PROT locks from non-interrupt context. I would certainly design a pre-emptive system by NOT entering the pbuf layer from interrupt context, but instead schedule a high-priority real-time task to move the packets of the chip from the interrupt handler, and nothing more. We have a proven real-time pre-emptive design (even with nested pre-emptable interrupts) that does not use SYS_LIGHTWEIGHT_PROT but uses the "bottom-half" approach. This is using the open-source, non-free uCOS-II RTOS. If I am completely mistaken, I will probably be corrected by my colleague Christiaan :-) > The !SYS_LIGHTWEIGHT_PROT code simply doesn't give any thread or > interrupt > safety at all. So in fact the !SYS_LIGHTWEIGHT_PROT code does not appear > to solve the problem it seems intended to solve. Hence me saying that that > code should be removed entirely since as far as I can tell it doesn't > achieve anything. If protection is needed, something using > SYS_LIGHTWEIGHT_PROT is the solution. I am NOT sure if SYS_LIGHTWEIGHT_PROT protects against all concurrent acccess possible, I thought this was exactly the reason why it was called lightweight when introduced. Pushing a packet into the stack will have a chain reaction where all higher-level layers are called into. I would not run this from interrupt context. I am against removing the !SYS_LIGHTWEIGHT_PROT code for the above reasons. :-) Regards, Leon. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
