SAS Expander question

Sheffield, Robert L robert.l.sheffield at intel.com
Fri Dec 10 16:35:33 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DF19.53617669
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dennis,
=20
Yes, I was just reading that, and it's not consistent with the =
reasoning
originally posed for the CLEAR AFFILIATION function. I think it ended =
up
as it is to discourage "stealing" an affiliation.
=20
Another option (assuming the STP target will accept a CLEAR AFFILIATION
only from the SMP initiator that corresponds to the STP initiator that
owns the affiliation) is that the affiliation can be cleared
immediately, even if there's a connection active. The STP target port
won't honor connection requests from other STP initiator ports anyway
until the current connection ends, so the sequence {CLEAR AFFILIATION,
use connection, CLOSE(NORMAL)} is equivalent to {use connection,
CLOSE(CLEAR AFFILIATION)}. I think that's consistent with existing text
anyway. The description of CLEAR AFFILIATION doesn't say anything about
whether there's a connection active or not. So, if taken literally, =
this
is the correct interpretation.=20
=20
I think the normal usage of CLEAR AFFILIATION as currently defined is =
to
handle the case where an STP initiator closes the connection
(CLOSE(NORMAL)), not knowing whether it really needs to maintain the
affiliation or not (or if the STP target closes the connection). If the
STP initiator subsequently decides it doesn't need the affiliation, it
can clear the affiliation using the SMP command without having to
reestablish an STP connection just to send the CLOSE(CLEAR =
AFFILIATION).
=20
Note, it doesn't say anywhere that an STP target port will reject a
CLEAR AFFILIATION received from an SMP initiator port other than the =
one
corresponding to the STP initiator port that currently holds an
affiliation, it just says that if CLEAR AFFILIATION is received from =
the
current owner, it shall clear the affiliation. Which presumably means
that it might not clear the affiliation if the request is received from
other than the current owner, but frankly, it doesn't say one way or =
the
other. It probably should (perhaps SMP FUNCTION FAILED if CLEAR
AFFILIATION is received from other than the current owner).
=20
Also, I did a bit more looking on the effect of the HARD RESET on
connections. For either STP or SSP connections, if the phy loses
dword-sync, the expander BREAKs the connection. A HARD RESET will cause
loss of dword-sync, so a HARD RESET will BREAK a connection. Other
conditions may break the connection as well, and can leave the
AFFILIATION in effect, perhaps with the current owner unable to clear
the affiliation. It does make sense that another SMP initiator could
know it needs to clear that affiliation and should issue an SMP PHY
CONTROL(HARD RESET) to clear outstanding SATA commands and clear the
affiliation.
=20
Bob

  _____ =20

From: Dennis Moore [mailto:dmoore at ix.netcom.com]=20
Sent: Friday, December 10, 2004 4:56 PM
To: Sheffield, Robert L
Cc: t10 at t10.org
Subject: Re: SAS Expander question


Bob,
 My interpretation of CLEAR AFFILIATION is that it is only valid from
the initiator that holds the affiliation, not from any other initiator
ports. Others must use HARD RESET to clear an affiliation left from
another initiator.
dmoore

----- Original Message -----=20
From: Sheffield, Robert L  =20
To: Marushak, Nathan   ; Elliott,
Robert (Server   Storage) ; t10 at t10.org
<mailto:t10 at t10.org> =20
Sent: Friday, December 10, 2004 12:17 PM
Subject: RE: SAS Expander question

The intent of the CLEAR AFFILIATION function was to preempt an
affiliation left over from a malfunctioning initiator (e.g. an =
initiator
establishes a connection and subsequently the initiator ceases to
function I_T Nexus Loss, either with the connection active or after the
connection is closed). At some point the connection closes, and another
initiator tries to get access. It can't because the affiliation is =
still
in-force. The new initiator (judging that it's been too long since it's
been able to access the STP port) issues an SMP CLEAR AFFILIATION  to
gain access.
=20
It's generally not a good idea to send this SMP command if there's an
active connection, and it's only for error recovery.
=20
I'm not sure there's much value in defining the behavior beyond it's
intended use, but it might be worth adding informative text about the
intended use, and leave any other usage as vendor-specific.
=20
Bob

  _____ =20

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Marushak, Nathan
Sent: Friday, December 10, 2004 7:59 AM
To: Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: SAS Expander question



Is it reasonable to reject the CLEAR AFFILIATION request indicating =
that
there is an ongoing connection and the initiator should retry later?  =
If
the device is hung, then the connection will eventually timeout.
Furthermore, it might be reasonable to define another PHY CONTROL
operation that is a heavier hammer version of CLEAR AFFILIATION (e.g.
RESET AFFILIATION, RESET STP TARGET, etc.).

=20

Nate

=20


  _____ =20


From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of =
Elliott,
Robert (Server Storage)
Sent: Thursday, December 09, 2004 6:51 PM
To: t10 at t10.org
Subject: RE: SAS Expander question

=20

The standard doesn't completely address this scenario today.

=20

