SAS NOTIFY (RESERVED 2) encoding problem and arbitration fairness issue for an absurd case

Elliott, Robert (Server Storage) Elliott at hp.com
Mon Mar 17 11:05:56 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C2ECB8.3D5F859F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You're right - generating OPEN_ACCEPT would be the "lose" case not the
"win" case. =20
=20
To handle both sides requestingthe same connection rate we could add
this rule: if the AWT, source SAS address, and connection rate are the
same, the SAS port shall choose one request as the winner and one as =
the
loser.  Since it's the same port on both sides, it should be able to
solve its own problem.
=20
That could be applied to just AWT and source SAS address without
including the connection rate, if that seems simpler.
=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


-----Original Message-----
From: Day, Brian [mailto:bday at lsil.com]=20
Sent: Monday, March 17, 2003 10:56 AM
To: Elliott, Robert (Server Storage); T10 Reflector (E-mail)
Subject: RE: SAS NOTIFY (RESERVED 2) encoding problem and arbitration
fairness issue for an absurd case


Rob...
=20
For item #2, isn't a more likely absurd case is when the link rates are
the same for both ports.  In either case, if both ports assume they =
win,
then they will both wait for (not generate?) an OPEN_ACCEPT, which will
result in an open timeout.  This could happen for every connection
request.  I don't think adding 3) helps this.
=20
Brian Day
LSI Logic=20

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Friday, March 14, 2003 5:35 PM
To: t10 at t10.org
Subject: SAS NOTIFY (RESERVED 2) encoding problem and arbitration
fairness issue for an absurd case



We noticed two problems in sas-r03e this week:=20

1.  NOTIFY (RESERVED 2) is supposed to be neutral disparity but is not.
All the other ALIGNs and NOTIFYs are neutral.  A different encoding =
will
need to be assigned or this primitive will need to be removed.

2. One of the current arbitration fairness rules in 7.12.3 (Arbitration
fairness) is:
"If two connection requests pass on a physical link, the winner shall =
be
determined by comparing OPEN address frame field values in the =
following
order:

1) largest arbitration wait time field value; and=20
2) largest source sas address field value."=20

If two phys in a wide-capable port are attached to each other (unusual
but allowed) and for some reason they choose different connection rates
(not disallowed) when simultaneously sending OPENs, they need to agree
on which request wins.  If each phy assumes it wins and send
OPEN_ACCEPT, one phy would think the connection rate is different from
the other.

Adding:=20
3) largest connection rate field value.=20

solves this, and makes the comparison exactly the same as that used by
expander devices when comparing competing path requests (see 7.12.4.1
[Expander] Arbitration overview).


If there is no objection I'll add these to the letter ballot comments
and resolve them.=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




------_=_NextPart_001_01C2ECB8.3D5F859F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

Message You're=20 right - generating OPEN_ACCEPT would be the "lose" case not the "win"=20 case.  
 
 To=20 handle both sides requestingthe same connection rate we could add this = rule: if=20 the AWT, source SAS address, and connection rate are the same, the SAS = port=20 shall choose one request as the winner and one as the loser.  = Since=20 it's the same port on both sides, it should be able to solve its own=20 problem.
  
 That=20 could be applied to just AWT and source SAS address without including = the=20 connection rate, if that seems simpler.
  
 -- = 
Rob Elliott, = elliott at hp.com=20 
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology 
https://ecardfile.com/id/Ro= bElliott=20 


-----Original Message-----
From: = Day, Brian=20 [mailto:bday at lsil.com] 
Sent: Monday, March 17, 2003 10:56=20 AM
To: Elliott, Robert (Server Storage); T10 Reflector=20 (E-mail)
Subject: RE: SAS NOTIFY (RESERVED 2) encoding = problem and=20 arbitration fairness issue for an absurd case


 Rob...
  
 For=20 item #2, isn't a more likely absurd case is when the link rates = are the=20 same for both ports.  In either case, if both ports = assume they=20 win, then they will both wait for (not generate?) an = OPEN_ACCEPT, which=20 will result in an open timeout.  This could happen for = every=20 connection request.  I don't think adding 3) helps=20 this.
  
 Brian Day
 LSI=20 Logic 
 -----Original Message-----
From: Elliott, Robert = (Server=20 Storage) [mailto:Elliott at hp.com]
Sent: Friday, March 14, = 2003 5:35=20 PM
To: t10 at t10.org
Subject: SAS NOTIFY = (RESERVED 2)=20 encoding problem and arbitration fairness issue for an absurd=20 case


 We noticed two problems in sas-r03e = this=20 week: 1.  NOTIFY (RESERVED 2) is = supposed to be=20 neutral disparity but is not.  All the other ALIGNs and = NOTIFYs are=20 neutral.  A different encoding will need to be assigned or = this=20 primitive will need to be removed. 2. One of the current arbitration = fairness rules=20 in 7.12.3 (Arbitration fairness) is:
"If two connection requests = pass on=20 a physical link, the winner shall be determined by comparing OPEN = address=20 frame field values in the following order: 1) largest arbitration wait time = field value;=20 and 
2) largest source sas = address field=20 value." If two phys in a wide-capable port = are attached=20 to each other (unusual but allowed) and for some reason they choose = different connection rates (not disallowed) when simultaneously = sending=20 OPENs, they need to agree on which request wins.  If each phy = assumes=20 it wins and send OPEN_ACCEPT, one phy would think the connection = rate is=20 different from the other. Adding: 
3)=20 largest connection rate field value. solves this, and makes the = comparison exactly the=20 same as that used by expander devices when comparing competing path = requests=20 (see 7.12.4.1 [Expander] Arbitration overview).
 If there is no objection I'll add = these to the=20 letter ballot comments and resolve them. 
-- 
Rob Elliott,=20 elliott at hp.com 
Hewlett-Packard Industry=20 Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott=20 



------_=_NextPart_001_01C2ECB8.3D5F859F--




More information about the T10 mailing list