[T10] Request for clarification on CREDIT_BLOCK received message condition for SSP transmitter

Lana Chan lana at cadence.com
Sun Oct 28 17:08:06 PDT 2018


Thank you Tim for the clarifications
Regards
Lana


From: Tim.Symons at microchip.com <Tim.Symons at microchip.com>
Sent: Friday, October 26, 2018 4:54 PM
To: Lana Chan <lana at cadence.com>; t10 at t10.org
Subject: RE: [T10] Request for clarification on CREDIT_BLOCK received message condition for SSP transmitter

EXTERNAL MAIL
Lana,
Here are some answers to your enquiry.

Question 1: It seems that indirectly, all three conditions 1) CREDIT_BLOCKED Received, 2) EXTEND_CLOSE_CONNECTION received and 3) RRDY_CLOSE are received handled same way.
Considering that, how does the SSP transmitter differentiate between RRDY_CLOSE received condition and CREDIT_BLOCK received condition in terms of sending response?

Answer 1:  Both messages cause the SSP_TCM state to repeatedly send a Begin Close message to the SSP_TF1:Connected_Idle state.

Question 2: What if transmit SSP frame credit is available (refer below example/scenario) and CREDIT_BLOCK received primitive is received ? In this case, should it send Tx Credit Status (Blocked) or Tx Credit Status (Available) to SSP_TF2 state ?

Answer 2:  When SSP-TCM state receives CREDIT BLOCKED Received message, then it repeatedly sends a Begin Close message to the SSP_TF1:Connected_Idle state. No other messages are sent to the SSP_TF2 state as no new credits are available for that connection, and the connection needs to close.

Question 3: How do we differentiate CREDIT_BLOCKED received condition response with DONE_NORMAL or DONE_CREDIT_TIMEOUT ?
Shall it be interpreted as below ?

  1.  If transmitter has received CREDIT_BLOCK and it has some (> zero) transmit CREDITs available to transfer, but no pending frames to be transmitted then transmitter will respond with DONE_NORMAL
  2.  If transmitter has received CREDIT_BLOCK and it has NO TRANSMIT CREDIT available to transfer, but have/have-not pending frames to be transmitted then transmitter will respond with DONE_CREDIT_TIMEOUT

Answer 3:  Correct. Table 139 in section 6.2.7.3 describes the conditions.

Question 4:

  *   What should be the response of initiator to target , considering Initiator has still 1 more frame pending to transmit ?
     *   Initiator should Immediately close the on-going connection by DONE_CLOSE (as CREDIT_BLOCKED received is treated same as RRDY_CLOSE received message) OR
     *   Initiator should transmit the 4th pending frame and then close connection by DONE_NORMAL ? OR
     *   Initiator should Immediately close the on-going connection by DONE_CREDIT_TIMEOUT transmission ?

Answer 4:  The initiator has received 6 credits and used only 3 of them. In this scenario it still has credit to send the 4th SSP frame and close the connection reporting DONE (NORMAL).

Question 5:

  *   Does above statement of transmitting CREDIT_BLOCK hold true, even when Persistent connection are not supported(*) and not established so. ?
* PERSISTENT_CAPABLE bit in IDENTIFICATION frame is 0 for Initiator as well as target.

Answer 5:  Yes, The conditions in the list all describe the case when a persistent connection is NOT open, either because it's not supported or it is supported by not established are all the same.


Regards
Tim.


Tim Symons | Storage Architect
Microsemi Corporation
Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>

[Microsemi_Subsidiary_Logo_4C_BLK (003)]


From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Lana Chan
Sent: Tuesday, October 16, 2018 3:56 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: [T10] Request for clarification on CREDIT_BLOCK received message condition for SSP transmitter

EXTERNAL EMAIL
Specification reference : SPL-5r06

