[Nagasaka, Fumio]
May be CBT credit management for multiple channels could be
expensive from memory requirements reason. And multiple login
requires SBP-2 target to have server capabilities. A server style
program consumes many threads and memory, also it brings
complexities into software development. Actually these difficulty
would be solved by software development effort.
But as you know, Windows NT5.0 SBP-2 initiator invokes one log-in
to the target device when PC boots up. And the initiator never log-out
until an user shut down his PC. I am afraid of that log-in function of
SBP-2 is not exported to other software, in Windows NT5.0 environment.
I mentioned two reasons above. Basically single login for one CBT
is merely simple. Because, SBP-2 layer shall be a simple data path
as data link layer for the transport protocol.
--------------------------------------------
-------------------------------
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: Greg Shue [SMTP:gregs@sdd.hp.com]
Sent: Saturday, January 10, 1998 11:29 AM
To: Fumio Nagasaka
Cc: p1394@pwg.org
Subject: P1394> RE: [PP1394:00137]
Hi,
Fumio wrote:
> 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".
[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.
> "One login for one logical channel" solves this problem. However multiple
> 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.
> -------------------------------
> 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
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------