[T10] SPL - Question on BREAK during SSP frame transmission

Tim Symons tim.symons at microsemi.com
Mon Sep 26 10:47:54 PDT 2016


Srinivas,

You have two active conditions and so both messages are required ('shall' statements are mandatory) per the standard specification:

a)       Break response event

b)      Incomplete transfer - retry required.

Tim.

From: Srinivas Vijayaragavan [mailto:Srinivas.Vijayaragavan at synopsys.com]
Sent: Thursday, September 22, 2016 2:47 AM
To: Tim Symons <tim.symons at microsemi.com>; t10 at t10.org
Subject: RE: SPL - Question on BREAK during SSP frame transmission

EXTERNAL EMAIL
Hi Tim,

Thank you for your response.

The sections 7.2.2.3.5, 7.2.2.3.6 & 7.2.2.3.7 consider the "Retry Open" & "Unable to Connect" messages for establishing an I_T nexus loss event. However in my case, the retry message is a "Retry Frame" message and not "Retry Open". I could not find any text in the specification which links "Retry Frame" message to I_T nexus loss event (or) to be ignored when connection closes due to BREAKs.

In my case:

-          a SSP connection is successfully opened.

-          The Port layer sends a Tx Frame request to link layer. SSP link layer begins frame transmission.

-          BREAK is received before the SSP frame is completely transmitted. Link layer does not send a "Frame Transmitted" confirmation to port layer.

-          SL_CC3:Connected state sends a "Connection Closed (Break Received)" to port layer

-          SL_CC0 then sends a "Connection closed (Transition to Idle)" upon state entry

This "Connection closed (Transition to Idle)" confirmation leads to both "Transmission Status (Break Received)" & "Retry Frame" messages per 7.2.3.4.1

7.2.3.4.1 PL_PM3:Connected state description
If this state receives a Connection Closed (Transition to Idle) confirmation after receiving one of the following:
a) a Connection Closed (Break Received) confirmation; or
b) a Connection Closed (Break Requested) confirmation,
then this state shall send a Transmission Status (Break Received) confirmation to the transport layer.
...  ...  ...
If this state receives a Connection Closed (Normal) confirmation, a Connection Closed (Transition to Idle)
confirmation, or a Phy Disabled confirmation after sending a Tx Frame request but before receiving a Frame
Transmitted confirmation, then this state shall send a Retry Frame message to the PL_OC state machine.


Is it expected to have both these messages generated in this case?


Thanks,
Srinivas


From: Tim Symons [mailto:tim.symons at microsemi.com]
Sent: Thursday, September 22, 2016 4:26 AM
To: t10 at t10.org<mailto:t10 at t10.org>
Cc: Srinivas Vijayaragavan <Srinivas.Vijayaragavan at synopsys.com<mailto:Srinivas.Vijayaragavan at synopsys.com>>
Subject: RE: SPL - Question on BREAK during SSP frame transmission

Srinivas,
There are a number of events within the state machines when a BREAK event is initiated.

The 'Retry Frame' event is a legacy behavior from SAS 1.0 and text is included to ensure benign behavior.
See 6.18.4.7 SL_CC5:BreakWait state
"NOTE 36 - Some SAS logical phys compliant with SAS-1.1 send a Transmit OPEN_REJECT (Retry)
message to the SL transmitter in response to each OPEN Address Frame Received message received while
in this state."

When in the SL_CC3: Connected state (6.18.4.5):
"If a Request Break message is received and a BREAK Received message has not been received, then this state shall send a Connection Closed (Break Requested) confirmation to the port layer.
If a BREAK Received message is received, then this state shall send a Connection Closed (Break Received) confirmation to the port layer."
And this causes a transition to either "SL_CC5:BreakWait" or "SL_CC6:Break"
In either of these states a BREAK response is transmitted and the link layer is waiting for break response confirmation before going idle.

