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:
>This may not be a problem for a target if the target-side
>1284.4 implementation provides its own SBP-2 fetch
>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?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp
-----Original Message-----
From: Turner, Randy [SMTP:rturner@sharplabs.com]
Sent: Sunday, December 07, 1997 10:02 PM
To: 'Fumio Nagasaka'; '1394-architecture@1394ta.org'; 'p1394@pwg.org'
Cc: 'PJohansson'
Subject: RE: P1394> Re: SBP-2 Bidirectional ORB
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
> -----Original Message-----
> From: Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
> Sent: Sunday, December 07, 1997 12:35 AM
> To: '1394-architecture@1394ta.org'; 'p1394@pwg.org'
> Cc: 'PJohansson'
> Subject: P1394> Re: SBP-2 Bidirectional ORB
>
> 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.
>
> PJohansson@aol.com 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 nagasaka.fumio@exc.epson.co.jp
>
> -----Original Message-----
> From: PJohansson [SMTP:PJohansson@aol.com]
> Sent: Thursday, December 04, 1997 11:17 AM
> To: fumiona@venus.dtinet.or.jp; 1394-architecture@1394ta.org
> Subject: Re: P1394> Re: SBP-2 Bidirectional ORB
>
> In a message dated 97-11-21 12:18:06 EST, fumiona@venus.dtinet.or.jp
> 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
>
> pjohansson@aol.com
> << File: InOrbStalled.PDF >>