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

Day, Brian bday at lsil.com
Mon Mar 17 08:55:33 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <bday at lsil.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2ECA6.06399B00
Content-Type: text/plain;
	charset="iso-8859-1"

Rob...
 
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.
 
Brian Day
LSI Logic 

-----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: 

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 
2) largest source sas address field value." 

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: 
3) largest connection rate field value. 

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. 
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
 <https://ecardfile.com/id/RobElliott>
https://ecardfile.com/id/RobElliott 




------_=_NextPart_001_01C2ECA6.06399B00
Content-Type: text/html;
	charset="iso-8859-1"

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

SAS NOTIFY (RESERVED 2) encoding problem and arbitration fairness issue for an absurd case Rob...
  
 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.
  
 Brian Day
 LSI Logic 
 -----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: 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 
2) largest source sas address field value." 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: 
3) largest connection rate field value. 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. 
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 



------_=_NextPart_001_01C2ECA6.06399B00--




More information about the T10 mailing list