Questions on CREDIT_BLOCKED

Evans, Mark Mark_Evans at maxtor.com
Tue Apr 27 08:48:14 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Evans, Mark" <Mark_Evans at maxtor.com>
*
Hi Rob,

I think that, by not prohibiting the behavior, the standard strongly implies
that an SSP port may use the RRDY credits that it's already received even
after receiving a CREDIT_BLOCKED.  I've looked at all of the occurrences of
CREDIT_BLOCKED in the standard, and I think you're oversimplifying the issue
by saying that only one thing would need to be changed to define behavior
"A".  Since none of the other places in the standard say anything about
"...and once you receive a CREDIT_BLOCKED you shall not use any of the RRDYs
you've already received...", the strong implication is that the previously
received RRDY credits MAY be used.

I don't have a major problem with your item 1 ("CREDIT_BLOCKED shall not be
sent while previous RRDY credits are still available for use."), so long as
you don't force the recipient to interpret this as an error condition.
However, I'm not sure what problem you're trying to solve with this, and I
do think that what you propose is more restrictive than it needs to be.  If
an SSP port sent one or more RRDYs, then it had allocated the buffer space
for the frames.  If it's out of buffer space and doesn't expect to have more
soon, it could immediately send CREDIT_BLOCKED allowing the recipient to
send a DONE immediately after the last frame saving a little time in closing
the connection.

Anyhow, I expect we'll talk more about this next week.

Regards,

Mark Evans
Maxtor Corporation

 -----Original Message-----
From:   Elliott, Robert (Server Storage) [mailto:elliott at hp.com] 
Sent: Monday, April 26, 2004 1:19 PM
To: t10 at t10.org
Subject:  RE: Questions on CREDIT_BLOCKED

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*
That's sentence is in the introduction to the issue, not the proposed
text.  That question one of the reasons for the proposal :-) 

B) matches the current state machine wording (in one place).    If the
group wants it to mean A) then:

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

needs to change to:
When transmit frame credit is blocked, this state machine shall send the
Tx Credit Status (Credit Blocked) message to the SSP_TF2:Tx_Wait state.


-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 


-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Leon
Krantz
Sent: Monday, April 26, 2004 1:58 PM
To: t10 at t10.org
Subject: Questions on CREDIT_BLOCKED


Ref: 04-115r1 SAS-1.1 Miscellaneous changes
 
 
 
The statement "If a receiver sees CREDIT_BLOCKED at unexpected times, it
shall honor it." means:
 
A: The sender ignores all the outstanding RRDYs and stops sending
frames.
 
B: The sender continue sending frames as long as credit is available,
then assumes there will be no more RRDYs during this connection.
 
Arie Krantz
QLogic Corporation
 
*
* 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