From: "Elliott, Robert (Server Storage)" <Elliott@hp.com>
To: "t10@t10.org" <t10@t10.org>
Date: Thu, 23 Oct 2008 14:25:24 +0000
Subject: RE: Elasticity buffer and training
X-Message-Number: 9229
Formatted message: HTML-formatted message

Why are training pattern dwords going into the elasticity buffer?  They are
only received by the SP state machine, which is in the phy layer.  The
elasticity buffer and the concept of ALIGNs for physical link rate tolerance
matching are in place for the link layer, and only start being used after the
phy reset sequence completes (which is the OOB sequence + speed negotiation
sequence + multiplexing sequence), which is followed by the initialization
sequence.
________________________________
From: Bill.Martin@Emulex.Com [mailto:Bill.Martin@Emulex.Com]
Sent: Thursday, October 23, 2008 12:31 AM
To: Elliott, Robert (Server Storage); t10@t10.org
Subject: Elasticity buffer and training
In looking at a combination of figure 35 and figure 180 in SAS2r14f, there is
a potential that the first valid address frame is lost after initialization.
During training, there are no ALIGNS inserted for physical link rate
tolerance matching.  This means that there can be many more dwords received
than what the elasticity buffer can accommodate for a clock skew mismatch. 
At the end of training, there are three identify frames sent and then a
address frame may be sent.  All of these occur in less than the 512 bytes
that determine when ALIGN for clock skew management shall be inserted.	The
case exists where the elasticity buffer is capable of holding the three
IDENTIFY address frames but then overflows during the first Address frame for
a destination phy.
I do not have a proposed fix for this, but unless I have missed something,
this needs to be addressed.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com