XFER_RDY - CREDIT_BLOCKED - Resuming Data Transfer

Day, Brian Brian.Day at lsil.com
Fri Mar 12 07:22:19 PST 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsil.com>

Answers to your questions:

1.  The initiator would be the one to establish future connections.
2.  Current SAS 1.0/1.1 rules state that only a single XFER_RDY 
  may be outstanding for a given TAG.... section of
  the SAS spec.  The initiator needs to remember the remaining
  XFER_RDY amount for that TAG across connections.
3.  It seems correct to have whoever has frames to actually send 
  be responsible for establishing these connections.  That way
  once the connection is established, frames can immediately
  follow the OPEN_ACCEPT.  In pSCSI, you would often see the
  reselection from the target occur, and then a long "dead"
  time while the initiator went off and fetched all the data
  again.  In SAS we avoid this dead time by getting connections
  closed more frequently, allowing other devices to get their
  work done as well.  Also remember that the OPEN_REJECTs the
  target may be issuing should be a pretty quick handshake.

Hope this helps...

Brian Day
LSI Logic  

-----Original Message-----
From: Bellamy, Wayne [mailto:wayne.bellamy at hp.com]
Sent: Thursday, March 11, 2004 1:57 PM
To: 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)).

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.


Grateful for all replies,

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
* 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