P1394 Mail Archive: RE: [PP1394:00147] Re: P1394> 1284.4 over SBP-2

P1394 Mail Archive: RE: [PP1394:00147] Re: P1394> 1284.4 over SBP-2

RE: [PP1394:00147] Re: P1394> 1284.4 over SBP-2

Nagasaka Fumio (Nagasaka.Fumio@exc.epson.co.jp)
Fri, 13 Feb 1998 19:54:02 +0900

Greg Shue wrote:
>To highlight the issue:
> Exactly how does an initiator peer which supports CBT receive a
> Credit packet from the target at any indeterminate time?
>This is not provided directly by 1284.4. How are you planning on
>solving it for your implementation of option A?

1) The initiator place “CreditRequest” packet in an out-ORB.
2) If the target find an in-ORB in the linked list of ORBs, target
fill out
the buffer associated this ORB with “CreditRequestReply”
packet.
3) If the target could not find any in-ORB in the linked list of
ORB,
then the target send unsolicited status which requests the initiator
to provide an in-ORB in the list. Then go to step #2.

Am I missing any steps?
I think step #3 becomes overhead. So CBT supportive SBP-2 profile
does not mark higher speed than pure SBP-2 transaction.

--------------------------------------------
-------------------------------
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: Friday, February 13, 1998 4:58 AM
To: pp1394 ML
Subject: [PP1394:00147] Re: P1394> 1284.4 over
SBP-2

>
> This message is in MIME format. Since your mail reader
does not understand
> this format, some or all of this message may not be
legible.
>
> ------ =_NextPart_000_01BD3784.4C5B70D6
> Content-Type: text/plain
>
> Dear Eric,
> Dear Larry,
>
> Please find an attached document which shows issue
Eric and myself
> had discussed at December 3, 1997.
> <<Generation.PDF>>
> I am writing printer drivers that covers first
generation of 1394
> printing.
> These printer drivers are supporting option A.
> <<
> A- 1284.4 with SBP-2
> B- New SBP-2 command set with SBP-2
> >>
> I also prefer to choose option A at least in these
couple of years. One
> of my reason is market reason same as Larry. Another
my reason is
> technical reason. As I mentioned before, a target peer
which supports
> CBT allows initiator peers to send ORBs safely. Any
data link layer
> which services only one data path has difficulties to
support multiple
> logical channels. Because, if once one of logical
channels had been
> stalled, other requests that goes same data path will
be stalled.
> The CBT set the data link layer free from these
difficulties.

Yes, any link which supports only one data path has
difficulties
to support multiple logical channels.

This is exactly why I identified the major issue between
option A
and option B as whether multiple functions within a
device are
provided via:

MUX layer for multiple functions access presented as
one Unit (option A)
vs.
separate units for each function (option B)

This is really the choice between the two options.

The other topic of discussion under this thread deals
with how to
use SBP-2 to provide independent, opposing,
unidirectional data
streams over the same login. Whether option A or option
B is
chosen, the issue of providing the specified
bidirectional
service to the layer above SBP-2 still exists. And, I
think it's
exactly the same issue.

To highlight the issue:

Exactly how does an initiator peer which supports CBT
receive
a Credit packet from the target at any indeterminate
time?

This is not provided directly by 1284.4. How are you
planning on
solving it for your implementation of option A?

> -------------------------------
> 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

----------------------------------------------------------------