Tom Chen writes:
> Yes, my driver is for a giga bits high speed PCI network device. I
> have been considering whether to use a soft interrupt or a separate
> kernel thread to process received packets. If gldm_intr( ) handler is
> already quite "soft" like a kernel thread, then there is no need to
> use a separate handler(soft intr or thread) to process.
So it's almost like a kernel thread in the sense you can do
anything you would in a kernel thread, but there is still an
important distinction.
While running as an interrupt, you are pinning a thread that
was just happening to be running on the interrupted CPU. The
pinned thread will not be rescheduled as long as the
you interrupt routine is running. The idea is that interrupts
should be of short duration and need not incur the full
overhead of a context switch. So if the interrupt is about
to push a packet or 2 up the stack, it's still resonable to
do so. But if you're about to handle an endless data stream
forever pinning the poor thread that happen to run on the
CPU, then we might want to consider an alternative.
A hybrid approach in which you push up a few packets from
the interrupt (for low initial packet latency) but switch to
a full kernel thread if the individual interrupt time gets
too large might be interesting.
____________________________________________________________________________________
Performance, Availability & Architecture Engineering
Roch Bourbonnais Sun Microsystems, Icnc-Grenoble
Senior Performance Analyst 180, Avenue De L'Europe, 38330,
Montbonnot Saint Martin, France
http://blogs.sun.com/roch
_______________________________________________
networking-discuss mailing list
[email protected]
