Subject: InDataOrder (or not InDataOrder)

From: "Somesh Gupta" <[email-masked]>
Date: Tue, 16 Jan 2001 20:43:22 -0800

Looking at the Appendix C of the latest draft, and the InDataOrder
key, it seems that both sides can decide that they want data in order
(for a single command) - or each side can independently agree to
accept data in order.

I have the following questions:

1. Does any target return data for a read out of order? Althought the
potential benefit is there, in practice is it used?

2. For a write, does this restriction apply to the entire
write operation or only to individual r2t's (I assume the r2t) although
in practice there seems little reason for the r2t's to be requested
out of order?

Thanks,
Somesh

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 22 Jan 2001 13:55:53 -0600

Somesh,

> potential benefit is there, in practice is it used?

Historically, there HAVE been targets that return read data out of
order.  This history predates the widespread adoption of SCSI.  I
don't know any modern SCSI target that returns read data out of order.
I expect this capability is primarily there for people from big, old
companies, (with 3 letter names, one of which doesn't exist anymore)
who remember those cool products where data (cylinders) read
out-of-order substantially reduced random I/O latency, increasing TP
throughput.

I believe that's the rough story behind FCP's support of the feature,
and we may as well keep bowing to the shrine.  Certainly, the reasons
to support it haven't gone away, but implementors still find so many
other, easier avenues of improvement that it's unclear whether it ever
will be implemented again.  I've never seen the feature enabled.

It's cute that I started this draft, and then Julian said:

> Definitely - many high performance controllers, when they have cache
> misses, return data out of order for operations that involve many
> blocks.

That's irony for you.

Julian (or anybody else), can you please list some SCSI (of FC)
controller/targets being sold today that actually do return read data
out of order?

That aside, there's really no reason to toss the feature if it might
become useful in the future, particularly given that it has been
around for time immemorial.

Steph