Hello,
Thank you John and Jesse. You are right. As soon as I shifted the Intel NIC
to another PCI slot, the number of interrupts to the NIC dropped away
completely and the packet throughput shot up. I will cross check if those
interrupts coming earlier were TX complete interrupts meant for NVDIA. But yes,
the problem does look solved. I do not know how to setup a different interrupt
vector but I will look into it.
I took a computer architecture course a long time ago and for some reason I
had this in the back of the mind that the CPU knows who raised the interrupt
even for shared interrupts.
Ans yes, I will try to update the driver although it may not be possible
since I am doing some comparisons with earlier research which used this
particular version.
Thank you again very much .
Azeem Khan
Mumbai.
> From: [email protected]
> To: [email protected]; [email protected]
> Date: Fri, 17 Apr 2009 10:13:09 -0700
> Subject: RE: [E1000-devel] help understand origin of spurious interrupts
>
> You need to stop sharing the interrupt somehow since you'll never be able to
> tell which device is causing the interrupts you want to stop. Also, the
> e1000 driver you are usin gis very old. Us the latest one from our
> Sourceforge site, http://e1000.sf.net.
>
> You could also try disabling the NVIDIA NIC in the BIOS to see what that does.
>
>
> Cheers,
> John
> -----------------------------------------------------------
> "...that your people will judge you on what you can build, not what you
> destroy.", B. Obama, 2009
>
>
> -----Original Message-----
> From: Azeem Khan [mailto:[email protected]]
> Sent: Friday, April 17, 2009 9:45 AM
> To: [email protected]
> Subject: [E1000-devel] help understand origin of spurious interrupts
>
>
> Hello everyone,
>
> I see almost 80% spurious interrupts inside the e1000 irq handler
> (e1000_intr) when receiving frames. NAPI is enabled and functional. Please
> help me understand why. Here are more details.
>
> Configuration:
> --------------
> I have a PC with an onboard NVIDIA GbE NIC and a Intel 82540OEM NIC in a PCI
> slot. Coincidentally, both of them are sharing IRQ 11. I am using ver 6.3.9
> of the e1000 driver. The NVIDIA driver is not NAPI enabled afaik. Linux
> kernel version 2.6.16.13. Processor is AMD Opteron @ 2GHz. IP Forwarding is
> enabled.
>
>
> Execution:
> ------------
>
> For performance analysis, I send small packets (64 bytes) at rates of 200Kpps
> into the Intel NIC which is routed through the NVIDIA NIC to the other
> network. What I observe is that for 3 million packets, about 1.1 million
> interrupts are being handled by e1000_intr(). Deeper analysis (I added some
> code) shows that about 22% of these are the timer RXT0 interrupts. The
> remainder are not destined for the Intel NIC (since the icr variable set
> earlier in e1000_intr() contains the value 0x0). To confirm, I added a
> counter which shows that 78% of the times, e1000_intr() returns IRQ_NONE i.e.
> the interrupt register does not have any bits set at all.
>
> How can this be? I mean, where are all these interrupts coming from? And why
> is the e1000 driver being asked to handle the interrupt when no bits in the
> register are set? This is seriously affecting peak packet throughput of my
> router. So please help me out.
>
>
> Azeem Khan
> Mumbai
>
>
>
> _________________________________________________________________
> The new Windows Live Messenger. You don't want to miss this.
> http://www.microsoft.com/india/windows/windowslive/messenger.aspx
_________________________________________________________________
Windows Live Messenger. Multitasking at its finest.
http://www.microsoft.com/india/windows/windowslive/messenger.aspx
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
