Thanks for your response. I can see that the skb is just queued. So how can this queuing take several milliseconds sometimes, when mostly it takes 5 microseconds? i.e. this is the time spent in the function netif_rx! Kevin -----Original Message----- From: Suresh Singh K. [mailto:sureshsingh.keisam@analog.com] Sent: 13 November 2002 14:57 To: Kevin Curtis; linux-net@vger.kernel.org Subject: Re: possible delays in netif_rx Hi, From your descriptions , you are calling " netif_rx" in the interrrupt context. So netif_rx just queues the packets in the processor specific queue and simply mark the NET_RX_SOFTIRQ softirq FLAG. Next time when the kernel thread "sofirqd" is scheduled , it executes the RX softirq. As the version you are using is a non-preemptive kernel, the control paths are all non-deterministic. So the longer interrupt processing will definitely hog the whole system and the non-deterministic scheduling of the "softirqd" will also degrade the overall performance. Cheers ! suresh sureshsingh.keisam@analog.com ----- Original Message ----- From: "Kevin Curtis" <kevin.curtis@farsite.co.uk> To: <linux-net@vger.kernel.org> Sent: Wednesday, November 13, 2002 7:44 PM Subject: possible delays in netif_rx > Hi, > I have been enhancing our sync card driver to use DMA to copy a > received frame from the cards memory into a Kernel buffer. We previously > used to use memcpy_fromio. The card has 8 receive buffers, which are used > in turn. I have been debugging a problem where sometimes my Kernel module > hasn't been able to keep up with the card. > > The line rate is 8Meg, and the packet size if 1500, so thats about > 1.5 ms per frame. So it would take 12 ms to run out of buffers. > > I used an analyser for debugging and I soon found that from requesting the > DMA to completing the processing of the received frame was on average 280 > us, but sometimes could take over 3 ms. Homing this down a bit more, I > found that the call to netif_rx could take a variable amount of time. This > was on average 5 us, but could sometimes be as much as 3 milliseconds. > > This I think explains my problem, and I can see that I need to separate the > DMA complete processing from processing the received frame, including > passing it up the stack. I guess I need to process the frame in a bottom > half. > > However, I'm puzzled by what is happening in netif_rx. It looks as though > it is just queuing it for later processing. Can anyone explain what is > happening in netif_rx to cause this wide variation in execution time. The > return from netif_rx is always NET_RX_SUCCESS. The Kernel I'm currently > using is 2.4.17 > > > Many Thanks > > Kevin > > -----Original Message----- > From: Carsten Langgaard [mailto:carstenl@mips.com] > Sent: 13 November 2002 13:35 > To: Ralf Baechle; linux-mips@linux-mips.org; tsbogend@alpha.franken.de; > linux-net@vger.kernel.org; kevink@mips.com > Subject: BUG in the PCNET32 ethernet driver > > > I finally found the problem that caused a lot of problem with an > ethernet throughput test, that we have been running. > It turned out the problem is related to a bug in the PCNET32 driver, > when you are running it on a system that doesn't support hardware > coherency. > > The problem is the way the AMD ethernet driver is using the PCI DMA > mapping routines. > When the driver releases a receive DMA buffer to the controller for > later DMA transfer it call the PCI DMA flushing routine as it should, > but it calls it with a length equal to 0. The driver is assuming that > the length field in the buffer structure is equal to the actual length > of the buffer, but this field is first updated when we are receiving the > packet (and call the skb_put function). > > I have attached a patch, that solve this problem. > Please note that the patch is against Ralf Baechle latest linux_2_4 > tree. > > /Carsten > > > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > - > : send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
