[T10] [SAS]Resending Query regarding XL1 to XL5 state transition

Tim.Symons at microchip.com Tim.Symons at microchip.com
Wed May 22 16:22:35 PDT 2019


I'm re-reading the specification to figure out why the phy (Y) OPEN(B to A) request is effectively ignored.
The intention of the informative annex is to illustrate the XL1 to XL5 transition.  This seems to only occur if there is a race condition where the phy(Y) open request causes a transition from XL0 to XL1, but subsequently transitions to XL5 because the ECM has committed the path for A to B. In terms of ECM arbitration messaging the phy(Y) request is effectively ignored due to timing.
This appendix was written in 2008 as an example of the internal flow expander flow, so I don't recall the full details.

The case where the PHY(Y) is acknowledged is in K.5  Connection request - arbitration lost

Regards
Tim.

From: Deep Mehta <deep at cadence.com>
Sent: Wednesday, May 22, 2019 8:54 AM
To: Tim Symons - C33374 <Tim.Symons at microchip.com>
Cc: Gurudatta Mewundi <gmewundi at cadence.com>; Lana Chan <lana at cadence.com>; sasxg_vip <sasxg_vip at cadence.com>
Subject: RE: [SAS]Resending Query regarding XL1 to XL5 state transition


External E-Mail


Hi Tim,

I appreciate if we have any update on this.
Thanks in advance.

Regards,
Deep

From: Deep Mehta
Sent: Friday, May 17, 2019 10:20 AM
To: Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>; t10 at t10.org<mailto:t10 at t10.org>
Cc: Gurudatta Mewundi <gmewundi at cadence.com<mailto:gmewundi at cadence.com>>; Lana Chan <lana at cadence.com<mailto:lana at cadence.com>>
Subject: RE: [SAS]Resending Query regarding XL1 to XL5 state transition

Hi Tim,

Before moving to point no. 2 question, we want get more clarification on question 1.

1.       Per Figure K.18: Why does Expander phy (Y) not have "Arbitrating Normal confirmation" from ECM ?  Expander phy[X] has "Arbitrating Normal confirmation"
[Tim]The Expander Connection Manager (ECM) is the entity that maps the request path from phy(X) to phy(Y). Successful mapping results in the ECM confirmation of Arbitration (Normal) to phy(X) to indicate that phy(Y) has been mapped and is in the process of requesting the egress path to be opened at which point the ECM indicates an Arb Won confirmation to phy(X). Phy(Y) only generates ECM messages is its receiver is requesting a path, and in this case it is not.
>>[Deep] As shown in figure K.18, Expander phy[Y] is having XL0 to XL1 state machine transition. In XL1 state machine entry it will give "Request Path request" to the ECM.
As per section 6.16.5.2.2 Arbitrating confirmations - "The ECM shall send an Arbitrating (Normal) confirmation after it has received a Request Path request."

As shown in below figure, there in Pink color box (Arbitrating Normal confirmation) Expander Phy[X] just after "Request Path request" ; why that box is not present for Expander phy[Y] after it got "Request Path request" ?

[cid:image002.jpg at 01D51095.D0D37C30]

Let us know your thought on this.

Thanks.

Regards,
Deep

From: Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com> <Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>>
Sent: Friday, May 17, 2019 5:57 AM
To: Lana Chan <lana at cadence.com<mailto:lana at cadence.com>>; t10 at t10.org<mailto:t10 at t10.org>
Cc: Deep Mehta <deep at cadence.com<mailto:deep at cadence.com>>; Gurudatta Mewundi <gmewundi at cadence.com<mailto:gmewundi at cadence.com>>
Subject: RE: [SAS]Resending Query regarding XL1 to XL5 state transition

EXTERNAL MAIL
Lana,

1.       Per Figure K.18: Why does Expander phy (Y) not have "Arbitrating Normal confirmation" from ECM ?  Expander phy[X] has "Arbitrating Normal confirmation"

The Expander Connection Manager (ECM) is the entity that maps the request path from phy(X) to phy(Y). Successful mapping results in the ECM confirmation of Arbitration (Normal) to phy(X) to indicate that phy(Y) has been mapped and is in the process of requesting the egress path to be opened at which point the ECM indicates an Arb Won confirmation to phy(X). Phy(Y) only generates ECM messages is its receiver is requesting a path, and in this case it is not.

