Object oriented issues

Peter Johansson PJohansson at acm.org
Fri Jul 21 09:49:00 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* Peter Johansson <PJohansson at ACM.org>
*
At 11:22 AM 7/21/00, Ericson, George wrote:

>Be sure to separate SCSI Upper Level Protocol(ULP)from SCSI Lower Level 
>Protocol (LLP) issues.
>
>Its not obvious that SAM needs much (if any) changes to support 
>bi-directional traffic.
>
>However, the various SCSI LLP (including ISCSI) specifications would 
>certainly need to change if bi-directional traffic were to be supported.
>For some this may be difficult (SCSI Parallel), others may be easier, 
>(FCP, ISCSI).

I agree with George that the effects of bidirectionality upon SAM may not 
be large.

It's also easy to support bidirectional data flow in the transport layer. 
When SBP-2 (now ANSI NCITS 325-1998) was under development, two sets of 
data pointers (one inbound, one outbound) were discussed. We settled upon 
one set for relatively weak reasons: a) there was a desire to fit the 
transport control data structures into 32 bytes and b) SAM did not look 
beyond unidirectional flow.

Perceived "sweet spots", such as 32 bytes for a control structure, tend to 
have rapid obsolescence.

In the interval since the approval of SBP-2, another project (now in ballot 
as IEEE P1394.3) was started to remediate the unidirectional nature of 
SBP-2. It's important to support bidirectional data flow over IEEE 1394 
since the interconnect is both a) peer-to-peer and b) loosely-coupled. As 
has already been observed on this reflector, it is much easier to guarantee 
the atomicity of operations in a loosely-coupled environment when a single 
operation may have bidirectional data flow.

Well, IEEE P1394.3 does a perfectly workable job of bringing 
bidirectionality to SBP-2. With the benefit of hindsight, it would have 
been much simpler if it had been designed in from the start.

Perhaps this is an opportune to revisit SAM and extend it to bidirectional 
data flows. I think this architectural feature could be used to good 
purpose by OSDs, at the very least.






Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson at ACM.org

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list