SAS SSP DONE in response to CREDIT_BLOCKED when waiting for A CKs or NAKs

Sachidanandam, Kannan Kannan_Sachidanandam at maxtor.com
Mon Apr 28 19:07:17 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sachidanandam, Kannan" <Kannan_Sachidanandam at maxtor.com>
*


>The reason is that a Blocked is just an early indication of a credit
>timeout (i.e., if there was no blocked defined or used everything would
>work the same only slower).

As I see it, to the recipient a DONE(Credit Timeout) is
 indistinguishable from a DONE(CLOSE Connection). For this 
reason a valid response to a CREDIT BLOCKED primitive 
could also be DONE(Close Connection). 

The only purpose I can see for a DONE (Credit Timeout) 
primitive is to alert the other side that it has gone 
to sleep. In the case of receiving a Credit Blocked 
primitive the sender is obviously "alert" to the fact 
that it is not issuing RRDY's.

I am not arguing for a different implementation for 
arguments sake. I am merely trying to figure out if 
there is something I am missing here. Is there some 
required logging of the fact that a DONE (Credit Timeout) 
has been received. And furthermore does this imply that 
one side of the circuit was rudely interrupted mid-conversation
and needs to reconnect or does it imply that one side was 
interrupted rudely due to the other side dozing off and the 
sleeping side needs to take corrective action?

Is this primitive there to track errors?
Kannan

-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Monday, April 28, 2003 2:23 PM
To: Leshay, Bruce
Cc: owner-t10 at t10.org; 't10 at t10.org'
Subject: RE: SAS SSP DONE in response to CREDIT_BLOCKED when waiting for
A CKs or NAKs


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*




Bruce,

Yes that's has always been the case. Here is the paragraph that is being
replaced:

This transition shall occur and include a Credit Timeout argument if this
state was entered from the SSP_TF1:Connected_Idle state with a Transmit
Frame Balance Required argument or a Transmit Frame
Balance Not Required argument and the last Tx Credit Status message
received had an argument of Blocked.

Note that it states when you get a Tx Credit Status of Blocked you send a
Credit Timeout argument with the transition.
w
Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880




 

                      "Leshay, Bruce"

                      <Bruce_Leshay at max        To:       "'t10 at t10.org'"
<t10 at t10.org>                                                 
                      tor.com>                 cc:

                      Sent by:                 Subject:  RE: SAS SSP DONE in
response to CREDIT_BLOCKED when waiting for A       CKs   
                      owner-t10 at t10.org         or NAKs

 

 

                      04/28/2003 12:41

                      PM

 

 





* From the T10 Reflector (t10 at t10.org), posted by:
* "Leshay, Bruce" <Bruce_Leshay at maxtor.com>
*
George,

             I'm a little confused by your wording.
             If we receive Credit Blocked primitive, are you stating that
we should respond with a DONE(credit timeout)?.  That seems to be
what your new (b) below implies.

                                     Thanks,
                                     Bruce


-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Monday, April 28, 2003 11:20 AM
To: Elliott, Robert (Server Storage)
Cc: owner-t10 at t10.org; t10 at t10.org
Subject: Re: SAS SSP DONE in response to CREDIT_BLOCKED when waiting for
ACKs or NAKs


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*




Rob,
I agree with your point but your solution is not quite complete. The
a,b,c,d list just below the paragraph you modified has all the same
conditions you want it have if balanced is required before you can respond
to the blocked message. You forgot item d which is important because it
prevents a hang. Since both lists would be almost identical I suggest
modifying item b in the existing list to:

From:
b) the Credit Timeout timer expired before a Tx Credit Status message was
received with an argument of
Available;

to

b) the Credit Timeout timer expired before a Tx Credit Status message was
received with an argument of
Available or the last Tx Credit Status message received had an argument of
Blocked;

Now delete this paragraph:

This transition shall occur and include a Credit Timeout argument if this
state was entered from the
SSP_TF1:Connected_Idle state with a Transmit Frame Balance Required
argument or a Transmit Frame
Balance Not Required argument and the last Tx Credit Status message
received had an argument of Blocked.


Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880






                      "Elliott, Robert

                      (Server Storage)"        To:       <t10 at t10.org>

                      <Elliott at hp.com>         cc:

                      Sent by:                 Subject:  SAS SSP DONE in
response to CREDIT_BLOCKED when waiting for ACKs or NAKs
                      owner-t10 at t10.org





                      04/25/2003 06:18

                      PM









After an SSP phy sends DONE, it is allowed to continue sending RRDY, ACK,
NAK, and CREDIT_BLOCKED to keep the other side going.  There would be a
problem if both sides send DONE before all frames have been ACKed or NAKed
yet.


This is handled in SSP_TF2:Tx_Wait for both normal Close Connection
requests and Credit Timeout timer expiration; the state machine does not
jump to SSP_TF4:Indicate_DONE_Tx unless it got Tx Balance Status
(Balanced), meaning all outgoing frames have been ACKed or NAKed.


If SSP_TF decides to send a DONE because it received a CREDIT_BLOCKED
primitive, however, it does not check that its incoming ACKs or NAKs are
balanced.  Just because a CREDIT_BLOCKED arrived does not mean that an
ACK/NAK timeout has also happened and this phy should stop waiting for
them.  The SSP_TC logic that transmits CREDIT_BLOCKED doesn't consider
ACK/NAK status.  If both phys decide to send CREDIT_BLOCKED, the resulting
DONEs could cross before the ACKs and the ACKs could get lost amongst the
CLOSEs that follow.


I think adding a check for Tx Balance Status (Balanced) to the third
paragraph fixes this.


Current:
7.16.7.6.3.3 Transition SSP_TF2:Tx_Wait to SSP_TF4:Indicate_DONE_Tx
This transition shall occur and include an ACK/NAK Timeout argument if an
ACK/NAK Timeout message is
received.


This transition shall occur and include a Close Connection argument if this
state was entered from the
SSP_TF1:Connected_Idle state with an argument of Close Connection and the
last Tx Balance Status
message received had an argument of Balanced.


This transition shall occur and include a Credit Timeout argument if this
state was entered from the
SSP_TF1:Connected_Idle state with a Transmit Frame Balance Required
argument or a Transmit Frame
Balance Not Required argument and the last Tx Credit Status message
received had an argument of Blocked.


This transition shall occur and include a Credit Timeout argument if:
a) this state was entered from the SSP_TF1:Connected_Idle state with a
Transmit Frame Balance
Required argument or a Transmit Frame Balance Not Required argument;
b) the Credit Timeout timer expired before a Tx Credit Status message was
received with an argument of
Available; and
c) a Tx Balance Status message was received with an argument of Balanced
(i.e., the Credit Timeout
argument shall not be included in this transition for this reason unless
the ACK/NAK count is
balanced); and
d) an ACK/NAK Timeout message was not received.





to (new text in <<< >>>):
...
This transition shall occur and include a Credit Timeout argument if:
a) this state was entered from the SSP_TF1:Connected_Idle state with a
Transmit Frame Balance
Required argument or a Transmit Frame Balance Not Required argument;
b) the last Tx Credit Status message received had an argument of Blocked;
and
<<< c) the last Tx Balance Status message received had an argument of
Balanced.  >>>
...





--
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
*
* 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
*
* 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