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
