"Justin T. Gibbs" <gibbs@freefall.freebsd.org> writes:

> 
> I agree with all of these points, and provide what I think is a
> solution.  The main problem here is that the buffer is pulled off
> the queue only based on a per device openings number.  For the
> aic7xxx driver, the number of openings is arbitrary and based on
> the number of tags we feel like allowing a device to consume.  This
> just isn't enough information to ensure that all the resources we
> need are availible.  Instead, the SCSI system should track the
> number of controller openings and device openings and only proceed
> if both are availible.  The SCSI system could also monitor the
> number of openings allowed on a per device level and modulate them
> based on rtprio or for fairness in sharing controller openings
> among competing devices.  With this strategy, you should never
> have to sleep and you don't need a software queue in each driver
> (as Jason proposed).

I wouldn't call this a solution so much as a restating of the problem.
But two comments:

1) At some point, you still have to allocate data structures in
response to something happening.  Who's going to do it?  Until you get
to the strategy routine, you don't even know that you need a buffer,
and you don't know how many more you'll need for the I/O in progress.
(I have two somewhat high-impact solutions for this.)

2) The higher-level SCSI code has no business knowing about resource
limits on the controller, except through an explicit feedback
mechanism.  The device needs resources, and the controller supplies
resources, but neither should know the internals of the other.