SSP DONE policy

Evans, Mark Mark_Evans at maxtor.com
Mon Apr 7 13:14:48 PDT 2003


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

I received a question that I haven't been able to completely reconcile.  The
question is, "What happened to the rules about who was supposed to send a
DONE when?"  I first went back to my original proposal for this that was
accepted (02-201r3), and then looked in good old rev 3f.  There have been
lots of changes since the rev for which my document was proposed (00c), and
even the clauses I was recommending for change are no longer there.  I think
there need to be some minor editorial corrections, one way or the other.

The essence of my proposal was, "When a source SSP device has no frames to
send, it shall send a DONE.  When a destination SSP device has no frames to
send, it may wait for a vendor-specific period of time, and then shall send
a DONE."  It seems to me that all of the decisions about this occur in the
port layer

The first place that I think needs adjustment is the first sentence in the
second paragraph in 7.16.2 Full duplex, "When a connection is open and an
SSP phy has no more SSP frames to transmit on that connection, it shall
transmit DONE to start closing the connection."  Well, yes, sooner or later
it shall send a DONE, but the implication is that the DONE shall be sent
immediately based on information the phy doesn't have.  I recommend that
this be changed to something like, "When a connection is open and an SSP phy
has no more SSP frames to transmit on that connection, it transmits a DONE
to start closing the connection (see 8.2.2.3.5)."  I think the actual
sequence would be that the link layer would send a DONE (NORMAL) after
receiving a Close Connection from the port layer, but this recommended
change still works as it makes things more vague, but NOT incorrect.

Then, in 7.16.6 Closing an SSP connection, the first paragraph reads, "DONE
shall be exchanged prior to closing an SSP connection."  The second
paragraph reads, "When a source SSP phy has no SSP frames to transmit, it
should transmit DONE (NORMAL). When a destination SSP phy has no SSP frames
to transmit, it may wait for a vendor-specific period of time, and then
shall transmit DONE (NORMAL). There are several versions of the DONE
primitive indicating additional information about why the SSP connection is
being closed:" followed by a bulletted list.

I recomment that these be changed to, "DONE shall be exchanged prior to
closing an SSP connection (see 8.2.2.3.5). There are several versions of the
DONE primitive indicating additional information about why the SSP
connection is being closed:" followed by the bulletted list.

Based on the above, there need to be more words in 8.2.2.3.5
PL_OC2:Overall_Control state connection management.  The last paragraph in
the clause reads, "If this state has no pending Tx Frame messages for a
destination SAS address with which a PL_PM state machine has established a
connection or this state has received a Disable Tx Frame message from a
PL_PM state machine, then this state should send a Close Connection message
to the PL_PM state machine."  This needs to be expanded.

I recomment that the paragraph be changed to something like:

"If this state is in an SSP port, has no pending Tx Frame messages for a
destination SAS address with which a PL_PM state machine has established a
connection, and the connection was established by a message from this state,
then this state shall send a Close Connection message to the PL_PM state
machine.  If this state is in an SSP port, has no pending Tx Frame messages
for a destination SAS address with which a PL_PM state machine has
established a connection, and the connection was established by the
destination, then this state may wait a vendor specific time and then shall
send a Close Connection message to the PL_PM state machine.  If this state
has received a Disable Tx Frame message from a PL_PM state machine, then
this state should send a Close Connection message to the PL_PM state
machine."

Please let me know what you think about this.

Regards,

Mark Evans
Maxtor Corporation
408-894-5310
*
* 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