David,
A little retrospective follow-up... :-)
As I understand it, your patch is designed to protect critical sections in memp.c and pbuf.c against preemption by your interrupt service routines. However, my case is a little different: Since my ISR doesn't call any lwIP functions, I only have to worry about protecting critical sections in memp.c and pbuf.c against preemption by other threads.
In memp.c, your patch changes the critical section protection from semaphores to disabling interrupts. While I can understand that this is required when an ISR makes direct calls to lwIP functions, I don't think it is necessary for me since semaphores provide an effective means of protecting against preemption from other threads.
I haven't looked closely yet at your changes for pbuf.c. You had mentioned that
there were several critical sections in pbuf.c that were not protected. Do you
mean that they are not protected against preemption by an ISR that calls lwIP
functions even though they are already protected by semaphores (as in memp.c)?
Or are they simply not protected at all?
All the best,
Dan Lewis, Chair
Computer Engineering
Santa Clara University
address@hidden 1/14/03 2:06:38 PM >>>
Dan,
I am using an interrupt-driven multi-threaded implementation. Yes, I did
have some problems.
You need to watch for the protection in memp.c and pbuf.c. There are
many areas which are not protected well and do need to be. In my case, I
am using pbuf buffers in my ISR and I found I needed to add protection
in order to do that. If you are calling tcpip_input from another thread
you definitely will need to add this protection and I recommend added
protection in memp.c as well.
Please look at patch 873. This code adds this protection in the form of
disabling and enabling interrupts through function calls in sys_arch.c.
I have had very good luck since I added this code. I am using a chargen
server as a test program and I have run this overnight from multiple
sources with no problems until today. Unfortunately, I did just find a
statistics problem which I am looking into. I will issue a patch if the
problem is in the protection code.
David.
Dan Lewis wrote:
Dear lwIP people,
What's the recommended way to feed incoming packets up to lwIP in an
interrupt-driven multi-threaded implmentation?
The interrupt service routine in my current implementation merely signals the
arrival of a packet by posting to a uC/OS mailbox. I created a separate thread
that contains an infinite loop that pends on that mailbox, and then calls
ethernetif_input to read the packet from the NIC (using low_level_input) and pass
it on to lwIP (using netif->input, which is a call to tcpip_input).
So the real question is this: Is it safe to initiate the call to tcpip_input
from an independent thread in a preemptive multi-threaded system? I.e., does
tcpip_input use kernel calls to pass the packet on to lwIP (which is running in
a different thread)? Or do I need to worry about critical sections in this
scenario?
Note that in addition to tcpip_input, ethernetif_input also calls arp_ip_input,
arp_arp_input, pbuf_header, and pbuf_free. Are these routines also thread-safe?
Is there a better way to feed incoming packets to lwIP in this kind of
environment?
Thanks in advance!
Dan Lewis, Chair
Computer Engineering
Santa Clara University
_______________________________________________
lwip-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/lwip-users