SAS: XFER_RDY - CREDIT_BLOCKED - Resuming Data Transfer
Edward.Younk at hgst.com
Edward.Younk at hgst.com
Fri Mar 12 07:52:19 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* Edward.Younk at hgst.com
*
This is a multipart message in MIME format.
--=_alternative 005819DB86256E55_=
Content-Type: text/plain; charset="us-ascii"
Wayne,
The target will not send and additional xfer_rdy until the burst length
in its original request has been satisfied. It is up to the initiator
to attempt to reconnect and send the additional data. The target may
open_reject(retry) the next open attempt by the initiator, (the targets
buffers may still be full), but it is up to the initiator to retry the
connection until he can send all the data for which the target
requested. At this point the target will send by status when the command
has been completed.
So in short, the answers are.
1. The initiator should reconnect.
2.The initiator must continue to try to reconnect.
3. In real life, what you describe does not happen very often. The well
behaved target will have reserved the necessary space to store the data
before issuing the xfer_rdy. The target may have to send credit blocked
for another reason, such as queue full handling, however.
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
"Bellamy, Wayne" <wayne.bellamy at hp.com>
Sent by: owner-t10 at t10.org
03/11/2004 02:56 PM
To: <t10 at t10.org>
cc:
From: owner-t10 at t10.org
Subject: SAS: XFER_RDY - CREDIT_BLOCKED - Resuming Data
Transfer
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bellamy, Wayne" <wayne.bellamy at hp.com>
*
SAS Scenario:
1) A write command is issued to a SAS target, any HDD target...
2) this target reconnects and provides an SSP XFER_RDY frame for the
complete write data transfer length...
3) later, midway through this transfer of data frames the target
provides ACK and CREDIT_BLOCKED...
4) the initiator issues DONE(CREDIT TIMEOUT) since credit has not been
provided and CLOSEs the connection (target had issued DONE(NORMAL) after
the aforementioned XFER_RDY in 2)).
Questions:
1) In this disconnected situation, write operation incomplete, which
device should reconnect to continue to complete this write operation?
(target or initiator?)
2) Can the target reconnect and issue a new XFER_RDY for the remainder
of the transfer or is it required that the initiator reconnect (or keep
trying to reconnect) to finish the transfer?
3) Somehow it seems incorrect for the initiator to continue to try to
reconnect to the target to finish the transfer. It seems incorrect to
put this management effort onto the initiator. In pSCSI the target
managed when it was ready to reconnect (to finish a data transfer) and
data phase/transfer control.
.end.
Grateful for all replies,
wayne
=20
Wayne Bellamy=20
ISS - HDD Storage - Adv Tech Eng
Loc. CCA15 - 159A28
281-514-5196 fax 281-514-3200=20
email: wayne.bellamy @HP.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
--=_alternative 005819DB86256E55_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">Wayne,</font>
<br>
<br>
<br><font size=2 face="sans-serif">The target will not send and additional xfer_rdy until the burst length in its original request has been satisfied. It is up to the initiator to attempt to reconnect and send the additional data. The target may open_reject(retry) the next open attempt by the initiator, (the targets buffers may still be full), but it is up to the initiator to retry the connection until he can send all the data for which the target requested. At this point the target will send by status when the command has been completed. </font>
<br>
<br><font size=2 face="sans-serif">So in short, the answers are.</font>
<br>
<br><font size=2 face="sans-serif">1. The initiator should reconnect.</font>
<br><font size=2 face="sans-serif">2.The initiator must continue to try to reconnect.</font>
<br><font size=2 face="sans-serif">3. In real life, what you describe does not happen very often. The well behaved target will have reserved the necessary space to store the data before issuing the xfer_rdy. The target may have to send credit blocked for another reason, such as queue full handling, however. </font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Bellamy, Wayne" <wayne.bellamy at hp.com></b></font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">03/11/2004 02:56 PM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: <t10 at t10.org></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> From: owner-t10 at t10.org</font>
<br><font size=1 face="sans-serif"> Subject: SAS: XFER_RDY - CREDIT_BLOCKED - Resuming Data Transfer</font>
<br>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Bellamy, Wayne" <wayne.bellamy at hp.com><br>
*<br>
SAS Scenario:<br>
1) A write command is issued to a SAS target, any HDD target...<br>
2) this target reconnects and provides an SSP XFER_RDY frame for the<br>
complete write data transfer length...<br>
3) later, midway through this transfer of data frames the target<br>
provides ACK and CREDIT_BLOCKED...<br>
4) the initiator issues DONE(CREDIT TIMEOUT) since credit has not been<br>
provided and CLOSEs the connection (target had issued DONE(NORMAL) after<br>
the aforementioned XFER_RDY in 2)).<br>
<br>
Questions:<br>
1) In this disconnected situation, write operation incomplete, which<br>
device should reconnect to continue to complete this write operation?<br>
(target or initiator?)<br>
2) Can the target reconnect and issue a new XFER_RDY for the remainder<br>
of the transfer or is it required that the initiator reconnect (or keep<br>
trying to reconnect) to finish the transfer?<br>
3) Somehow it seems incorrect for the initiator to continue to try to<br>
reconnect to the target to finish the transfer. It seems incorrect to<br>
put this management effort onto the initiator. In pSCSI the target<br>
managed when it was ready to reconnect (to finish a data transfer) and<br>
data phase/transfer control.<br>
<br>
.end.<br>
<br>
Grateful for all replies,<br>
<br>
wayne<br>
=20<br>
Wayne Bellamy=20<br>
ISS - HDD Storage - Adv Tech Eng<br>
Loc. CCA15 - 159A28<br>
281-514-5196 fax 281-514-3200=20<br>
email: wayne.bellamy @HP.com<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
</font>
<br>
<br>
--=_alternative 005819DB86256E55_=--
More information about the T10
mailing list