Re-transmit of SAS_RESPONSE

Larry Chen Larry_Chen at pmc-sierra.com
Fri Jul 7 17:31:01 PDT 2006


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

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