about the SAS XL state machine

Shogo Hamasaku hamasaku at d1.hw.necst.nec.co.jp
Fri Dec 12 03:20:13 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Shogo Hamasaku" <hamasaku at d1.hw.necst.nec.co.jp>
*
Dear Gilbert-san and Tim-san

Thank you for your reply.
Your suggestion hits my point.

Thanks,
Shogo Hamasaku
 NEC System Technologies, Ltd.
 External:(+81)89-947-7901


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