SAM-3 byte alignment change in 03-002r3

Ralph Weber ralphoweber at compuserve.com
Thu Jan 30 10:46:35 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
*
Although I am not nearly as familiar as Rob is about the
details of how various protocols support transfers that
have only byte alignment, I strongly support his concern.

Since many operation systems try to minimize the number
of memory to memory copies by DMAing data directly out
of user buffer and since may user applications could give
a rat's behind about buffer alignment, I find it very
difficult to believe that SCSI has any transport protocols
that fail to provide for data transfers that are only
byte aligned.

Rob's statement that the actions in Portland were hasty
seems right to me and I plead guilty to being one of those
who failed to impede that rush when I had a chance.

Thanks.

.Ralph

Elliott, Robert (Server Storage) wrote:

> 
>* From the T10 Reflector (t10 at t10.org), posted by:
>* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>*
>I think this change proposed by 03-002r3 went too far:
>
>"Change 20 [relax byte-alignment in SAM-3]:
>In 5.4.3.1 (Data transfer SCSI transport protocol services
>introductions),
>modify the fourth paragraph from the end of the subclause as follows:
>All SCSI transport protocol standards (shall changed to) should define
>support for a resolution of one byte for the above arguments. A SCSI
>initiator device (shall changed to) should support a resolution of
>one byte. A SCSI target device may support any resolution."
>
>
>Although SCSI transport protocols are free to require alignment for most
>data
>phases during a command (e.g. the DATA frames that are not the last DATA
>frame
>might have to be 4-byte aligned), they need to provide byte resolution
>for the
>command as a whole (e.g. there needs to be a way to indicate an odd
>number of
>bytes in the last DATA frame).
>
>This is why parallel SCSI has an IGNORE WIDE RESIDUE message and why
>protocols
>like SAS and FCP have "number of fill bytes" fields in their frame
>headers.
>It's fair to require the "number of fill bytes" field be zero until the
>last
>DATA frame of the command; but I think it's important for SCSI to
>mandate that
>they offer it for the last DATA frame.  Otherwise, the transport
>protocol can
>only support commands that perform multiple-of-n byte transfers (where n
>is
>protocol-specific, since there's no requirement in SAM-3 any more).
>
>Some wording changes from the original may be appropriate to communicate
>this
>intermediate vs. last distinction, but I think just changing those
>"shall"s
>to "should"s goes too far.
>
>
>>From the CAP minutes 03-047r0:
>
>4.8 E-mail SAM-3 topic [Penokie]
>George Penokie presented an issue with SAM-3 requiring byte alignment in
>transfer operations. He noted that most if not all of the serial
>protocols
>violate the SAM-3 statement. The group agreed to discuss the change as
>part of item 8.2.
>
>8.2 Remove SPI from SAM-3 and SPC-3 (03-002) [Weber]
>Ralph Weber presented a proposal to remove the SCSI parallel bus
>concepts
>from SAM-3. He noted that the proposal removes contingent allegiance
>completely. The group requested minor changes including text to resolve
>the
>issue described in item 4.8 and Ralph agreed to prepare a new revision.
>Ralph Weber moved that 03-002r3 (r2 as revised) be recommended for
>inclusion
>in SAM-3 and SPC-3. Mark Evans seconded the motion. In the absence of
>any 
>objections, the motion passed unanimously.
>
>
>--
>Rob Elliott, elliott at hp.com
>Hewlett-Packard Industry Standard Server Storage Advanced Technology
>https://ecardfile.com/id/RobElliott
>
>
>
>
>
>--
>Rob Elliott, elliott at hp.com
>Hewlett-Packard Industry Standard Server Storage Advanced Technology
>https://ecardfile.com/id/RobElliott
>
>
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.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