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

Lana Chan lana at cadence.com
Fri May 17 11:12:20 PDT 2019


Hi Tim,
Thank you as always.  We still have some doubts 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 01D50CA1.626BFD50]

Let us know your thought on this.

Thanks
Lana


From: Tim.Symons at microchip.com <Tim.Symons at microchip.com>
Sent: Thursday, May 16, 2019 5:27 PM
To: Lana Chan <lana at cadence.com>; t10 at t10.org
Cc: Deep Mehta <deep at cadence.com>; Gurudatta Mewundi <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.


  1.  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/20190517/0eae153a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 60205 bytes
Desc: image002.jpg
URL: <http://www.t10.org/pipermail/t10/attachments/20190517/0eae153a/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/20190517/0eae153a/attachment-0003.jpg>


More information about the T10 mailing list