Comments/Clarifications on sas1r03 SSP transport layer
Elliott, Robert (Server Storage)
elliott at hp.com
Sat Mar 13 17:05:08 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ameen Rahman <ameen at cup.hp.com>
> *
> I have the following comments/clarifications on
> SAS-1.1 Revision 3, Dated 24 Jan 2004
>
> 1) COMMAND frame - handling og link layer errors (Sec
> 9.2.4.2, Page 282)
>
> The last sentence in this page is,
> "An SSP initiator port should re-transmit each COMMAND frame that
> does not receive an ACK ateast one time".
>
> I think an SSP initiator port should retransmit only those COMMANDs
> which were NOT delivered to the target port.
It's just a "should." If it gets a NAK, it might try another target
port with access to that logical unit (perhaps using a different
initiator port altogether) if it has knows of one. Or, it might just
retry the command on the same I_T.
> 2) SSP frame format ( Sec 9.2.1, Page 270 )
> This section doesn't explain the RETRY DATA FRAMES and
> CHANGING DATA pointer fields of SSP frame header. Probably some
> text needs to be added in this section to explain these fields.
> Explanation for these fields can be found in later sections though.
The missing paragraphs from 03-186r5 will be included in sas1r04.
> 3) SSP frame format ( Sec 9.2.1, Page 270 )
>
> Explanation for RETRANSMIT bit from the standard:
>
> "The RETRANSMIT bit is set to one for TASK frames, RESPONSE frames,
> and XFER_RDY frames under the conditions defined in FIXFIX and shall
> be set to zero for all other frame types. This bit indicates the
> frame is a retransmission after the SSP target port failed in
> its previous attempt to transmit the frame"
>
> a) In the above "FIXFIX" needs to be sustituted with
> relevant section numbers.
Fixed in sas1r04.
>
> b) RETRANSMIT bit is also a indication of initiator port failed in
> its previous attempt to transmit a frame ( TASK frame )
Will remove "target" in sas1r04.
> 4) TASK frame - handling of link layer errors ( Sec 9.2.4.3,
> Page 283 )
>
> If a NAK is recieved for the TASK frame, what should be
> the action ?
> Retry the TASK frame with RETRANSMIT bit set to 0 ??
That's up to the initiator (same for COMMAND frames that are NAKed).
It knows the target didn't get it, so it can do whatever it wants.
There's
a general rule that it should retransmit the frame at least once.
There's
no requirement for the RETRANSMIT bit to be set to 1, though. That's
just
for ACK/NAK uncertainty. (see the application client error handling
section 10.2.2)
> 5) XFER_RDY frame with transport layer re-tries ( Sec 9.2.4.4.3 , Page
> 283 )
>
> When the target recieves NAK for a XFER_RDY, probably it should
> not set RETRANSMIT bit to 1 in the retransmitted XFER_RDY.
The SAS WG discussed this and recommended keeping the RETRANSMIT
bit as 1 in this case to ease the job of logic analyzers and engineers
in the lab. As the editor's note says, it provides no benefit to
the initiator (since it sent a NAK and never saw the original frame).
> Regards
> -Ameen
--
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
More information about the T10
mailing list