Re: Regarding ordered-tag support.

[Tejun <htejun@gmail.com>]

Hello,

James Smart wrote:
>>>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.

I intentionally wrote 'driver' because if a SCSI device determines that 
it's busy, it would report via CHECK CONDITION.  Depending on QErr, the 
whole task set will be terminated, and such case falls into EH 
requeueing case (would require changes in scsi_softirq though).

So, I thought this case was driver/controller thing where they report 
busy condition after issue for a command while accepting later commands.

>>>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.
> 

Was it ro field?  Didn't know that.  I will check it tomorrow.  If a 
device doesn't abort whole taskset, we just can't use ordered-tag for 
barriers.

Thanks for your comment.

-- 
tejun