On Thu, Dec 28, 2000 at 12:45:48AM -0800, Matthew Jacob wrote:
> This is starting to look good. I have to do some more review of it, but it's
> definitely the right direction. I also would like to see the midlayer be able
> to issue REQUEST SENSE rather than forcing all HBAs to implement some private
> form of auto-requestsense. 

Ok, I'll look at this. Shouldn't be too hard to implement.

> 
> I'd also like to start thinking about target mode.

I don't have much idea on this yet; I'm waiting for your comments :)

> 
> I'm a little dubious about handling QFULL out of band- by the time you
> activate a thread the QFULL condition is likely to be done with. This is also

Possible, but doing the requeue in interrupt context is much harder.
Maybe we can move the backoff algorithm in interrupt context, but leave the
requeue to the thread - and also leave the thread restart the queue once
we think the QFULL condition is cleared.

> a good time to examine the queue full backoff algorithms and maybe pay closer

Yes. Now that it's centralised it's much easier :)

> attention to the RFC that Sean Doran pointed me at (rfc2001)-  although I was
> talking to Bob Snively about this a couple of weeks ago and he and I are a
> little dubious that pure congestion control is what's needed given the nature
> of SCSI devices (he's of the opinion that as soon as a QFULL condition is
> done, jam it to the max- hence my slight unease at anything in QFULL handling
> that has race conditions or any amount of complexity other than requeing
> logic).

I'm not sure this is rigth. It seems that some SCSI devices have a hard limit
on the number of tag they can handle (for my quantun fireball it seems to be
around 20), bumping it to the max (256) again would leave to another
QFULL pretty soon, with a lot of xfer to requeue. We need an algorithm that
can detect and stay around this limit.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--