The flow control part of "target-to-initiator" data transfer seems to
be missing here.
I suppose that the condition follows to "until" in the above sentence
would be "until the target has no more data for the initiator OR the
initiator does not have resources to receive more data from the target."
Is this what you intended or am I still missing something?
> If we are doing unidirectional printing, then there is no data
> for the initiator, and the task set is never aborted.
>
> If we are interacting with the device, and it behaves as expected,
> then there is no unexpected data for the initiator, so the task
> set is never aborted. (For interactive Postscript, scanning models,
> and request/reply paradigms like SNMP)
This sounds like expectation (or requirement) for client applications
to be master/slave.
It seems that "request/reply" is expected to be done indivisibly and
sequencially. Does the solution well cover the case "requests/replies"
are done in parallel (more than one request are outstanding) as well?
Akihiro Shimura
On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
> Akihiro Shimura writes:
> > Basically, I also support to consider option B, but it is still not
> > clear for me how the data transfer of each direction is done
> > independently within single login in SBP-2 only solution.
> >
> > If target request data transfer by "Data Available" flag in certain
> > status block, initiator will subsequently append "SND data-in" ORB in
> > the current task list. It will be possible for the target to check if
> > there is a "SND data-in" ORB in the task list BEFORE the initiator
> > appends the "SND data-in" ORB. After finding there is no "SND data-in"
> > ORB, the target may issue another unsolicited status which indicates
> > "Data Available". By this status, the initiator may append one more
> > (total two) "SND data-in" ORB in the task list. After that, the
> > target will need to abort the excessive ORB.
> > Is this a way the SBP-2 only solution works?
>
> It's not the way I intended it to work. Let me work through
> the model I've had in mind.
>
> It is a status signal that data is available for the initiator. It is
> not an event requesting a new task be placed on the task list.
>
> The status is updated at exactly two points in time: on the
> completion of a task; and on a spontaneous change from No Data
> Available to Data Available when there are to active tasks on the
> task list. It is up to the initiator to determine whether a new
> task needs to be enqueued on the task list or not. The task
> enqueuing algorithm for the initiator would basically be:
>
> for (;;)
> {
> while target has unexpected data available
> get target data one request at a time
>
> enqueue one request for an expected data transfer
> }
>
> When the target has data available, and at least one request
> exists on the active task list, the data available indication is
> given on the completion status of the first ORB. The initiator
> will enqueue a new ORB for receiving target data if, and only if,
> no request for target data has already been enqueued on the task
> list. This ORB would be associated with the "hanging read"
> already required for independent communication in each direction.
>
> The target would continue to process the ORB list until one of
> the following states is reached:
>
> S1) the ORB list will be empty (no active task set)
>
> S2) the ORB list processing stalls at a data transfer to the target,
> and the target has no data for the initiator.
> (no more target buffer space, and no reason to abort the task set)
>
> S3) the ORB list processing stalls at a data transfer to the initiator
> (initiator expects data from the target, but none is currently
> available)
>
> When data becomes available, the following transitions take place:
>
> From S1
> the target signals Data Available via unsolicited status;
> the initiator enqueues one ORB to receive the data;
> the target resumes processing the ORB;
> on completion of the request, the target indicates whether
> or not more data is available.
>
> From S2
> the target aborts all the requests on the task list and indicates
> that data is available for the initiator on each request;
> the initiator enqueues one ORB to receive the data;
> the target resumes processing the ORB;
> on completion of the request, the target indicates whether
> or not more data is available.
>
> When the target has no more data available, the initiator
> requeues the aborted requests.
>
> From S3
> the target continues processing the task set
>
> The only ineffeciency occurs when the target doesn't behave the way
> the initiator expects.
>
> If we are doing unidirectional printing, then there is no data
> for the initiator, and the task set is never aborted.
>
> If we are interacting with the device, and it behaves as expected,
> then there is no unexpected data for the initiator, so the task
> set is never aborted. (For interactive Postscript, scanning models,
> and request/reply paradigms like SNMP)
>
> If the target doesn't behave as expected and has lots of unsolicited
> data for the initiator, the target aborts the current task set and
> the initiator pauses sending data to the target until the target has
> no more data for the initiator.
>
> The worst-case scenario occurs if the target keeps generating bursts
> of unexpected data for the initiator and the task sets are perpetually
> aborted. The net effect of this is minimized simply by minimizing
> the length of the active task set! Having 2-4 data transfer requests
> queued (e.g. double-buffering) may be sufficient (for most applications)
> to keep the task list running and the target busy.
>
>
> > I think that aborting tasks implies subsequent task retries, and may
> > not be efficient.
>
> Yes, aborting tasks implies subsequent task retries.
> The overhead is in the target (pre) fetching the ORBs
> in order to abort them, and in requeuing the task set
> when the data available indication disappears.
>
> But don't forget that the maximum data transfer size is known,
> so the target doesn't need to fetch any real data until it knows
> that it can complete the request!
>
> > It seems natural to make two independent logins for each direction,
> > one for down-link and another for up-link by using the idea to map
> > them into logical units. Furthermore, by extending this to allow to
> > allocate up-link in reverse fashion (i.e., the target of down-link
> > makes a login to the initiator of down-link), the link between two
> > devices will become symmetric if both ends have both initiator and
> > target functionality.
> >
> > Any suggestions?
>
> Haven't we been down this road before? (Yes, and rejected it.)
>
>
> > --
> > Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
> > Office Imaging Products Development Center 3
> > CANON INC.
> >
>
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs@sdd.hp.com
> ----------------------------------------------------------------
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.