2.       If we assume Expander Phy [X] and Expander Phy [Y] has the following state transitions:


Expander phy [X]

Expander phy [Y] -

having higher priority Add frame received

XL0: Idle

XL0: Idle

XL0: Idle -> XL1:Request_Path

XL0: Idle

XL1:Request_Path to XL2:Request_Open

XL0: Idle

XL2:Request_Open to XL3:Open_Confirm_Wait

XL0: Idle -> XL1:Request_Path

In your example why does phy(X) transition out of the XL1 state to the XL2 state?
6.19.4.3 Transition XL1:Request_Path to XL2:Request_Open
This transition shall occur if:
a) a BREAK Received message has not been received; and
b) an Arb Won confirmation is received.
This transition shall include an OPEN Address Frame Received argument containing the arguments in the received OPEN Address Frame Received argument.

Phy(Y) remains in XL0:Idle, which indicates that the ECM has not mapped the path, and so there would not be an Arb Won indication.

Please add a bit more information to this example.


Regards
Tim.


Tim Symons | Storage Architect
Microchip Technology Inc.
Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>

[Microsemi_Subsidiary_Logo_4C_BLK (003)]


From: Lana Chan <lana at cadence.com<mailto:lana at cadence.com>>
Sent: Wednesday, May 15, 2019 3:34 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Cc: Deep Mehta <deep at cadence.com<mailto:deep at cadence.com>>; Gurudatta Mewundi <gmewundi at cadence.com<mailto:gmewundi at cadence.com>>; Tim Symons - C33374 <Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>>
Subject: [SAS]Resending Query regarding XL1 to XL5 state transition


External E-Mail


Hello,
Can you please clarify the following questions with respect to the XL state machine  - XL1 to XL5 state transition:


  1.  Per Figure K.18: Why does Expander phy (Y) not have "Arbitrating Normal confirmation" from ECM ?  Expander phy[X] has "Arbitrating Normal confirmation"
  2.  If we assume Expander Phy [X] and Expander Phy [Y] has the following state transitions:


Expander phy [X]

Expander phy [Y] -

having higher priority Add frame received

XL0: Idle

XL0: Idle

XL0: Idle -> XL1:Request_Path

XL0: Idle

XL1:Request_Path to XL2:Request_Open

XL0: Idle

XL2:Request_Open to XL3:Open_Confirm_Wait

XL0: Idle -> XL1:Request_Path



Our understanding is that if Phy[X] XL state machine is in XL3 and gives Phy Status (Partial Pathway) response to the ECM, the result is "b) Arbitrating (Wait on Partial)" confirmation for Phy[Y] XL1 state machine.  However per Section 6.19.4.4


6.19.4.4 Transition XL1:Request_Path to XL5:Forward_Open

This transition shall occur if a Forward Open indication is received and none of the following confirmations have been received:
a) Arbitrating (Normal);
b) Arbitrating (Waiting On Partial);
c) Arbitrating (Blocked On Partial);
d) Arbitrating (Waiting On Connection);
e) Arb Won;
f) Arb Lost;
g) Arb Reject (No Destination);
h) Arb Reject (Bad Destination);
i) Arb Reject (Connection Rate Not Supported);
j) Arb Reject (Zone Violation);
k) Arb Reject (Pathway Blocked); or
l) Arb Reject (Retry).





then Xl1 to XL5 state transition will never occur.  This also means that back-off reverse/retry will not occur (in XL6 state) for higher priority open address frames received from the expander Phy[Y].  Is our understanding correct?



Similarly (referencing Question (1)), if Expander phy[Y] XL state machine does have  "a) Arbitrating (Normal)" confirmation from ECM this would also block XL1 to XL5 state transition of Phy[Y]. Is this a valid interpretation?



Assuming our interpretation is valid, can we suggest the following instead:
If Request path source address argument and forward open indication destination sas address argument has same address/argument, then XL1 to XL5 state transition should not have condition a) to d) to check


Thank you in advance
Lana


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20190522/54819e47/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 32349 bytes
Desc: image002.jpg
URL: <http://www.t10.org/pipermail/t10/attachments/20190522/54819e47/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 5392 bytes
Desc: image003.jpg
URL: <http://www.t10.org/pipermail/t10/attachments/20190522/54819e47/attachment-0003.jpg>


More information about the T10 mailing list