Done Timeout vs. Credit Timeout Race

Day, Brian bday at lsil.com
Fri Mar 7 10:08:36 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <bday at lsil.com>
*
George...

I don't believe your statement that if A is not sending credit, then B is
going to 
cause a BREAK if the credit timeout occurs is correct.  B is going to send a
DONE(CREDIT TIMEOUT), not a BREAK (at least not initially).

Also, if A is not well-behaved in sending credit blocked, it's not
device A that has to suffer the consequences... but device B.
That's what I particularly do not like.

Brian

-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Friday, March 07, 2003 10:05 AM
To: Day, Brian
Cc: owner-t10 at t10.org; T10 Reflector (E-mail)
Subject: Re: Done Timeout vs. Credit Timeout Race






Brian,

It seems to me that the issue has little to do with DONE as DONE timer has
no relation to the credit timer. So it makes no difference whether a DONE
was sent by device A, if A is not sending credit then B is going to cause a
BREAK if the credit time-out occurs in any case.

If the issue here is that A cannot or does not want to send any more credit
then Bruce is correct that it is device is responsible for sending
credit-blocked or suffer the consequences.

>From SAS r03d section 7.15.7.8 SSP_RCM (receive frame credit monitor) state
machine:

"This state machine may send the Rx Credit Status (Blocked) parameter to
the SSP_TC1:Idle state indicating that no more credit is going to be sent
during this connection. After sending the Rx Credit Status (Blocked)
parameter to the SSP_TC1:Idle state, this state machine shall not send the
Rx Credit Status (Available) parameter to the SSP_TC1:Idle state for the
duration of the current connection. The Rx Credit Status (Blocked)
parameter should be sent to the SSP_TC1:Idle state when no further credit
is going to become available within a credit timeout (i.e., less than 1
ms)."

So, unless I am missing something, I don't see anything wrong with things
are currently defined.

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




 

                      "Day, Brian"

                      <bday at lsil.com>          To:       "T10 Reflector
(E-mail)" <t10 at t10.org>                                        
                      Sent by:                 cc:

                      owner-t10 at t10.org        Subject:  Done Timeout vs.
Credit Timeout Race                                          
 

 

                      03/06/2003 05:47

                      PM

 

 





* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <bday at lsil.com>
*

I believe some folks within LSI have thought of a race condition between
the
Done Timeout and the Credit Timout timers
in the SSP link layers.  Consider the case when a device (device A) has
issued DONE and has not extended credit to the
other device (device B) which still has frames to send.  Device A starts
its
1ms Done Timeout timer as soon as it sends
the DONE.  Device B will start its 1ms Credit Timeout timer after a new Tx
Frame request is received.

There's a good chance the Done Timeout will occur first, which results in a
BREAK being transmitted by device A.
When device B receives the BREAK, it filters on up through the layers and
ends up as a DELIVERY FAILURE for the frame
that was attempting to get transmitted.

That's doesn't seem like what was the intent for what was really a credit
timeout.

Am I missing something here?  Thanks....

Brian Day
LSI Logic


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