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