Akihiro Shimura wrote:
>I'm not sure but I suppose the SHPT model will be still in the "spirit"
>of SBP-2 because its features seem to be maintained.
Let me clear "sprit of SBP-2".
1) Are you going to make something new protocol which has SBP-2 flavor?
2) Or, are you going to expand SBP-2 specification?
3) Or, are you going to define standard implementation for SBP-2 queuing model?
Akihiro Shimura wrote:
> The SHPT model requires two things as briefly described in the
> document.
> One is that the initiator shall keep up the "CONTENTS" of buffer until
> the request is completed, and shall keep up the relationship between
> "sequence identifier" and associated buffer (contents).
> Another is that the target shall maintain the "sequence identifier"
> and "offset" for the incomplete request, and shall be responsible in
> avoiding the duplicated execution.
I feel 1394 PWG does *not* need to make standard for implementation of
SBP-2 devices. May be I am misunderstanding your points. But we may
use ORB fetch queuing utilizing SBP-2. It would be beyond the specification.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp
-----Original Message-----
From: Akihiro Shimura [SMTP:shimura@pure.cpdc.canon.co.jp]
Sent: Tuesday, March 24, 1998 10:02 PM
To: Greg Shue
Cc: p1394@pwg.org
Subject: Re: P1394> Alternative Bi-Di proposal utilizing unordered model(Was Re: unordered execution)
See comment below....
On Mon, 23 Mar 1998 09:55:37 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
> Akihiro Shimura wrote:
(snip)
> > 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."
Thank you for the clarification.
In this mean, the SHPT model will not be an "Unordered Model" under
the "Basic task management model" but be sort of an "Unordered Model"
under the "Queuing Model".
> 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.
I'm not sure but I suppose the SHPT model will be still in the "spirit"
of SBP-2 because its features seem to be maintained.
> 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.
The SHPT model will set the 'q' bit as it was in the original HPT.
> > 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.
The SHPT model requires two things as briefly described in the
document.
One is that the initiator shall keep up the "CONTENTS" of buffer until
the request is completed, and shall keep up the relationship between
"sequence identifier" and associated buffer (contents).
Another is that the target shall maintain the "sequence identifier"
and "offset" for the incomplete request, and shall be responsible in
avoiding the duplicated execution.
Since the synchronization between the initiator and the target may be
lost in the way that initiator is behind (the target is ahead), the
target examines the "sequence identifier" provided just after the
re-synchronization is taken by the initiator(possibly behind) and the
target completes without duplicated execution.
Because the "CONTENTS" of buffer and related "sequence identifier"
are kept up by the initiator and the target avoids the duplicated
execution by using maintained "sequence identifier" and "offset", the
data stream will not be corrupted.
Am I still missing something?
Akihiro Shimura
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.