Subject: RE: P1394> RE: [PP1394:00137]

From: Fumio Nagasaka <[email-masked]>
Date: Sat, 10 Jan 1998 09:48:06 +0900

Hi,
Fumio wrote:
> At LA meeting, we agreed to remove PSID and SSID from CDB of normal
> command block ORB. However, now I would like to suggest to enclose
> 1284.4 supportive flag and 6 bytes 1284.4 packet header in CDB.
> 
> The reason is outlined below.
> 1)	IEEE 1284.4 is providing "out-of-band packet control flag" in the 
> header
> for 1284.4 packets.
> 2)	However if we does not enclose any 1284.4 information in normal 
> command
> block ORB. Fetch Agent needs to examine buffered data that wad 
> fetched
> after the fetch agent processed the ORB.
> 3)	Basically, out-of-band packet shall be extracted as soon as 
> possible.
> 4)	Thus we would like to make short cut to detect out-of-band requests 
> without
> reading buffer space associated with each ORB.

>[Shue,Greg] These comments lead me to think there is some
>confusion about what does "out-of-band" mean.  As I was told at
>one of the PWG meetings, it means information which is
>_synchronous_ to a specific point in the data stream, but is not
>to be interpreted as normal data.  As such, the phrase "shall be
>extracted as soon as possible" doesn't make sense to me.  Can
>this be explained further?

My colleague pointed out same thing. I misunderstood usage of
"out-of-band". But still I would like to enclose some control information
in CDB. Because current specification has problem shown below,...
1) if one data channel is stalled, the fetch agent does not pass data
toward upper layer ( in this case upper layer is CBT).
2) thus the fetch agent stops consuming data from a linked list of ORBs.
3) By the way an application would append new ORB which requests
status reply as the application need to solve the problem. (may be
new ORB uses other logical channel. But the logical channel number
is enclosed in data buffer associated with this ORB)
4) The fetch agent does not read this new data buffer, because he is
    busy. And he does not have any internal FIFO space to read new data.
5) Finally the fetch agent does not pass new request to CBT. He will
know that new ORB should be delivered to other logical channel, thus
he could do that, but he didn't.... It is too late.

We can provide ORB pre-fetch queue as the front end process, before
the fetch agent really consumes data stored in data buffer. And I believe 
that ORBs shall *not* be executed in order. And I prefer to choose
one login for one transport. Thus I want to say "A linked list of ORBs may
contain many requests to various logical channels".

"One login for one logical channel" solves this problem. However multiple
login supportive SBP-2 target is very expensive.

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

---

From: Greg Shue <[email-masked]>
Date: Fri, 9 Jan 1998 18:29:12 -0800 (PST)

Hi,
> contain many requests to various logical channels".

[Shue, Greg]
As I understand it, ORB "pre-fetching" is a desirable (required?)
characteristic of out-of-order processing and out-of-order
completion.  Either there is one login for one transport, and no
multiplexing needs to be done at the SBP-2 level, or there is one
login for multiple transports, so routing information is required
in the ORB CDB (yuck!  :-).  The whole purpose of CBT is to
provide multiplexing and data pacing such that whatever data
packets are sent already have the memory space reserved at the
other end, so all packet transfers can be completed immediately.

[Shue, Greg]
I think we need to choose whether multiple transports are
supported for one login or not.  (Haven't we already decided no?)
If one transport per login, and one login per transport, then
routing is not an issue.

> login supportive SBP-2 target is very expensive.

[Shue, Greg]
What leads you to think that a fetch agent is expensive?  Is it
any more expensive than the CBT agent managing credit for a given
CBT channel?  My guess is that the SBP-2 fetch agent is actually
cheaper, especially since all the code to run the fetch agent
could probably be reused across all instances.  But, I may be
missing some complexity behind an SBP-2 fetch agent.

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------