Subject: RE: P1394> 1284.4 over SBP-2

From: Nagasaka Fumio <[email-masked]>
Date: Fri, 13 Feb 1998 20:35:11 +0900

Hi,

Alan wrote:
<<
     I think Shimura san has some good points at the end of his message 
     that goes to the heart of what is still not clear with the option B

     proposal. I think we need to work up some example scenarios and 
     explore exactly how this will work. Greg Shue got any ideas here.
Alan, I think Shimura san has pointed out one important thing here,…

Akihiro Shimura wrote:
<<
		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?

I would like to introduce these rules shown below,
1)	The initiator clear Unsolicited_Status_Enable register to forbid
the target
	to issue unsolicited status which says "Data Available", while
the initiator
	is appending new ORBs in the list.
2)	The target shall observe Unsolicited_Status_Enable register,
whether or not it is
	set to one, before it scans linked list of ORBs.
3)	When the target found Unsolicited_Status_Enable register is set
to one,
and there is no in-ORB in the list, then the target may send unsolicited
status.

Then the initiator will not generate too many in-ORBs in the list.

Akihiro Shimura wrote:
<<
		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.
It is interesting. I had same idea to use two logins in last summer. But
my reason was different.
If we use one up-link and one down-ink, can we use multiple logical
channels in each direction? Then how can we prevent *one simple
uni-directional data path* to be stalled?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

		-----Original Message-----
		From:	Akihiro Shimura
[SMTP:[email-masked]]
		Sent:	Friday, February 13, 1998 12:05 AM
		To:	Greg Shue
		Cc:	[email-masked]; [email-masked]; Larry Stein
		Subject:	Re: P1394> 1284.4 over SBP-2

		On Tue, 10 Feb 1998 19:21:19 -0800 (PST)
		Greg Shue <[email-masked]> wrote:

		> > I await your responses.
		> OK, here we go...

		OK, I'll follow...

		> Larry Stein wrote:
		> 
		> > At this point in time we have apparently narrowed
our potential solutions
		> > to the following:
		> > 
		> > A- 1284.4 with SBP-2
		> > B-  New SBP-2 command set with SBP-2

		(snip)

		> As I understood it, the ability for 'a peripheral to
operate over
		> various interfaces without requiring major
architectural changes
		> to the product' is provided by meeting the specified
transport
		> service requirements.  As long as the transport
requirements are
		> met, no architectural changes are required of the
product.  Thus,
		> the transport layers are all modular with respect to
the product.

		I agree. This was original intent of the HPT which
Ueda-san and I
		introduced from last June meeting.

		(snip)

		> Given all of this, I am compelled to support option B.

		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?

		I think that aborting tasks implies subsequent task
retries, and may
		not be efficient.
		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?

		--
		 Akihiro Shimura ([email-masked])
		 Office Imaging Products Development Center 3
		 CANON INC.

---

From: Akihiro Shimura <[email-masked]>
Date: Sat, 14 Feb 1998 11:44:00 +0900 (JST)

On Fri, 13 Feb 1998 20:35:11 +0900
Nagasaka Fumio <[email-masked]> wrote:
(snip)
> Akihiro Shimura wrote:
> <<
> 	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

As far as I understand, the "another unsolicited status" will not
happen in this scenario by the definition given by Greg because the
target is already in "Data Available" state. (Greg, thank you for the
clarification.)

(snip)
> 	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.
> >>

I'm not sure if I understand your question, but the functionality
equivalent to multiple logical channel is already done in the SBP-2
only solution (option B) via unit architecture. If the target does NOT
behave as expected by the initiator, like asynchronous notification,
"aborting task"(which implies subsequent retry) will be necessary to
keep each direction independent.  To avoid the use of "aborting task"
while keeping each direction independent, I thought it may be natural
to allocate two independent links(logical units) for down-link and
up-link instead of using "aborting task".

On Thu, 12 Feb 1998 10:24:21 -0800 (PST)
Greg Shue <[email-masked]> wrote:
> Haven't we been down this road before?  (Yes, and rejected it.)

I don't remember if this(one initiator makes two logins for each
transfer direction without using 1284.4) is addressed already or not.
Is this addressed in last August (Redmond) meeting?
--
 Akihiro Shimura ([email-masked])
 Office Imaging Products Development Center 3
 CANON INC.