Subject: P1394> Re: SBP-2 Bidirectional ORB

From: Fumio Nagasaka <[email-masked]>
Date: Sun, 7 Dec 1997 17:34:39 +0900

Through the 1394 PWG discussion, I *was* thinking "in order execution" for
linked list of ORBs is required for printing application. Now I think the target
may skip ORB execution in some case, even in a printing application, utilizing
multiple logical channel.

[email-masked]  writes:
* Well, how does the initiator *know* that the target has no data? Use a
* timeout? No, I think that this would be an ill-advised strategy---very
* inefficient, too.

I don't think the initiator knows the target has no data. And I do not think
the application layer in the target device know the transport layer received
IN-ORB request from the initiator. Thus if there is an input request between
other ORBs and the target does not have any data to reply, SBP-2 transport
layer would not decide whether the application is going to send data just
10 msec later or after 10 minutes hard working.

We at 1394 PWG found the higher layer in the protocol stack in the target
shall service multiple logical channels. Then, the target agent may fetch
ORBs and distribute them into each logical channel. Please see an attached
figure:

Each logical channel shall consume ORBs in the queue. Even if a logical
channel received an ORB which is not executable, other logical channels
would be available.

Actually when paper out, the printer does not print and it does not consume
PCL commands. Then any ORB which is pointing print data will be stalled.
However the initiator may send status request through an available logical
channel. The initiator can get reason why the ORB is stalled. And if the
trouble is unrecoverable, then it may send *TASK_ABORT* to the target.

The PWG printer profile for SBP-2 is defining logical channel field in command
block of the "Normal command block ORB" data structure.
--------------------------------------------
-------------------------------
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:	PJohansson [SMTP:[email-masked]]
Sent:	Thursday, December 04, 1997 11:17 AM
To:	[email-masked]; [email-masked]
Subject:	Re: P1394> Re: SBP-2 Bidirectional ORB

In a message dated 97-11-21 12:18:06 EST, [email-masked] writes:

<<If the target device does not have any data to reply, when the initiator is
keeping Out-ORB, In-ORB and Out-ORB, the target fetch agent will be stalled at
second ORB and third ORB will not be consumed.>>

This is a true statement ONLY if the target reports in-order execution in its
configuration ROM. To keep things in perspective, all of the discussions of
printers (of which I am aware) have assumed in-order execution.

<<In this case, "AGENT_STATE" shall be ACTIVE at this moment. Thus if the
initiator try to ping DOORBELL, this write-transaction for DOORBELL is
redundant. To overcome this state, the initiator need to write a value to
AGENT_RESET register to force "AGENT_STATE" to turn RESET state. Is this a
normal job for this purpose?>>

Well, how does the initiator *know* that the target has no data? Use a
timeout? No, I think that this would be an ill-advised strategy---very
inefficient, too.

Better for the target to complete the second ORB in the example above and
indicate zero data transfer. It's then free to go on the the third ORB.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

[email-masked]

---

From: "Turner, Randy" <[email-masked]>
Date: Sun, 7 Dec 1997 05:02:06 -0800

When you implement 1284.4 on top of SBP-2, the 1284.4
layer will multiplex multiple independent logical channels
over a single SBP-2 login session. For each logical
channel that is managed over a particular SBP-2 login session,
"outbound" ORBs must be processed in FIFO order, and
"inbound" ORBs must be processed in FIFO order. These
requirements are necessary since 1284.4 contains no
sequence space or any other capability that would allow
it to reorder packets.

One problem with this requirement is that it was assumed
that the particular SBP-2 implementation to be used
would not have any information about 1284.4 - specific
requirements for FIFO processing of outbound/inbound
ORBs. Unless the SBP-2 layer software interface allows
this type of option to be specified for a particular login.

This may not be a problem for a target if the target-side
1284.4 implementation provides its own SBP-2 fetch
agent. I am not familiar with how SBP-2 implementations
are being designed; whether they implement "internal"
fetch agents, or do they support "external" fetch agents
for clients with special ORB processing requirements?

Randy

> From:	Fumio Nagasaka [SMTP:[email-masked]]
> Sent:	Sunday, December 07, 1997 12:35 AM
> To:	[email-masked]'; [email-masked]'
> Cc:	'PJohansson'
> Subject:	P1394> Re: SBP-2 Bidirectional ORB
> 
>  << File: InOrbStalled.PDF >>

---

From: Fumio Nagasaka <[email-masked]>
Date: Mon, 8 Dec 1997 23:59:46 +0900

Randy Turner writes:
>ORBs.

According to SBP-2 specification "7.4.8. Logical_Unit_Characteristics entry",
we may specify characteristics of the target implementation. If our target
agent is required to execute ORBs in order, then the order bit shall be one.

Randy Turner writes:
>agent.

I think a normal target agent can do it.
The target agent may not fetch ORBs in order. The target may fetch
some special ORBs before it fetches other ORBs. Thus if client layer
for SBP-2 stack informs SBP-2 that a channel is stalled, then the
fetch agent may skip any ORBs for this channel. Alan described a
command bock of each normal command block ORB shall have PSID
and SSID. So the target agent will be able to find a channel ID from
each ORB and may skip ORBs delivered to the channel which has
trouble.

After few moments, when the stalled queue turns to be available,
the higher layer protocol stack (1284.4 layer) shall inform SBP-2 that
the channel is recovered. Then the target agent may fetch and deiver
ORBs for this channel.

Randy, am I understanding your point? 

-----Original Message-----
From:	Turner, Randy [SMTP:[email-masked]]
Sent:	Sunday, December 07, 1997 10:02 PM
To:	'Fumio Nagasaka'; [email-masked]'; [email-masked]'
Cc:	'PJohansson'
Subject:	RE: P1394> Re: SBP-2 Bidirectional ORB

Randy