One option is to return an error in response to the SMP CLEAR
AFFILIATION request - this could result in it never being accepted.  I
think it's better to require the expander accept the request and defer
clearing the affiliation until the connection is closed. =20

=20

The initiator could observe its CLEAR AFFILIATION accepted, but then =
see
the REPORT PHY SATA response (see 10.4.3.7) Affiliation Valid and
Affiliated STP Initiator SAS Address fields remain unchanged.  We could
define another REPORT PHY SATA response bit indicating "Clear
Affiliation Pending", or define a PHY CONTROL response that indicates
"SMP FUNCTION SCHEDULED" rather than "SMP FUNCTION ACCEPTED."

=20

The STP target port is modeled as a narrow port attached to the =
expander
function (see figure 41), so any connection requests that arrive at the
expander destined to the STP target port after the attempted CLEAR
AFFILIATION will still receive repeated AIP (WAITING ON CONNECTION)s
until the connection is closed.  Once the connection is closed, the
affiliation disappears and one of those waiting connection requests =
gets
through.

=20

If it's a wide STP target port supporting affiliations (see 7.17.5),
then the STP target port rejects new connection requests from the
connected STP initiator port with OPEN_REJECT (RETRY), and rejects
connection requests from other STP initiator ports with OPEN_REJECT =
(STP
RESOURCES BUSY). The time the clear affiliation takes place doesn't
matter.

=20

--=20
Rob Elliott, elliott at hp.com=20
Hewlett-Packard Industry Standard Server Storage Advanced Technology=20
https://ecardfile.com/id/RobElliott
<https://ecardfile.com/id/RobElliott> =20

=20

=20

=20


  _____ =20


From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Dennis
Moore
Sent: Thursday, December 09, 2004 1:43 PM
To: t10 at t10.org
Subject: SAS Expander question

What is the expected behavior of an expander when a wide port HBA opens
an STP connection through an expander to an attached SATA device and
then opens another connection to the expander's SMP target port and
clears the affiliation on the phy with the open connection to the SATA
device?

Thanks,

dmoore

=20


