Date: 21 Dec 2000 20:45:02 -0500 From: Nat Lanza <magus@cs.cmu.edu> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Asynchronous commands for the passthrough driver Message-ID: <uoc8zp9kz4x.fsf@hurlame.pdl.cs.cmu.edu> In-Reply-To: "Justin T. Gibbs"'s message of "Thu, 21 Dec 2000 08:01:28 -0700" References: <200012211501.eBLF1SF42268@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" <gibbs@scsiguy.com> writes: > I chose to implement an interface capable of scheduling and retreiving > whole lists of I/O so a smart application could avoid several uesr/kernel > boundary trips for certain types of applications. My gut reaction is that the sort of SCSI commands you're generally going to want to queue up from a user application are going to be so slow anyway that the cost of going into the kernel doesn't matter much -- while being able to issue batches of requests is nice, it may be overkill. For example, in the application I care about (an iSCSI server), I'm going to want to have a queue of active requests, but I'm almost _never_ going to have multiple requests to issue at once. I'll be issuing requests as they come in from the network, or as space for them becomes available. In general, I can't see too many times other than "we've started our bulk data transfer and want to fill the queue up right now" that applications I care about will have enough CCBs to enqueue at once that saving the kernel/user trips will matter much. What sort of applications did you have in mind for this? > >Alternately, notification could be done through kqueue or maybe a > >poll() on the /dev/pass<n> device. > > I suppose an application could have the need to poll on thousands of > pass fds, but not in the near term. We can always add a kqueue interface > for agregating pass events at a later time giving the user the choice of > which one to use. I agree about poll(); applications aren't going to have many pass fds to deal with, and fundamentally the idea of polling for something other than read() and write() calls seems wrong to me. > It would also be cool if you could register an arbatrary > signal to fire when commands have completed as well as register a different > signal for exceptional events (bus resets, loop up/down, etc.). The latter > would finally allow you to do everything that you can from within the kernel > from a userland app. This would be nice, yes. --nat -- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?uoc8zp9kz4x.fsf>