Through the tel-conference held at January 12, Greg Shue's opinion
makes me recognize my points shown above had misunderstanding.
PWG-profile defines SBP-2 as CBT driven data-link layer. So when
an initiator starts transaction, the target peer gives credits for each
logical channels. If the initiator appends out-ORB up to given credits,
all these requests will be stored into target peer's FIFO without over-
flow. Thus we don't need to assume that a target agent will be stalled.
On the other hand, when the target peer starts transaction, the initiator
peer gives credits for each logical channels. In this case the initiator
needs to append an in-ORB at each time. Because if the initiator
appends N+k in-ORBs in a list, and the target has only N requests,
then k in-ORBs will not be consumed. From this point of view, I think
each in-ORB shall be set a notify bit one, when PWG-profile applied.
The initiator may be notified when provided in-ORB is consumed by
the target peer. Then the initiator may append one more in-ORB on
the inked list.
As conclusion, I think we don't need to fill CDB with any socket
information
nor control information,... Greg, do you have any points?
--------------------------------------------
-------------------------------
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: Fumio Nagasaka [SMTP:fumiona@venus.dtinet.or.jp]
Sent: Saturday, January 10, 1998 9:48 AM
To: 'Greg Shue'; Nagasaka Fumio
Cc: ALAN_BERKEMA@hp-roseville-om2.om.hp.com; p1394@pwg.org
Subject: RE: P1394> RE: [PP1394:00137]
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