Re: Regarding ordered-tag support.

[James Smart <James.Smart@Emulex.Com>]

>> For the first: busy/queue_full processing, the issue is that when we
>> send out a command, we could get a BUSY or QUEUE_FULL return which comes
>> back to us via IRQ context.  Unfortunately, we could have multiple
>> commands that do this and a command will be accepted as soon as the busy
>> condition alleviates, so we could see say two commands go down in order,
>> the first one will get BUSY, the second is accepted and only then do we
>> get the IRQ that says BUSY to the first ... now we have out of order
>> execution.
> 
> Oh... I see.  How many drivers do that?  I can't think of good reasons
> to report BUSY via IRQ for simpler transports (SATA/SPI).  Maybe enable
> ordered-tag selectively?

This isn't a driver thing - this is a SCSI device thing.  The disk array
is temporarily out of resources so it BUSY's, or QUEUE_FULL's. But the
next i/o may not encounter it.


> 
>> For the second:  Depending on the mode page (the QErr bit of the
>> queueing page), most devices fail only a single command.  We can set the
>> QErr bit to return every command after the failing one (thus ensuring
>> execution order), but the error handler would have to take them all back
>> and resort them for submission.
> 
> Actually blk layer will do the sorting part (this is what req->ordcolor
> is for).  Block drivers are only required to not successfully complete
> later requests while retrying earlier ones, so setting QErr and retrying
> all on-the-fly requests should do it (no EH code change).

You're making the assumption that you can set QErr... It's under device control.

-- james s