Date: Thu, 13 Feb 1997 22:44:46 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Software Interrupts Message-ID: <XFMail.970213232104.Shimon@i-Connect.Net>
next in thread | raw e-mail | index | archive | help
I have dug into the software interrupts a bit and would like to confirm the best approach. Problem Description: I would like to trigger an interrupt, from within a device driver. The reason for doing so (may not be so good :-): I would like to de-couple queueing SCSI commands from the calling layer on one side and results analysis and error handling from the interrupt handler on the other side. Let me be more specific: when the SCSI code calls my driver's xxx_scsi_cmd entry point, I take the command, tweak it to the hardware vendor's content, put the request in a queue. At this point i would like to evoke an interrupt and return QUEUED_SUCCESSFULLY. The interrupt routine then will go to the queue and negotiate with the device all these wonderful inb, outb and such. The calling process is not bound by hardware delays. When a hardware interrupt, from the HBA, occurs, I want to be able to, in the interrupt service routine to just capture the hardware state (it takes only two inb's (can be reduced to one) one indirect dereferencing and a 24 bytes bcopy) into the request's CCB, move the request to the ``complete'' queue, schedule a software interrupt and schedule another software interrupt. This one will process however many requests there are in the ``completed'' queue. In this fasion, the interrupt routine will remain very short, consume very little time. The device we are interfacing to can give us SCSI command completion in less than 1ms. Much less in fact. Now, if you nice people know of a better way (than software interrupts) to do this, i will be happy to hear about it. Just as an intelectual excercise, please help me understand the software interrupts business. I have noticed that the Inet code that uses them, boils down to calling setbits (an inline defined in i386/include/cpufunc.h). Setbits takes the address of an unsigned and a u_int called bits. Different purposes in the kernel call setbits with different arguments. The argument is always the address of either ipending or of idelayed. These appear to be global bitmaps describing which interrupts are pending or delayed. What I cannot find is how to register a software interrupt. They appear, as if by magic. So, after all this, i am asking for a way to schedule two software interrupts. I really do not care what arguments will be passed to these functions, what value they return, or what. Just so they get invoked at some known priority, without fighting for CPU with the splbio guys. At the context of a true SMP machine, this scheme makes even more sense. But it may improve our responsiveness quite a bit, at some cost of increased overhead. the old game of latency vs. throughput. Thanx a million. Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970213232104.Shimon>