P1394 Mail Archive: RE: P1394> RE: [PP1394:00137]

P1394 Mail Archive: RE: P1394> RE: [PP1394:00137]

RE: P1394> RE: [PP1394:00137]

Fumio Nagasaka (fumiona@venus.dtinet.or.jp)
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 nagasaka.fumio@exc.epson.co.jp