[ECOS] Re: Urgent Help: ether_demux function

Andrew Lunn andrew@lunn.ch
Tue Sep 20 08:41:00 GMT 2005

On Mon, Sep 19, 2005 at 05:46:19PM -0700, mkhoyila@uci.edu wrote:
> Hi Gary and Andew,
> I can see what the issue is, but I do not know how to solve. From my dsr I
> call:
> while ( !(pDevCtrl->rxBds[pDevCtrl->rxHeadIndex].status & DMA_OWN)
> 	(sc->funs->eth_drv->recv)(sc, pDevCtrl .....);
> this loops through as long as packets are coming and I checked from
> eth_drv.c the function ether_input.c is being called which calls
> ether_demux.
> ether_demux queue them in ip_input queue and schedule a software interrupt
> for ipintr to pick up the packets in the queue. if packets are coming
> beyond 100 packets/sec, then software interrupt is NOT generated and after
> first 50 packets received, all are dropped. ipintr is called at the end
> and at that time only first 50 packets are in the queue.

So you need to find out why the software interrupt is not
generated. How many packets per second are you actually sending to the
device? If you are sending 10000 of 64byte packets per second it is
possible the CPU is spending all its time simply throwing away packets
and has no time to process those in the queue. 

If the problem really is your device is spending all its time throwing
stuff away rather than processing new packets what might help is to
change the order of CYGPKG_NET_THREAD_PRIORITY and
CYGPKG_NET_FAST_THREAD_PRIORITY. ie make the FAST thread lower
priority than the other thread. You should then find that the device
driver does the discard because it is always overflowing its receive
buffers and the network stack gets to process every packet it


Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list