ST_ITS6: Receive_Data_in state question in sas1r06.
Elliott, Robert (Server Storage)
elliott at hp.com
Fri Nov 19 17:57:16 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Chang, Neil" <neil.chang at intel.com>
> Section 22.214.171.124.3.7 describes the following:
> 126.96.36.199.3.7 ST_ITS6:Receive_Data_In state
> 188.8.131.52.3.7.1 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
> DATA OFFSET
> 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.
> Neil Chang
Rob Elliott, elliott at hp.com
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 t10.org
More information about the T10