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: David Haas
Subject: Re: [lwip-users] Feeding incoming packets to lwIP
Date: Wed, 15 Jan 2003 23:25:10 -0500
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

Dan,

The issues are the same whether you disable ISRs or use a semaphore. By the way, I updated the patch today because I wanted to bring it up to the latest lwip level (today) and also because I found that I had not protected changing the stats and my pbuf stats lost counts.

So here is the bottom line: If you ever use the same pbuf in multiple threads, you will need the added protection. If not, then it is possible that the existing protection will work for you. I am writing this at home and don't have access to my source code, but if I remember right, the problems in memp are an issue if you use the non-raw API. I'll have another look at that tomorrow.

I did not "change" the protection to disabling interrupts. There was no protection previously at all. I don't count the lock variables as protection. The problem with the lock variables is that allocation can fail. That is unacceptable. It means that you will drop frames. Timing can be a funny thing. I bet there are some circumstances where you will not just drop one, but if the timing is just right (and it tends to repeat) you will drop ALL the frames. pbuf and memp allocation absolutely should not fail unless you are really out of memory.

Now I know that there are embedded systems where you can't disable interrupts, so this is a problem. However you don't really need to disable interrupts, only add protection. You could implement your sys_disable_interrupts() by using a semaphore.

I will say that if it is performance you are after and you can stand disabling interrupts for a short time, it is the absolute fastest way to attain critical region protection. pbuf allocation and deallocation is an area which is very speed sensitive. Using a semaphore will cost you significantly (especially with the coupled timer-semaphore implementation in lwip).

So if your ISR does not call any lwip functions, how do you get the ethernet data from your chip to memory and then to lwip. How many copies are involved?

I was involved in a SW-based bridge router a number of years ago. Using a 20Mhz AMD 29K processor, we were able to bridge thirteen 10mb ethernets in SW at wire speed. There were no copies in the software. You dma in to mbufs, move pointers around and then dma right out of the same memory. Using the same architecture, we went to a 25Mhz 68360 (remote-access router this time) and were able to support 64 V90 modems routed to a single 10mb ethernet at wire speed. Again, all packet processing was done in SW.

Of course, I'm not building a bridge or a router now, so I'm not that sensitive to the speed isssue, but several people have been asking about speed. You have to look carefully at the overall design. The speed of the stack itself is probably of less importance.

David.


Dan Lewis wrote:

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







reply via email to

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