RE: [lwip-users] Bug in pbuf.c regarding PBUF_POOL

[Pettinato, Jim]

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: address@hidden
[mailto:address@hidden 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users