------_=_NextPart_001_01C4DF19.53617669
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 @font-face { 	font-family: Tahoma; } @page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; = } P.MsoNormal { 	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { 	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { 	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } A:link { 	COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { 	COLOR: blue; TEXT-DECORATION: underline } A:visited { 	COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { 	COLOR: blue; TEXT-DECORATION: underline } SPAN.EmailStyle17 { 	FONT-WEIGHT: normal; COLOR: maroon; FONT-STYLE: normal; FONT-FAMILY: = Arial; TEXT-DECORATION: none } DIV.Section1 { 	page: Section1 } Dennis,
  
 Yes, I was just reading that, and it's not = consistent with=20 the reasoning originally posed for the CLEAR AFFILIATION function. = I think=20 it ended up as it is to discourage "stealing" an=20 affiliation.
  
 Another option (assuming the STP target will = accept a CLEAR=20 AFFILIATION only from the SMP initiator that corresponds to the STP = initiator=20 that owns the affiliation) is that the affiliation can be cleared = immediately,=20 even if there's a connection active. The STP target port won't honor = connection=20 requests from other STP initiator ports anyway until the current = connection=20 ends, so the sequence {CLEAR AFFILIATION, use connection, = CLOSE(NORMAL)} is=20 equivalent to {use connection, CLOSE(CLEAR AFFILIATION)}. I think = that's=20 consistent with existing text anyway. The description of CLEAR = AFFILIATION=20 doesn't say anything about whether there's a connection active = or not.=20 So, if taken literally, this is the correct interpretation. = 
 
 I think the normal usage of CLEAR AFFILIATION = as currently=20 defined is to handle the case where an STP initiator closes the = connection=20 (CLOSE(NORMAL)), not knowing whether it really needs to maintain the = affiliation=20 or not (or if the STP target closes the connection). If the STP = initiator=20 subsequently decides it doesn't need the affiliation, it can clear the=20 affiliation using the SMP command without having to reestablish an STP=20 connection just to send the CLOSE(CLEAR = AFFILIATION).
  
 Note, it doesn't say anywhere that an STP = target port will=20 reject a CLEAR AFFILIATION received from an SMP initiator port other = than the=20 one corresponding to the STP initiator port that currently holds an = affiliation,=20 it just says that if CLEAR AFFILIATION is received from the current = owner, it=20 shall clear the affiliation. Which presumably means that it might not = clear the=20 affiliation if the request is received from other than the current = owner, but=20 frankly, it doesn't say one way or the other. It probably should = (perhaps SMP=20 FUNCTION FAILED if CLEAR AFFILIATION is received from other than the = current=20 owner).
  
 Also, I did a bit more looking on the effect = of the HARD=20 RESET on connections. For either STP or SSP connections, if the phy = loses=20 dword-sync, the expander BREAKs the connection. A HARD RESET will cause = loss of=20 dword-sync, so a HARD RESET will BREAK a connection. Other conditions = may break=20 the connection as well, and can leave the AFFILIATION in effect, = perhaps with=20 the current owner unable to clear the affiliation. It does make sense = that=20 another SMP initiator could know it needs to clear that affiliation and = should=20 issue an SMP PHY CONTROL(HARD RESET) to clear outstanding SATA commands = and=20 clear the affiliation.
  
 Bob
 

From: Dennis Moore = [mailto:dmoore at ix.netcom.com]=20 
Sent: Friday, December 10, 2004 4:56 PM
To: = Sheffield,=20 Robert L
Cc: t10 at t10.org
Subject: Re: SAS Expander=20 question


 
Bob,
  My interpretation of CLEAR = AFFILIATION is=20 that it is only valid from the initiator that holds the affiliation, = not from=20 any other initiator ports. Others must use HARD RESET to clear an = affiliation=20 left from another initiator.
 dmoore
 ----- Original Message ----- 
black">From:=20 Sheffield, Robert L = 
To: Marushak, Nathan ; Elliott, Robert = (Server=20 Storage) ; t10 at t10.org=20 
Sent: Friday, December 10, = 2004 12:17=20 PM
 Subject: RE: SAS Expander = question
 

The intent of the CLEAR AFFILIATION function = was to=20 preempt an affiliation left over from a malfunctioning initiator = (e.g. an=20 initiator establishes a connection and subsequently the initiator = ceases to=20 function I_T Nexus Loss, either with the connection active or after = the=20 connection is closed). At some point the connection closes, and = another=20 initiator tries to get access. It can't because the affiliation is = still=20 in-force. The new initiator (judging that it's been too long since = it's been=20 able to access the STP port) issues an SMP CLEAR AFFILIATION  to = gain=20 access.
  
 It's generally not a good idea to send this = SMP command=20 if there's an active connection, and it's only for error=20 recovery.
  
 I'm not sure there's much value in defining = the behavior=20 beyond it's intended use, but it might be worth adding informative = text about=20 the intended use, and leave any other usage as=20 vendor-specific.
  
 Bob

 From: owner-t10 at t10.org=20 [mailto:owner-t10 at t10.org] On Behalf Of Marushak,=20 Nathan
Sent: Friday, December 10, 2004 7:59 = AM
To:=20 Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: = SAS=20 Expander question


 
Is it = reasonable to=20 reject the CLEAR AFFILIATION request indicating that there is an = ongoing=20 connection and the initiator should retry later?  If the device = is hung,=20 then the connection will eventually timeout.  Furthermore, it = might be=20 reasonable to define another PHY CONTROL operation that is a heavier = hammer=20 version of CLEAR AFFILIATION (e.g. RESET AFFILIATION, RESET STP = TARGET,=20 etc.). 
On Behalf Of Elliott, Robert = (Server=20 Storage)
Sent: = Thursday,=20 December 09, 2004 6:51 PM
 = bold">To:=20 t10 at t10.org

   The = standard doesn't=20 completely address this scenario today.   One option = is=20 to return an error in response to the SMP CLEAR AFFILIATION = request -=20 this could result in it never being accepted.  I think it's = better to=20 require the expander accept the request and defer clearing the = affiliation=20 until the connection is closed.    The = initiator could=20 observe its CLEAR AFFILIATION accepted, but then see the REPORT PHY = SATA=20 response (see 10.4.3.7) Affiliation Valid and Affiliated STP = Initiator SAS=20 Address fields remain unchanged.  We could define another REPORT = PHY SATA=20 response bit indicating "Clear Affiliation Pending", or define a = PHY=20 CONTROL response that indicates "SMP FUNCTION SCHEDULED" rather than = "SMP=20 FUNCTION ACCEPTED."   The STP = target port=20 is modeled as a narrow port attached to the expander function (see = figure 41),=20 so any connection requests that arrive at the expander destined to = the STP=20 target port after the attempted CLEAR AFFILIATION will still receive = repeated=20 AIP (WAITING ON CONNECTION)s until the connection is closed.  = Once the=20 connection is closed, the affiliation disappears and one of those = waiting=20 connection requests gets through.   If it's a = wide STP=20 target port supporting affiliations (see 7.17.5), then the STP target = port=20 rejects new connection requests from the connected STP initiator port = with=20 OPEN_REJECT (RETRY), and rejects connection requests from other STP = initiator=20 ports with OPEN_REJECT (STP RESOURCES BUSY). The time the clear = affiliation=20 takes place doesn't matter.   -- = 

Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology 
https://ecardfile.com/id/Ro= bElliott=20    
   
On Behalf Of Dennis = Moore
Sent: Thursday, December 09, = 2004 1:43=20 PM
To:=20 t10 at t10.org
=20 bold">Subject: SAS=20 Expander question What is the expected = behavior of=20 an expander when a wide port HBA opens an STP connection through an = expander=20 to an attached SATA device and then opens another connection to the = expander's SMP target port and clears the affiliation on the phy = with the=20 open connection to the SATA device?
 

------_=_NextPart_001_01C4DF19.53617669--




More information about the T10 mailing list