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 ----------------------------------------------------------------