ST_ITS6: Receive_Data_in state question in sas1r06.

Elliott, Robert (Server Storage) elliott at
Fri Nov 19 17:57:16 PST 2004

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert (Server Storage)" <elliott at>
> * From the T10 Reflector (t10 at, posted by:
> * "Chang, Neil" <neil.chang at>
> *
> Section describes the following:
> -----
> ST_ITS6:Receive_Data_In state
> State description
> If this state receives a Data-In Arrived message from the ST_IFR state
> machine, then this state shall verify the DATA frame received with the
> message as follows:
> 1) check the data offset. If the data offset was not expected 
> (i.e., the
> CHANGING DATA POINTER bit is set to one and the value in the 
> field is not set to a data offset associated with a previous ACK/NAK
> balance, or the CHANGING DATA POINTER bit is set to zero and the value
> in the DATA OFFSET field is not set to the value in the DATA OFFSET
> FIELD in the previous DATA information unit plus the number 
> of bytes in
> that information unit), then this state shall send a 
> Reception Complete
> (Data Offset Error) message to the ST_IFR state machine;
> ------
> The question:
> When CHANGING DATA POINTER bit is set to one, this is a retransmission
> of the data frame. As an initiator in the receive_data_in state
> (initiator is receiving read data), it is impossible for the initiator
> to keep track of the ACK/NAK balance point. The ACK/NAK that the
> initiator returned could still be on the wire so the 
> initiator's balance
> point is different than the target's balance point or the 
> ACK/NAK can be lost.
> Clarification on checking the ACK/NAK balance on read data
> retransmission is appreciated.

The initiator has to be prepared to handle fairly arbitrary read data
offsets (if CHANGING DATA POINTER is 1).  Even if it is throttling RRDY
credits so there is only one read DATA frame outstanding at a time, the
target is not required to retry only that frame - it can go back to any
balance point (from its perspective).

There is no XFER_RDY interlocked frame transmission to serve as a retry
point that both sides can agree they either successfully exchanged or
did not successfully exchange.  

There wasn't much enthusiasm to add such communication (e.g. adding
something similar to the SAVE DATA POINTERS message in parallel SCSI) to
the protocol when transport layer retries were defined.  

The initiator just has to be prepared to reset its DMA engine (and
rewalk its internal scatter-gather list) to reestablish the read data
pointer for the command.  While doing this, it may have to temporarily
cease sending RRDY frame credits if read data starts piling up.

> Regards,
> Neil Chang

Rob Elliott, elliott at
Hewlett-Packard Industry Standard Server Storage Advanced Technology

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list