A SAS Outstanding Xfer_RDY Question.

Elliott, Robert (Server Storage) elliott at hp.com
Mon Jun 30 16:32:11 PDT 2003

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>

> -----Original Message-----
> From: Nixon, Bob [mailto:Bob.Nixon at Emulex.Com] 
> Sent: Monday, June 30, 2003 6:12 PM
> To: Elliott, Robert (Server Storage); t10 at t10.org
> Subject: RE: A SAS Outstanding Xfer_RDY Question.
> Thanks, Rob, "misplaced" was exactly our concern...I didn't 
> want to polish
> this tu...rkey, I wanted to simply and reliably disable it. 
> I appreciate your confirmation that a first burst is not very 
> useful and add
> that supporting all the possible pathological behavior in a 
> multi initiator
> environment, where it MAY change unpredictably, makes it exceedingly
> expensive in code complexity.  That's why I was looking for a 
> cheap reliable
> way for us transport providers to be SURE it didn't apply.  
> The mode page
> alone doesn't give any way to assure that since it is changeable by an
> uncontrolled population of other initiators (and by the 
> target itself, for that matter).
> It's possible I'm missing some important point...Is there 
> already a way for
> an initiator to opt out of first burst behavior independent 
> of what other
> initiators choose?  (Or am I misinterpreting that the first 
> burst size is writable by initiators?)

For the Disconnect-Reconnect page, T10 chose that "changes in the 
parameters for one target port should not affect other target 
ports." and "The parameters for a target port affect its behavior 
regardless of which initiator port is forming an I_T nexus with 
the target port."  (based on FC implementations and general
disdain for per-initiator mode pages)

So, any initiator can change it and it does affect all the others.
A change results in a unit attention for all initiator ports that
are affected.

An initiator needs to know the current setting to successfully 
execute a MODE SELECT command, since it is a write command.
If an initiator doesn't support first burst, there's no way for
it to turn it back off once turned on because it can't do 
the write.

A new bit in COMMAND to confirm that first burst is desired
would help that, assuming the target used it to override the 
mode page setting on a per-command basis.  I'd rather just 
obsolete the feature.

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 mailing list