about the SAS XL state machine

Gil Romo gil.romo at qlogic.com
Thu Dec 11 11:37:50 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Gil Romo <gil.romo at qlogic.com>
*

> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Hoglund, Tim" <thoglund at lsil.com>
> *
> 
> Here's my assessment:
> 
> Should two phys A, B arbitrate at the same time for each other, I would
> expect the following:
> 1. ECM will recognize the arbitration attempts and send Arbitrating(Normal)
> to both phy A,B.
> 2. Phy A and B will both transmit AIP(NORMAL)
> 3. ECM will send ArbWon to arbitration winner (say phy A) and ArbLost to
> arbitration loser (phy B).
> 4. Phy A will proceed to Request_Open, causing Phy B to Forward_Open which
> will transmit the higher priority open out Phy B.
> 
> Should the timing vary slightly such that Phy A begins arbitratation
> (Request_Path) as Phy B is receiving an Open Address Frame, I would expect
> the following:
> 1. ECM will recognize Phy A arbitrating and send Arbitrating(Normal) to Phy
> A
> 2. Phy B enters Request_Path
> 3. ECM declares Phy A arbitration winner (ArbWon) because Phy B was late
> with it's request.
> 4. ECM will not send Arbitrating(anything) to Phy B.
> 5. Phy A will proceed to Request_Open, causing Phy B to Forward_Open which
> will transmit the open address frame out Phy B (irrespective of it's
> priority relative to the Open Address Frame Phy B received).
> 6a. If Phy A's open address frame was higher priority, everything is fine
> and will be resolved downstream.
> 6b. If Phy A's open address frame was lower priority, when in
> Open_Response_Wait Phy B needs to BackoffRetry or BackoffReversePath.
> 
> Spec requirements:
> 1. XL1:Request_Path must transition to XL5:Forward_Open if it receives a
> Transmit Open indication.
> 2. XL6:Open_Response_Wait must remember that it has received an Open address
> frame that has not been acted on yet such that it will go through
> BackoffRetry/BackoffReversePath process if necessary.
> 

I agree with your resolution of this issue, as this was also what I suggested to 
Shogo in an earlier reply.

Suggested changes:

7.12.4.1 Arbitration overview

<perhaps at the end of this subclause>

Before beginning arbitration, the ECM shall respond with an Arbitrating (Normal) 
confirmation to each phy with a contending request.  The ECM shall not accept 
any more requests and shall send no confirmations to other phys until it has 
completed arbitration and has responded to each request with an Arb Won, Arb 
Lost or Arb Reject confirmation.

7.15.4 XL1:Request_Path state

<add this subclause between 7.15.4.3 and 7.15.4.4>

7.15.4.<n> Transition XL1:Request_Path to XL5:Forward_Open

This transition shall occur if:

a) a Transmit Open indication is received; and
b) an Arbitrating (Normal) confirmation has not been received.

This transition shall include an OPEN Address Frame Received argument.

