Persistent Connection Timeout Timer

Penokie, George George.Penokie at lsi.com
Mon Jan 21 12:41:43 PST 2013


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1301210_f.htm">HTML-formatted message</a>

Pooja,
Yes, you are correct, the Persistent Connection Timeout timer should suspend
during frame receiving traffic. I will write a proposal to fix that.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pooja Gupta
Sent: Friday, January 18, 2013 11:13 PM
To: t10 at t10.org
Subject: FW: Persistent Connection Timeout Timer
Hi,
I have a concern about Persistent Connection Timeout Timer.
Below is the snippet from Draft  T10/12-251 revision 8:
--------------------- Page# 
37---------------------------------------------------------------------------
--------------------------------------------
6.18.9.3.4 SSP_EM2:Manage
This state:
a) requests the SSP transmitter send EXTEND_CONNECTION; and
b) monitors the receipt of EXTEND_CONNECTION.
Upon entry into this state, this state shall initialize and start the
Transmit Extend Connection timer.
If this state receives:
a) a Frame Transmitted message, then this state shall initialize and start
the Transmit Extend
Connection timer; or
b) a Transmitting Frame message, then this state shall stop the Transmit
Extend Connection timer.
If the Transmit Extend Connection timer expires, then this state shall:
a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and
b) after receiving an EXTEND_CONNECTION transmitted message, initialize and
start the Transmit
Extend Connection timer.
--------------------- Page#
37---------------------------------------------------------------------------
--------------------------------------------
So, For the transmission of the EXTEND CONNECTION Primitive, it takes care of
the following:
1.	 Upon entry into SSP_EM2: Manage state, SSP Phy shall initialize and
start the Transmit Extend  Connection timer
2.	 Transmit Extend Connection timer runs when there is nothing to do,
And when timer expires, EXTEND_CONNECTION primitive is transmitted
3.	 If there is a request to transmit a Frame, it stops the timer until
the frame is completely transmitted. It initializes and resumes the timer
upon receipt of Frame Transmitted message.
But it does not take care of the Receiver side of  EXTEND CONNECTION
Primitive. Please see the snippet below:
--------------------- Page# 
37,38------------------------------------------------------------------------
-----------------------------------------------
If this state receives an EXTEND_CONNECTION Received message, then this state
shall initialize and start
the Persistent Connection Timeout timer.
If the Persistent Connection Timeout timer expires, then this state shall
send a Persistent Connection
Established (Disabled) confirmation to the port layer.
--------------------- Page#  37,
38---------------------------------------------------------------------------
--------------------------------------------
Here SSP_EM2:Manage state nowhere accommodates the change in the Persistent
Connection Timeout timer state when receiving the frame.
Consider a situation where the Transmitter has long traffic of Back to Back
Frames to transmit. In that case it will not send the EXTEND_CONNECTION
Primitive(refer to #3 above).
Eventually, the Persistent Connection Timeout Timer will expire and will
force the Receiver to send a Persistent Connection Established (Disabled)
confirmation to the port layer.
So, is it correct, that the Persistent Connection Timeout time keeps on
running, waiting for EXTEND_CONNECTION primitive, even when it is receiving a
Frame?
Please share your opinion on this.
Regards
Pooja



More information about the T10 mailing list