lwip-users
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]