When the SL_CC states transition to SL_CC0:Idle state (see 6.18.4.2)
Upon entry into this state, this state shall:
a) send an Enable Disable SSP (Disable) message to the SSP link layer state machines;
b) send an Enable Disable SMP (Disable) message to the SMP link layer state machines;
c) send an Enable Disable STP (Disable) message to the STP link layer state machines;
d) send an Idle State Condition (Active) message to the SL_P_S link layer state machine (see 6.14.4)
and SL_P_C link layer state machine (see 6.14.5);
e) initialize and start the Idle timer;
f) send a Connection Closed (Transition to Idle) confirmation to the port layer; and
g) send an Enable APTA confirmation to the management application layer.

The  Connection Closed (Transition to idle) message
, no frames are processed and so any spurious Frame Retry events will be ignored.

When PL_PM3 receives a
"...
c) a Connection Closed (Break Requested) confirmation;
d) a Connection Closed (Break Received) confirmation; or
e) a Connection Closed (Transition to Idle) confirmation,
then this state shall send a Connection Closed message to the PL_OC state machine including the argument
received with the confirmation."

The Connection closed message for causes PL_OC to suspend frame transmissions until the state receives Connection Closed (transmission to idle):

PL_OC:  PL2_OC:Overall_control state connection management (7.2.2.9)
If this state receives one of the following:
a) a Connection Closed (Close Timeout) message;
b) a Connection Closed (Break Requested) message; or
c) a Connection Closed (Break Received) message,
then this state shall not send a Tx Open or Tx Frame message to the PL_PM state machine that sent the message until this state receives a Connection Closed (Transition to Idle) message from that PL_PM state machine.

In the case of a retry event:

PL_OC:  PL2_OC:Overall_control state connection management (7.2.2.9)
If this state receives a Connection Closed (Normal) message or a Connection Closed (Transition to Idle)
message indicating that a connection with a destination SAS address is no longer open, and this state has
pending Tx Open messages, then this state may send a Tx Open message to the PL_PM state machine that sent the Connection Closed message.

Since the connection has already been established any retry event will trigger an I_T nexus loss event:
PL2_OC2:Overall_Control state connection established  state receives a retry request then an I_T_nexus loss event occurs (see 7.2.2.3.6 and 7.2.2.3.3.7)


I hope this helps to clarify your enquiry.

Regards
Tim Symons



From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> [mailto:t10-bounces at t10.org] On Behalf Of Srinivas Vijayaragavan
Sent: Thursday, September 15, 2016 3:55 AM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: [T10] SPL - Question on BREAK during SSP frame transmission

EXTERNAL EMAIL
Hi,

I have a question on the expected PL_PM behavior when a SSP frame transmission is interrupted by BREAKs.

The following lines are mentioned in the SPL(spl4r09) specification  -

7.2.3.4 PL_PM3:Connected state
...
If this state receives a Connection Closed (Transition to Idle) confirmation after receiving one of the following:
a) a Connection Closed (Break Received) confirmation; or
b) a Connection Closed (Break Requested) confirmation,
then this state shall send a Transmission Status (Break Received) confirmation to the transport layer.

...
If this state receives a Connection Closed (Normal) confirmation, a Connection Closed (Transition to Idle)
confirmation, or a Phy Disabled confirmation after sending a Tx Frame request but before receiving a Frame
Transmitted confirmation, then this state shall send a Retry Frame message to the PL_OC state machine.

=============================================================

I encountered a scenario where the link layer receives BREAKs after it has transmitted SOF and before EOF could be transmitted. The SL_CC state machine sends a "Connection Closed (Break Received)" confirmation first followed by a "Connection Closed (Transition to Idle)".

Both conditions mentioned above are satisfied

1)      "Connection Closed (Transition to Idle)" is received after "Connection Closed (Break Received)"

2)      "Connection Closed (Transition to Idle)" is received after sending a Tx Frame request but before receiving a Frame Transmitted confirmation

I am wondering how the same frame can have a "Transmission Status" going to transport layer and a "Retry Frame" message going to the PL_OC. The "Transmission Status (Break Received)" will cause the ST_TTS state machine to terminate the transfer; but "Retry Frame" message will cause PL_OC to retry the frame.


Am I missing something here?


Thanks,
Srinivas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20160926/245eadac/attachment.html>


More information about the T10 mailing list