> TimH
> 
> ~~~~~~~~~~~~~~~~~~~~~~~
> Tim.Hoglund at lsil.com
> LSI Logic Corporation
> Storage Std Products
> 719/533-7450 (Voice)
> 719/533-7480 (Fax)
> ~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> -----Original Message-----
> From: Gil Romo [mailto:gil.romo at qlogic.com]
> Sent: Wednesday, December 10, 2003 1:31 PM
> To: t10 at t10.org
> Subject: RE: about the SAS XL state machine
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gil Romo <gil.romo at qlogic.com>
> *
> 
> > 
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * "Elliott, Robert (Server Storage)" <elliott at hp.com>
> > *
> > The difference in XL0 and XL1 handling of Transmit OPEN (an outbound
> > request) is that in XL0, the OPEN would go out before AIP and be subject
> > to full arbitration comparison, while after reaching XL1, it would go
> > out after AIP and automatically win.
> > 
> > If XL0 sees both an outbound Transmit Open indication and an inbound
> > OPEN Address frame, it remembers the inbound frame, but process the
> > outbound request first.  It doesn't issue a Request Path for the inbound
> > request at that time.  It goes to XL5:Forward_Open and then
> > XL6:Open_Response_Wait, where the two requests are compared.  If the
> > inbound request is the winner, it backs off the outbound request and
> > finally goes to XL1:Request_Path.
> > 
> > Once XL0 commits to XL1, it sends an AIP and sends the Request Path
> > request to the ECM.  There is no Abort for a Request Path, so we cannot
> > let XL1 jump to a state the transmits the OPEN the same as if it had
> > happened in XL0.
> > 
> 
> Actually, the phy doesn't automatically transmit AIP when entering XL1  
> (7.15.4.1, "If an Arbitrating (Normal) confirmation is received, this state 
> shall repeatedly send a Transmit AIP (Normal) message to the XL
> Transmitter.").
> 
> Does the use of the Arbitrating (Normal) confirmation come into play here?
> The 
> standard doesn't describe its use.  My guess is that, if the ECM is already 
> arbitrating when a phy sends another request, it won't return an Arbitrating
> 
> (Normal) confirmation until it's done.  If this is true, then the ECM could 
> prevent the phy from transmitting an AIP and always use the pre-AIP rule.
> 
> > I think the resolution is: It is up to the ECM not to send a Transmit
> > Open to a phy after receiving a Request Path from that phy, without
> > first sending an Arb Lost.  This rule needs to be stated somewhere
> > (probably 7.12.4.1).
> > 
> > 
> > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > * "Shogo Hamasaku" <hamasaku at d1.hw.necst.nec.co.jp>
> > > *
> > > Gil, thank you for your consideration.
> > > I agree with you in the case of your explanation.
> > > 
> > > So, what do you think in the case of that in my previous e-mail?
> > > That means Phy#A state machine changed to XL1 just before 
> > > (or simultaneously) to receive Transmit Open request from Phy#B 
> > > via ECR.
> > >
> > > Thanks,
> > > Shogo Hamasaku
> > > 
> > > 
> > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > * Gil Romo <gil.romo at qlogic.com>
> > > *
> > > > If phy#A receives a Transmit Open indication before 
> > > receiving an Arbitrating 
> > > > (Normal) confirmation, perhaps it should transition to XL5. 
> > >  The transition 
> > > > would have been XL0 to XL5 if the OPEN address frame had 
> > > not yet been received. 
> > > > The passing requests are handled by the XL6 state.
> > > > 
> > > > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > > > * "Shogo Hamasaku" <hamasaku at d1.hw.necst.nec.co.jp>
> > > > > *
> > > > > Hi all,
> > > > > 
> > > > > I have a question about the SAS XL state machine.
> > > > > 
> > > > > What do I do with the XL state machine of Phy#A after Step:3?
> > > > > I could not find a description about this situation in 
> > > SAS-1.1 rev.1. 
> > > > > I think that the XL state of Phy#A depends on the 
> > > priority of both requests.
> > > > > 
> > > > > Step:1  Phy#A is XL0:Idle
> > > > > 
> > > > > Step:2  Phy#A receives an OPEN Address Frame.
> > > > >         Then, XL state machine of Phy#A changes from XL0 
> > > to XL1:Request_Path.
> > > > > 
> > > > > Step:3  Phy#A requests a Request Path to the ECM. 
> > > > >         At the same time, Phy#A recives a Transmit Open 
> > > request from Phy#B 
> > > > >         via the ECR, because The ECM has determined to 
> > > make a connection 
> > > > >         between Phy#B and Phy#A.
> > > > > 
> > > > > So, I thought that a new state (XL11) could be add to the 
> > > XL sate machine.
> > > > > 
> > > > > Transition XL1:Idle to XL11  
> > > > >   - A Transmit Open request is received.
> > > > > 
> > > > > State description about XL11
> > > > >   - This state shall compare a Request Path request arguments and 
> > > > >     a Transmit Open request arguments according to the 
> > > arbitration fairness 
> > > > >     comparison. 
> > > > >   - If a Request Path request is a higher priority, this 
> > > state shall send a 
> > > > Backoff
> > > > >      Retry or a Backoff Reverse Path response to a 
> > > opposite Phy via the ECR.
> > > > >   - If a Transmit Open request is a higher priority,  
> > > this state shall change 
> > > > to 
> > > > >      XL5:Forward_Open.
> > > > > 
> > > > > Thanks,
> > > > > Shogo Hamasaku
> > > > > NEC System Technologies, Ltd.
> > > > >   External:(+81)89-947-7901
> > > > > *
> > > > > * For T10 Reflector information, send a message with
> > > > > * 'info t10' (no quotes) in the message body to majordomo at t10.org
> > > > 
> > > > ------------
> > > > Gilbert Romo
> > > > Circuits & Integration
> > > > QLogic Corporation, Aliso Viejo, California
> > > > Office: 949-389-6266
> > > > E-mail: gil.romo at qlogic.com
> > --
> > 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
> 
> ------------
> Gilbert Romo
> Circuits & Integration
> QLogic Corporation, Aliso Viejo, California
> Office: 949-389-6266
> E-mail: gil.romo at qlogic.com
> 
> *
> * 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

------------
Gilbert Romo
Circuits & Integration
QLogic Corporation, Aliso Viejo, California
Office: 949-389-6266
E-mail: gil.romo at qlogic.com

*
* 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