> > Agreed. I think we can eliminate out-of-order processing model.
>
> I don't think so.
>
> Though the CBT may prevent deferring(re-ordering or retrying) the ORB
> for initiator-to-target transfer in the initiator, there still exists
> an inefficiency on target-to-initiator transfer.
> In order to prevent ORB re-ordering in the initiator, it is necessary
> to guarantee the completion of each request. In case of target-to-
> initiator transfer, the CBT may only guarantee the receiving space on
> the initiator and does not necessarily guarantee the completion on
> the target because the target may not be ready to send a data.
A CBT-style mechanism covers data flow in both directions.
> To prevent this, it will be necessary for the initiator to defer
> appending target-to-initiator request ORB until ready-to-send is
> indicated by the target. Because appending pending read request to
> the task set requires indication from the target and the initiator
> need appending process based on the indication after the indication
> arrived, this procedure will not so efficient as shown by the spirit
> of SBP-2.
The "ready-to-send indication" from the target is implicit with
each credit.
> In this SHPT model, re-ordering the ORB between write and read
> request in the initiator is not required at all because the target
> does re-order between them.
> In the "ordered model", the ORB re-ordering in the initiator will
> occur whenever the requested order in the task set is not appropriate
> for the "target" to execute.
> Because the ORB re-ordering in the initiator requires aborting tasks
> by the target, re-appending the tasks to the task list by the
> initiator and re-fetching the tasks by the target potentially in
> non-linear order of retries, it will be expensive for the initiator,
> the target and the bus.
>
> Also, in this SHPT model, the initiator does not need to synchronize
> with the indication from the target to append the pending read request
> to the task set because the pending state is achieved in the execution
> agent on the target.
> In the "ordered model", if the initiator limits the number of
> requests in the task set very small (e.g., one) to avoid potential ORB
> re-ordering in the initiator, the target will enter suspend state
> frequently before requests are appended to the task list. In this case,
> the bandwidth benefit of the SBP-2 will be reduced by the latencies on
> each side.
I think you're missing one big clause about the Unordered Execution
Model. SBP-2 spec rev 3a, Section 4.6 states:
"The unordered model is usually appropriate for direct-access
devices for which no poisitional or other context information
is inherited from one command to the next."
"Unrestricted reordering leaves the responsibility for the
assurance of data integrity with the initiator. If the integrity
of data on the device medium could be compromised by unrestricted
reordering involving a set of active tasks, {T0, T1, T2, ... Tn}
and a new task T', the initiator shall wait until {T0, T1, T2, ... Tn}
have completed before appending T' to an active request list."
We have talked quite a bit in various threads on this reflector
about the "spirit" of SBP-2. In continuing with this emphasis,
the spirit of the Unordered Execution model is _completely_
unordered. Since the nature of our buffer transfers are ordered
within each direction, the previous clauses really require no
more than one message be queued for each direction at a time!
Anything else is really not consistent with the Unordered
Execution model.
The only possible supported way around this is to set the 'q' bit
in the Logical_Unit_Characteristics entry to be one and define a
command-set dependent queuing model. But I'm still not sure that
the interpretation of the 'o' bit in the same entry is affected.
> In addition, this SHPT model does not require to limit maximum data
> payload size, and does not need to prepare the maximum data payload
> size of (intermediate) receive buffer to guarantee the delivery.
In order to support transient link interruptions, either
additional restrictions are placed on ORBs being queued (that
they MUST be explicitly completed or aborted to be removed from
the task set), or maximum sizes must be set. If neither of these
mechanisms are defined, then it is possible for the data stream
to be corrupted because of a Bus Reset which resulted in a
partially processed ORB being requeued, or a new ORB being
queued, but interpreted as a partially fetched one.
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------