6.20.9.4 SSP_TCM (transmit frame credit monitor) state machine


  *   The CREDIT_BLOCKED Received message indicates that transmit SSP frame credit is blocked. After receiving a CREDIT_BLOCKED Received message, this state machine may ignore additional RRDY Received messages until it receives a Request Close message or a Request Break message.


  *   This state machine shall handle an EXTEND_CONNECTION Received (Close) message as if a CREDIT_BLOCKED Received message was received.


  *   The RRDY Received (Close) message indicates:

     *   that transmit SSP frame credit is available; and
     *   this state machine shall handle that RRDY Received (Close) message as if a CREDIT_BLOCKED Received message was received.


  *   If this state receives an RRDY Received (Close) message or an EXTEND_CONNECTION Received (Close) message, then this state shall repeatedly send a Begin Close message to the SSP_TF1:Connected_Idle state.

Question 1: It seems that indirectly, all three conditions 1) CREDIT_BLOCKED Received, 2) EXTEND_CLOSE_CONNECTION received and 3) RRDY_CLOSE are received handled same way.
Considering that, how does the SSP transmitter differentiate between RRDY_CLOSE received condition and CREDIT_BLOCK received condition in terms of sending response?


  *   While transmit SSP frame credit is not available and transmit SSP frame credit is not blocked, this state machine shall repeatedly send the Tx Credit Status (Not Available) message to the SSP_TF2:Tx_Wait state.


  *   While transmit SSP frame credit is not available and transmit SSP frame credit is blocked, this state machine shall repeatedly send the Tx Credit Status (Blocked) message to the SSP_TF2:Tx_Wait state.

Question 2: What if transmit SSP frame credit is available (refer below example/scenario) and CREDIT_BLOCK received primitive is received ? In this case, should it send Tx Credit Status (Blocked) or Tx Credit Status (Available) to SSP_TF2 state ?


6.20.8 Closing an SSP connection

If the transmitter has no more SSP frames to transmit and receives a CREDIT_BLOCKED, then it may transmit either DONE (NORMAL) or DONE (CREDIT TIMEOUT).

Question 3: How do we differentiate CREDIT_BLOCKED received condition response with DONE_NORMAL or DONE_CREDIT_TIMEOUT ?
Shall it be interpreted as below ?

  1.  If transmitter has received CREDIT_BLOCK and it has some (> zero) transmit CREDITs available to transfer, but no pending frames to be transmitted then transmitter will respond with DONE_NORMAL
  2.  If transmitter has received CREDIT_BLOCK and it has NO TRANSMIT CREDIT available to transfer, but have/have-not pending frames to be transmitted then transmitter will respond with DONE_CREDIT_TIMEOUT

Example/Scenario :
===============

  1.  Initiator has opened the connection with target, and after accepting the connection Target send 6 RRDY to Initiator
  2.  Initiator has 4 SSP frames to transmit in this connection
  3.  While sending 3rd SSP frame, Initiator received CREDIT_BLOCK primitive from Target (due to Rx Credit Control (Blocked) condition at target)

Question 4:

  *   What should be the response of initiator to target , considering Initiator has still 1 more frame pending to transmit ?

     *   Initiator should Immediately close the on-going connection by DONE_CLOSE (as CREDIT_BLOCKED received is treated same as RRDY_CLOSE received message) OR
     *   Initiator should transmit the 4th pending frame and then close connection by DONE_NORMAL ? OR
     *   Initiator should Immediately close the on-going connection by DONE_CREDIT_TIMEOUT transmission ?


6.20.4 SSP flow control


  *   If SSP frame credit is nonzero and a persistent connection:

     *   has not been established;
     *   was established and has been disabled (see 6.20.9.12.4); or
     *   has been established and the Persistent Connection Timeout timer (see table 196) has expired,
             then SSP phys that are going to be unable to provide additional SSP frame credit for 1 ms, even if they receive frames per the existing SSP frame credit, may transmit CREDIT_BLOCKED.

Question 5:

  *   Does above statement of transmitting CREDIT_BLOCK hold true, even when Persistent connection are not supported(*) and not established so. ?
* PERSISTENT_CAPABLE bit in IDENTIFICATION frame is 0 for Initiator as well as target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20181029/d19f4ca8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5390 bytes
Desc: image001.jpg
URL: <http://www.t10.org/pipermail/t10/attachments/20181029/d19f4ca8/attachment.jpg>


More information about the T10 mailing list