> if any other devices are on the same interrupt

Right!  Sharing interrupts is definitely to be avoided
if at all possible:

http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Dr
ivers_wiki_page

and scroll down to:

-- cut --

Shared Interrupts - Problems?

Different devices sharing a hardware interrupt is kind of a neat idea,
but unless you really need to do it - because you've run out of hardware
interrupt lines - it generally doesn't help you much. In fact, it can
cause you trouble. For example, if your driver doesn't work - e.g. no
received packets - check and see if it is sharing an interrupt with
another device, and if so, re-configure your board so it does not. Most
of the times, when shared interrupts are configured, there is no good
reason for it - i.e. you haven't really run out of interrupts - and this
can decrease your performance, because when the interrupt fires, ALL of
the devices sharing the interrupt need to run and check and see if it is
for them. If you check the source, you can see that some drivers do the
"right thing" which is to read registers in their interrupt handlers to
see if the interrupt is really for them, and ignore it if not. But many,
many drivers do not - they schedule their thread-level event handlers to
check their hardware, which is inefficient and reduces performance. If
you are using PCI bus, use the "pci -v" utility to check interrupt
allocation. You may be surprised as to what you see. Another point worth
making is that sharing interrupts can vastly increase interrupt latency,
depending upon exactly what each of the drivers do. Remember that after
an interrupt fires, it will NOT be re-enabled by the kernel until ALL
driver handlers tell the kernel that they have completed handling. So,
if one driver takes a long, long time servicing a shared interrupt which
is masked, if another device on the same interrupt causes an interrupt
during that time period, processing of that interrupt can be delayed for
an unknown duration of time. Bottom line is that interrupt sharing can
cause problems, and reduce performance, increase cpu consumption, and
seriously increase latency. Unless you really need to do it, don't. If
you must share interrupts, make sure your drivers are doing the "right
thing". Face it - shared interrupts are the new "trans fats" :-) 

-- cut --

P.S.  Took at peek at the intel doc, it mentions an
internal limit of 64k for rx descr ring size.  Looked
at the BSD (wm) driver, it's hardcoded to 256!

I suspect we should bump up the rx max descr ring from
2048 to 4096 in both devnp-e1000 and devnp-i82544.

--
aboyd

Thanks for the suggestion Hugh.  Interrupt is not shared and priority of the event thread is set to 100.  Just checked 
with pidin and none of io-pkt thread's priority are above 21, that's odd?  

Io-pkt-v4 -de1000 transmit=4096 receive=4096 priority=100 -pqnet no_slog=1
None of our process are above priority 20.  Machine is Quad Core running at 2.3G.


> -----Original Message-----
> From: Hugh Brown [mailto:community-noreply@qnx.com]
> Sent: Monday, September 14, 2009 10:54 AM
> To: drivers-networking
> Subject: RE: Squelch Test errors
> 
> You can also check to see if any other devices are on the same
> interrupt
> line and slay their drivers to see if the situation improves.
> 
> 
> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: Monday, September 14, 2009 10:49 AM
> To: drivers-networking
> Subject: RE: Squelch Test errors
> 
> 
> >> Increase the size of your "receive=X" command line
> >
> > it's to 4096
> 
> Hm.  Just checked the source and both devnp-e1000
> and devnp-i82544 limit rx to 2048.  I wonder if
> there is some underlying hardware limitation?
> 
> > 191 Packets Dropped on received
> > and 78 squelch Test errors
> > Out of 10Million packet.
> 
> that's around 1 in 90,000 rx packet dropped,
> which again isn't perfect, but isn't really
> that bad, either.
> 
> > 703 packet dropped and 283 sequel error
> > out of 11 million packet.
> 
> 1 in 11,000 - not bad, but not great either.
> 
> With a big enough rx descriptor ring, you
> ought to be able to straddle your scheduling
> latency of io-pkt and entirely get rid of the
> "dropped" errors, unlike you've got something
> that really hogs the cpu at a very high priority
> for a lengthy time.
> 
> The SQE (rx fifo) errors may be a bit trickier
> to eradicate - first, you have to figure out
> the exact cause.
> 
> --
> aboyd
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post37903
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post37904
>