about the SAS XL state machine

Gil Romo gil.romo at qlogic.com
Wed Dec 10 12:30:38 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:
> * "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




More information about the T10 mailing list