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
https://ecardfile.com/id/RobElliott
*
* 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