Subject: P1394> unordered execution

From: Nagasaka Fumio <[email-masked]>
Date: Mon, 9 Mar 1998 10:14:15 +0900

Does SBP-2 printing protocol need to have out of order execution for ORB
list?

Let me assume one case shown below.
When an initiator puts an input ORB in linked list of ORBs.
[out::ORB] - [out::ORB] - [out::ORB] - [in::ORB] - [out::ORB] …
If our SBP-2 target consume them by in order execution. The target
will stop at fourth ORB and will examine whether it has reverse data
or not. It is normal and reasonable.
We might have an analogy of C language source code outlines
below.
{
    putchar(..);    // step 1
    putchar(..);    // step 2
    putchar(..);    // step 3
    getchar( );     // step 4  * INPUT*
    putchar(..);    // step 5
    …..
}
This process will stop at step 4 and will wait input from TTY.

OK?, next, let’s go back to SBP-2 target problem. Even if
the target does not have any thing to replay at step 4. The
transport layer shall *not* return “no data flag” or “something
to say there is nothing to reply”. The target’s application may reply
“no data” , “this is data” or any thing. This action shall be taken
by application’s responsibility.

By the way, for second case is shown below.
When the initiator has some requests which shall be delivered to
each logical channels like these,…(#k means logical channel ‘k’).
[out::#1::ORB] - [out::#1::ORB] - [out::#1::ORB] - [in::#2::ORB] -
[out::#1::ORB] …
Then if the transport layer in the target waits reverse data is passed
through from the application, fifth ORB which shall be delivered to
channel #1 will not be delivered while the transport is pending on
fourth ORB.

If our SBP-2 protocol may allow out of order execution. The
target is able to consume sixth ORB earlier than fifth. Then
the protocol provides concurrent executive opportunity for
each logical channels.

*	Shall the transport provide out of order execution ?

I want to say no. The initiator shall place [input::ORB] if
it expects reverse data will be sent from the target. I would
like to say, the currents SBP-2 protocol has enough facility.

I am curious why unordered execution is required for ‘HPT’.
May be there are something I am missing.

Thank you, best regard.
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

---

From: Akihiro Shimura <[email-masked]>
Date: Mon, 9 Mar 1998 18:41:46 +0900 (JST)

On Mon, 9 Mar 1998 10:14:15 +0900

> May be there are something I am missing.

The HPT(High Performance Transport) essentially requires unordered
execution model in order to multiplex two independent sequences of
operation requests (read request sequence and write request sequence)
into single linked list of ORB's. In other words, the HPT provides
full duplex communication path (independent flow for each direction)
by using unordered execution model with one fetch agent (one login).

The unordered model under the basic task management model allows the
target to unrestrictedly reorder the active tasks, but does not allow
to append a new task to the task list until all tasks in the current
task set completed.
Though this model will be suitable for multi-cluster or multi-track
access to the disk drive since the disk drive may optimize track
seeking, etc., it will not meet the requirement from multiplexing two
ordered request sequences because it prohibits to append a new task
when previous tasks are in progress.

The SBP-2 describes following sentences as a note.

	"NOTE - In multitasking operating system environments,
	independent execution threads may generate tasks that have
	ordering constraints within each thread but not with respect
	to other threads. If this is the case, an initiator may
	manage the constraints of each thread yet still keep the
	target substantially busy. This avoids the undesirable
	latencies that occur if the target is allowed to become idle
	before new ORB's are signaled."

The HPT uses this model. Essentially, the independent execution
threads are read thread and write thread in the HPT. Each thread
generates tasks that have ordering constraints within each thread but
not with respect to another thread. So, the HPT provides in-order
delivery in each direction while keeping each direction independent.

A certain operating system uses two I/O request queues for each
direction to serve as full duplex. The requests in these I/O request
queues are multiplexed into single linked list of ORB by message(ORB
or status_block, but NOT data itself) flow control in the HPT. The
ordering constraints are maintained in these two I/O request queues
as usual. The status_block returned by the target indicates to which
of the head of these I/O request queues the completed I/O request
belongs. Since the message flow control does not require additional
packet exchange with another peer in the HPT, the flow control does
not have an overhead from the peer's latency.
(The HPT also uses the same mechanism to multiplex multiple channels.)

There will be three places to put multiplexing information for
independent data paths within on using SBP-2.

	a) Data buffer
	b) ORB
	c) 1394 bus address

The protocol uses "a)" will be 1284.4 over SBP-2. 
       (Single fetch agent, single execution agent, data flow control)
The protocol uses "b)" will be HPT.
       (Single fetch agent, independent execution agents, message flow control)
The protocol uses "c)" will be dual login or cross login.
       (Independent fetch agents, independent execution agents)

Since plain SBP-2 provides master controlled half duplex path, the
profile (rev. 0.1d) may be between half duplex "plain SBP-2" and full
duplex "SBP-2 dual or cross login" because it may require some sort
of retries(re-ordering in the initiator) in case of asynchronous back
channel data though it uses ordered model. (Three quarters duplex?)
--
 Akihiro Shimura ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.

---

From: Akihiro Shimura <[email-masked]>
Date: Mon, 9 Mar 1998 20:32:36 +0900 (JST)

Oops, I've corrected some errors. Sorry for the duplicated posting.

Forwarded by Akihiro Shimura <[email-masked]>
---------------- Original message follows ----------------
 From: Akihiro Shimura <[email-masked]>
 To: Nagasaka Fumio <[email-masked]>
 Cc: [email-masked]
 Date: Mon, 9 Mar 1998 18:41:46 +0900 (JST)
 Subject: Re: P1394> unordered execution
--

On Mon, 9 Mar 1998 10:14:15 +0900
Nagasaka Fumio <[email-masked]> wrote:

> I am curious why unordered execution is required for 'HPT'.

The unordered model under the basic task management model allows the
target to unrestrictedly reorder the active tasks, and the responsibility
for the assurance of data integrity is left with the initiator.

	a) Data buffer
	b) ORB
	c) 1394 bus address