Should PS_REQ, PS_ACK be extended type?

Day, Brian Brian.Day at lsi.com
Wed Feb 18 09:46:17 PST 2009


* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsi.com>
*
Using a single primitive sequence type is definately not preferred, so that
we can tolerate bit errors on these primitives.  The particular case
discussed previous in a working group was a corrupted PS_ACK results in one
device going down into thee power management state, and the other seeing a
loss-of-sync and restarting the whole link reset sequence.  
SAS-2 had quite a few changes to make it more tolerant of bit errors and
prevent link reset sequences, so we don't want to take a backward step on
that philosophy.
Now, relative to the issue at hand about extended sequence type.  I agree
that since the receiver of the extended primitive sequence decodes each dword
as a primitive (refer to section 7.2.4.5 of the rev 15 draft SAS-2 spec), it
does mean that there are then three PS_ACK / PS_NAK Received messages
generated.  This can cause some theoretical race conditions in the spec state
machines I think.
So I suggest a different alternative would be to change these to redundant
primitives.  This eliminates the multiple PS_ACK / PS_NAK Received messages,
and still provides bit error tolerance.  This also lines up with our only
other request / response model (kinda) for primitives... the
BREAK/BREAK_REPLY handshake.
I'd encourage additional relflector discussion prior to the meeting, if there
are other concerns from other folks.
Other points relative to your original email though:
Re (a) below - There are rules on how often PS_REQ can be sent.  It's sent
one time on entry into the PS_Request state.  It's not sent again until
either getting a PS_ACK / PS_NAK, or the 1ms timer expires.
Re (b) below - Based on previous answer... there is not a condition where
there are multiple outstanding PS_REQs.
Brian Day
LSI Corporation
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Monday, February 09, 2009 9:18 AM
To: t10 at t10.org
Subject: Should PS_REQ, PS_ACK be extended type?
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I have received inquiries from folks looking at implementing the new PS_REQ
(x), PS_ACK, and PS_NAK primitives. They have pointed out that all other
cases in SAS where primitives use a request/ response model, the primitives
are the single type.
Use of the extended type primitive for request/ response cases causes a
number of implementation issues.
(a) How does the receiving end differentiate between a single PS_REQ (x) that
has idle dwords between them and possible multiple PS_REQ (x) primitives
where some of the duplicates are lost? There are no rules about how often
PS_REQ (x) can be sent.
(b) Similar race condition issues can arise when multiple PS_REQ (x) have
been sent and the sending end has to match up PS_NAK and PS_ACK responses
with the appropriate SP_REQ (x).
It has been suggested that it is simpler to use single type PS_REQ (x),
PS_NAK, and PS_ACK. If we are concerned about missing a request or response,
the function can be retried after the 1 msec timeout expires for a couple of
times before giving up. This would allow these primitives to use similar
generation/ detection logic as other request/ response primitives used in SAS
(this logic is often in hardware).
Please discuss this subject with appropraite hardware designers ar your
company. I ask that this subject be covered in the Protocol WG as part of
discussion of the intergration of proposals 08-015, 08-206, et. al.
*
* 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