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

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

P1394> RE: [PP1394:00137]

Greg Shue (gregs@sdd.hp.com)
Fri, 9 Jan 1998 18:29:12 -0800 (PST)

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