Re: Regarding ordered-tag support.

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

James Bottomley wrote:
> On Wed, 2006-02-08 at 15:40 +0900, Tejun Heo wrote:
> ...<snip>...
> Unfortunately, though, this is only half the problem.
> 
> The other half is busy/queue_full processing and error recovery
> 
> 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.

James is also not disclosing other areas that may fail...

- How does multipathing affect this (maybe not dm, but others that exist).
- The implicit expectation of the LLDD and the hardware is that commands are
   placed on the wire in the same order given to queuecommand. However, no
   where is this mandated. In general, they do keep order. However, I've seen
   driver implementations that don't dispatch directly to hardware in
   queuecommand, allowing the intermediate steps to fail and perhaps disrupt
   ordering.
- Some adapters may actually be multipath/raid cards, thus affecting command
   delivery.
- SCSI Transports are not 100% reliable, affecting ordering. For FC,
   a single Frame corruption could cause a command frame to be dropped thus
   the next command received and executed out of order. You would not notice
   an issue until the scsi i/o timeout fires and aborts the i/o. The subsequent
   i/o may have already completed by that time. Some transports due have
   command sequence numbering to avoid this, but it's an optional feature.

-- james s