In PC-to-Device case, the PC resources like processor power need to be
efficiently shared with many other tasks.
SBP-2 is based on the "message passing/shared memory" model. The
shared memory function is provided by "bus" nature of 1394 and bridge
feature of OHCI style link. The message passing is done using
initiator's request queue (linked list of ORB's) and target's
response queue (status_FIFO) pair in the initiator's memory space.
Because the message passing does not require synchronization with the
target response, (i.e., the "initiator" PC can queue messages as far
as it has resource), SBP-2 will greatly reduce OS involvement (of
latency critical code) in I/O activities. Also bridge feature of OHCI
style link will free the CPU from shared memory accesses. So, SBP-2
"initiator" will efficiently share PC resources with other tasks while
achieving high bandwidth.
Furthermore, "target" device can de-queue the request messages at its
own pace.
As described above, SBP-2 has a benefit when used as a (possibly
uni-directional) data path between "initiator" PC and "target" device.
Though it will be technically possible to make link peer-to-peer by
"targiator" approach with SBP-2 and it will work on various link
implementations, I think it will be too tough to require expensive
bridge hardware in any device to be "initiator" device. The device
will be cost sensitive with doing dedicated task as contrast with PC
to be general purpose.
Without bridge hardware, the SBP-2 will lose its appeal because
"message passing/shared memory" model is not optimized for packet
exchange on the wire due to its indirect buffer reference.
So, I think Device-to-Device (or peer-to-peer) other than SBP-2
"targiator" should also be addressed.
It may be good to make device-to-device framework that has an extra
SBP-2 data path for "PC-to-device" (or PC-to-PC) in it.
Akihiro Shimura
On Tue, 17 Feb 1998 17:40:15 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:
>
>
> Gee, so much discussion ...
>
> Hitoshi Sekine writes:
> > Saying just 1284.4 over SBP-2 may cause some confusions. Have
> > you described what is inefficient to stack overlapping
> > functionality and tried to remove it from 1284.4 over SBP-2? Is
> > supporting socket interface included in the latest proposal? If
> > you have, I am sorry. My manager didn't allow me to travel to
> > Maui, however I loved to be there. Can you update the latest
> > status or a meeting memo in Maui? I need catching up you.
>
> [Greg Shue]
> If anything is removed from 1284.4 or SBP-2 for a combined solution,
> then the driver(s) for the protocol(s) affected cannot be used.
> They are no longer the standard protocols.
>
> The proposal I made at the January PWG meeting placed no requirements
> or restrictions on the API. Sockets may be supported.
>
> Kazuhiro Hirata asks:
> > Alan or Greg, why did you choose SBP-2 based profile rather than 1284.4
> > at Jan. PWG?
>
> [Greg Shue]
> There are several reasons for choosing SBP-2 rather than 1284.4:
>
> 1. SBP-2 is defined and exists.
> 2. SBP-2 is preferred by Microsoft and Apple.
> 3. It already addresses the issue of access control and reconnect
> 4. The PWG already expressed preference against a 1284.4 only solution.
> 5. The Unit Architecture provides independent access to multiple services.
> 6. I wanted to prove to myself whether or not it was feasable!
>
> Brian Batchelder writes:
> > Actually, I am currently leaning towards SBP-2, but we must use
> > it in a way that allows clients to be clients, servers to be
> > servers, and both to exist on every device. This probably means
> > implementing both target and initiator (targiator) functionality
> > on each device. If the chip implementations available today
> > don't optimally support targiators, well, we won't be optimal
> > until they are fixed. However, I was pleased to read Michael
> > Teener's message in which he indicated that targiators should be
> > quite possible.
>
> [Greg Shue]
> Good job Brian!
>
> I agree that we must use SBP-2 in a way that allows clients to
> be clients, and servers to be servers, and both to exist on
> every device.
>
> The coined terms "targitator" and "targiator" may get confusing
> as they have been used slightly differently. In one case it
> refers to an transport connection composed of cross-SBP-2-logins.
> The other case refers to a device which provides both SBP-2
> initiator libraries and SBP-2 target libraries.
>
> Good Job Michael! I completely agree that any device should be
> capable of support both SBP-2 initiator and SBP-2 target functionality.
> The HW assists are not required.
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products Division gregs@sdd.hp.com
> ----------------------------------------------------------------
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.