Subject: RE: P1394> unordered execution

From: "Turner, Randy" <[email-masked]>
Date: Sun, 8 Mar 1998 21:09:48 -0800

See my comments below...

Randy

	-----Original Message-----
	From:	Nagasaka Fumio [SMTP:[email-masked]]
	Sent:	Sunday, March 08, 1998 5:14 PM
	To:	[email-masked]
	Cc:	PWG-C mailing
	Subject:	P1394> unordered execution

	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.

	Yes, the requesting application code would not issue a READ
operation if no application response was expected.  The application
would return an application level response *no-data*, or the application
would return some other appropriate response.

	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.

	We should never have a single ORB list processing multiple
logical channels. Each ORB list handles a single logical channel, at
least according to the current profile document decisions we have made.

	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]