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

George Penokie gop at us.ibm.com
Tue Apr 29 08:39:35 PDT 2003


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




Kannan,

First I have to assume you mean DONE (Normal) when you state DONE (CLOSE
Connection) in your note. There is a DONE Received (CLOSE Connection) but
that is a confirmation sent to up to the application layer. With that
assumption:
Your statement : "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)."
Is not correct. There is a definite distinction between a DONE (Normal) and
a DONE (Credit Timeout). A DONE (Normal) indicates a normal completion and
that the transmitter has no more SSP frames to transmit. A DONE (Credit
Timeout) indicates the transmitter still has SSP frames to transmit, but
did not
receive an RRDY granting frame credit within 1 ms or that a CREDIT BLOCKED
occurred. Because their are two different meanings you cannot return a
DONE(Normal) if you receive a CREDIT BLOCKED and be compliant with the
standard.

What the receiving device does with the DONE (Credit Timeout) and the DONE
(Normal) is up to the receiver and not defined in the standard. But
whatever is done the reason for generating the different DONE's must be
consistent across all devices.

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





                                                                                                                                            
                      "Sachidanandam,                                                                                                       
                      Kannan"                       To:       George Penokie/Rochester/IBM at IBMUS, "Leshay, Bruce" <Bruce_Leshay at maxtor.com> 
                      <Kannan_Sachidanandam@        cc:       owner-t10 at t10.org, "'t10 at t10.org'" <t10 at t10.org>                              
                      maxtor.com>                   Subject:  RE: SAS SSP DONE in response to CREDIT_BLOCKED when waiting for A             
                                                     CKs or NAKs                                                                            
                      04/28/2003 09:07 PM                                                                                                   
                                                                                                                                            
                                                                                                                                            






>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






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