SAS-1.1 Disable First Burst problem

Elliott, Robert (Server Storage) elliott at hp.com
Mon Sep 15 16:01:14 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, September 15, 2003 2:12 PM
> To: Elliott, Robert (Server Storage); t10 at t10.org
> Subject: RE: SAS-1.1 Disable First Burst problem
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Nixon, Bob" <Bob.Nixon at Emulex.Com>
> *
> Rob, I believe the situation is not so bad as you suggest for 
> the sense of the DISABLE FIRST BURST bit proposed in 03-249r2.
> 
> The meaning of the DISABLE FIRST BURST bit being set to 0 is 
> that the mode page shall be honored. The case you describe as 
> "target does not support first burst" is also indicated by the
> mode page setting.  1.0 targets will honor the mode page because
> they don't know any better and 1.1 targets will honor the mode 
> page because that's what is instructed by DISABLE FIRST BURST
> bit being set to 0.  This leads to the much less grim situation that 
> 
> The possible responses to the DISABLE FIRST BURST bit being 
> set to 0 are:
> * SAS-1.0 or 1.1 target
>   * all cases: SUCCEEDS (honors the mode page)
> 
> You are correct that there are several failure cases for a 
> 1.0 target when
> the DISABLE FIRST BURST bit is set to one. Subclause 3.2 of 03-249r2
> suggests that it is incumbent on the intiator not to set the bit in
> operation with a 1.0 target, and suggests a method to determine this
> condition.
> 
> On the other hand, the opposite sense of the bit would lead 
> to complete inoperability of a 1.0 initator with a 1.1 target that 
> supports first burst.

Since there are probably no initiators or targets being designed yet 
that support first burst, any device that does can easily be declared 
a 1.1 device and use an ENABLE bit to confirm its support for first
burst.

> I don't believe a change in sense of the bit is a net gain.  It may be
> desirable to insert the equivalent of subclause 3.2 of the 03-249r2
> somewhere in the standard, though.

Version descriptors are optional, and T10 usually doesn't like solutions
that require changing behavior based on version numbers.

I'd rather not burden every non-first burst capable initiator with
checking 
for this (forever); instead, let's place the burden on the first-burst 
capable  initiator to determine that it's safe to set an ENABLE bit.

With an ENABLE bit, real-life initiators can just set it to 0 and forget
about it.  With a DISABLE bit, they're forced to do more work (involving
both application software to issue INQUIRYs and MODE SENSEs to 
investigate, an API to set the mode in the HBA, firmware to implement 
the API, and hardware to allow both settings).

> 
>    - Bob
> 
> -----Original Message-----
> From: Elliott, Robert (Server Storage) [mailto:elliott at hp.com]
> Sent: Monday, September 15, 2003 10:53 AM
> To: t10 at t10.org
> Subject: SAS-1.1 Disable First Burst problem
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert (Server Storage)" <elliott at hp.com>
> *
> While I was in the SAS phy WG meeting, the SAS protocol WG passed a
> proposal adding a DISABLE FIRST BURST bit to the COMMAND frame
> (03-249r2).  Unfortunately, this proposal makes SAS-1.0 and SAS-1.1
> incompatible, mainly since targets are allowed (although not required)
> to check reserved fields in the SSP COMMAND frame headers.
> 
> The possible responses to the DISABLE FIRST BURST bit being set to 0
> (per SAS-1.0) are:
> * SAS-1.0 or SAS-1.1 target
>   * with first burst: FAILS (mismatch)
>   * without first burst: SUCCEEDS
> 
> The possible responses to DISABLE FIRST BURST being set to 1 (per
> SAS-1.1) are:
> * SAS-1.0 target
>   * without first burst
>     * does not check reserved fields: SUCCEEDS (no first burst)
>     * checks reserved fields: FAILS (get a RESPONSE frame indicating
> INVALID FRAME)
>   * with first burst
>     * does not check reserved fields: FAILS (mismatch)
>     * checks reserved fields: FAILS (get a RESPONSE frame indicating
> INVALID FRAME)
> * SAS-1.1 target
>   * all cases: SUCCEEDS (no first burst)
> 
> I think it works better if the sense is ENABLE FIRST BURST.  This only
> breaks when first burst is used, not when it is not used:
> ENABLE FIRST BURST set to 0:
> * SAS-1.0 target
>   * without first burst: SUCCEEDS (no first burst)
>   * with first burst: FAILS (mismatch)
> * SAS-1.1 target
>   * all cases: SUCCEEDS (no first burst)
> 
> ENABLE FIRST BURST set to 1:
> * any kind of target: doesn't happen since no initiator supports this
> misplaced feature
> (but assuming an initiator does support it:)
> * SAS-1.0 target
>   * without first burst
>     * does not check reserved fields: FAILS (mismatch)
>     * checks reserved fields: FAILS (get a RESPONSE frame indicating
> INVALID FRAME)
>   * with first burst 
>     * does not check reserved fields: SUCCEEDS
>     * checks reserved fields: FAILS (get a RESPONSE frame indicating
> INVALID FRAME)
> * SAS-1.1 target
>   * all cases: SUCCEEDS (honors the mode page)
> 
> I would like to incorporate the proposal into SAS-1.1 
> revision 1 with an
> editor's note advising that the sense of the bit may change, 
> and propose
> changing the sense in the November CAP meeting.
> 
> --
> 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
> *
> * 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