Date: Fri, 14 Feb 1997 16:27:28 -0800 From: Julian Elischer <julian@whistle.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Software Interrupts Message-ID: <330502EF.1CFBAE39@whistle.com> References: <XFMail.970213232104.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon Shapiro wrote: > > 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. There is already support for this.. this is what the filesystem code does.. check out the files in kern/vfs_bio.c especially look at biodone() if you fill ou the b_iodone entry in the buf struct then it will call whatever routine you want on completion.. check the output() strategy() code for sd.c and the adapter to understand how your routine may return after having queueud the data. > > 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. Usually, what you do is: get the old command status.. load teh next command process the old status.. > > 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. look for schednetisr() software interrupts are run if there is anything scheduked for them when the SPL is set back to 0. > > 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. unless you duplicate teh splnet cade, you will end up running at the networking spl.. which may or may not be what you wanted.. > > 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?330502EF.1CFBAE39>