Subject: P1394> Re: SBP-2 Bidirectional ORB

From: [email-masked]
Date: Mon, 6 Oct 1997 23:46:17 -0400 (EDT)

In a message dated 97-10-06 22:13:42 EDT, [email-masked] writes:

<<1. I agree with David's observation that two ORBs (one read, one write) can
be used instead of a bidirectional ORB.  A device is free to fetch both ORBs
and execute them in whatever order it likes, including simultaneously.  A
device or device class can mandate that such ORB pairs be provided, even
though SBP-2 does not require it.>>

It seems to me that the use of unidirectional ORB's is essentially a
hold-over from SCSI habits of DATA IN or DATA OUT on a single command. It's
not surprising that SBP-2, thus far, addresses this model well---but perhaps
we should move forward.

Two coordinated ORBs is little more than a 64-byte bidirectional ORB that
takes two Serial Bus transactions to fetch! Given the lack of scalability for
arbitration times at faster and faster speeds ('specially for small packets)
I think we ought to avoid the unnecessary fetch.

<<2. I agree with John that the bidirectional ORB will be difficult to deal
with in software.  Even though the SBP-2 layer is thin, there are complex
virtual memory issues, and having a special ORB with two payloads will
complicate that.>>

This is not some Pandora's box that is being opened, with n-directional ORBs
in our future. "Complex virtual memory issues?" Are you suggesting that
operating systems today have *no* API's in which more than one user buffer is
presented and must be locked down? I think the bidirectional ORB is
*different* to deal with in software and not all that difficult. The problems
of coordinating two-in-one ORBs (the paired ORBs David mentions) may be more
difficult than those of dealing with two buffers.

Peter Johansson