Re-transmit of SAS_RESPONSE

George Penokie gop at us.ibm.com
Wed Aug 2 19:16:56 PDT 2006


Formatted message: <A HREF="r0608020_f.htm">HTML-formatted message</A>

Larry,
The statement in section 9.2.6.3.3.3 ST_TTS2:Target_Send_Frame state of 
SAS 2 rev 5a (which has not changed since SAS 1.1) that states:
If transport layer retries are enabled, the Transmit Frame request was for 
a RESPONSE frame, the vendor-specific number of retries has not been 
reached, and this state receives one of the following confirmations:....
Is not correct. It should be:
If the Transmit Frame request was for a RESPONSE frame, the 
vendor-specific number of retries has not been reached, and this state 
receives one of the following confirmations:....
The RESPONSE frame reties is not tied to transport layer retries.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Larry Chen <Larry_Chen at pmc-sierra.com> 
Sent by: owner-t10 at t10.org
07/07/2006 07:31 PM
To
"T10 (t10 at t10.org)" <t10 at t10.org>
cc
Subject
Re-transmit of SAS_RESPONSE
Hi,
In the SAS-1.1 spec, it is not very clear if the target device should 
retry
Sending the SAS_RESPONSE at least one time, if transport layer retries
Are disabled.
For example,
[1] says SSP target port should unconditionally Re-transmit the 
SAS_RESPONSE
At least one time.
[2] says SSP target port should Re-transmit the SAS-RESPONSE iff transport 
layer
Retries are enabled.
[3] says transport layer retries only applies to XFR_RDY and DATA frames
On the surface, Re-transmit of SAS_RESPONSE by the target device seems a 
bit
Dangerous when compared to FCP-1 and FCP-2 based solutions. The SAS 
initiator port
Is free to immediately re-use the command resources after the SAS_RESPONSE 
with
Retransmit bit set to 0. If the ACK is lost to the initial SAS_RESPONSE 
frame (with
Retransmit bit set to 0), then the initiator Port may have trouble the 
difference between
stale and new command.
Lastly, is there a way to disable all Re-transmit of SAS-RESPONSE at the 
target device?
==
[1] Taken from SAS-1.1 rev 10 page 364
9.2.4.6 RESPONSE frame - handling of link layer errors
If an SSP target port transmits a RESPONSE frame and receives a NAK for 
that frame, the SSP target port
retransmits, in the same or a new connection, the RESPONSE frame at least 
one time with the RETRANSMIT bit
set to one (see 9.2.6.3.3.7.1).
If an SSP target port transmits a RESPONSE frame and does not receive an 
ACK or NAK for that frame (e.g.,
times out, or the connection is broken):
1) the SSP_TF state machine closes the connection with DONE (ACK/NAK 
TIMEOUT) (see 7.16.8.6.5);
and
2) the SSP target port retransmits, in a new connection, the RESPONSE 
frame with the RETRANSMIT bit
set to one (see 9.2.6.3.3.7.1).
The ST_TTS state machine retransmits each RESPONSE frame that does not 
receive an ACK at least one
time (see 9.2.6.3.3). The number of times it retransmits each RESPONSE 
frame is vendor-specific.
If an SSP initiator port receives a RESPONSE frame with a RETRANSMIT bit 
set to one, and it has previously
received a RESPONSE frame for the same I_T_L_Q nexus, the ST_IFR state 
machine discards the extra
RESPONSE frame (see 9.2.6.3.2). If the ST_IFR state machine has not 
previously received a RESPONSE
frame for the I_T_L_Q nexus, then it considers the RESPONSE frame to be 
the valid RESPONSE frame.
[2] Taken from SAS-1.1 rev 10 page 391.
If transport layer retries are enabled, the Transmit Frame request was for 
a RESPONSE frame, the
vendor-specific number of retries has not been reached, and this state 
receives one of the following
confirmations:
a) Transmission Status (NAK Received);
b) Transmission Status (ACK/NAK Timeout); or
c) Transmission Status (Connection Lost Without ACK/NAK),
then this state shall:
a) set the RETRANSMIT bit to one; and
b) resend a Transmit Frame (Interlocked) request to the port layer for the 
failed RESPONSE frame.
[3] Taken SAS-1.1 rev10 page 428
Transport Layer Retries is defined in the Protocol-Specific
Logical Unit mode page for SAS SP (Page Code = 18h).
A TRANSPORT LAYER RETRIES bit set to one specifies that the target port 
shall support transport layer retries for
XFER_RDY and DATA frames for the logical unit as described in 9.2.4 (i.e., 
transport layer retries are
enabled). A TRANSPORT LAYER RETRIES bit set to zero specifies that 
transport layer retries shall not be used
(i.e., transport layer retries are disabled)
Do you think this is an oversight and should include RESPONSE frames too?



More information about the T10 mailing list