[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Feeding incoming packets to lwIP
From: |
Dan Lewis |
Subject: |
Re: [lwip-users] Feeding incoming packets to lwIP |
Date: |
Wed, 15 Jan 2003 15:31:36 -0800 |
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