[BULK] - Re: [BULK] - SAS Backoff Retry Priority

Greg Tabor greg at vitesse.com
Wed Aug 11 09:18:36 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* Greg Tabor <greg at vitesse.com>
*
Gil,

When you say "suppose that the expander phy transmits a lower priority 
request after AIP" you are implying by your statement that the Retry 
Priority Status rule will result in a *lower* priority request winning 
arbitration.  But the sticky point here is that the Retry Priority 
Status rule redefines the concept of priority.  When IGNORE_AWT is set, 
a request's priority is decided purely by the source address and 
connection rate (table 82), so it is not correct to say that "the 
expander transmits a *lower* priority request" as a result of this.  The 
expander is still only sending out higher priority requests after 
sending AIP; the difference is that the definition of "priority" has 
changed for the backoff/retry case because IGNORE_AWT ends up getting 
set.  In this case, a "higher priority" OPEN does not necessarily have a 
higher arbwait time.

If you are concerned that the other expander will be confused by 
receiving an OPEN frame after AIP with a lower arbwait time than the one 
it sent, bear in mind that the AIP/OPEN reception will cause that 
expander to backoff and retry its request as well.  Then it will use the 
Retry Priority Status rule and come to a consistent decision with the 
first expander.

This is a minor weakness in the SAS fairness algorithm: there are two 
different concepts of priority.  The normal priority (which includes the 
arbwait time and is consistent with an LRU fairness algorithm) when not 
doing a backoff/retry, and the retry priority status version of priority 
when doing a backoff/retry.  What this boils down to is that 
occasionally, when OPEN frames cross on the link, the LRU fairness 
algorithm is temporarily set aside and the system falls back to relying 
on static source addresses to resolve the creation of connection 
pathways (the reason, of course, that the Retry Priority Status rule was 
added to the standard was to prevent LIVELOCKs).

Greg


Gil Romo wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gil Romo <gil.romo at qlogic.com>
> *
> Hello Greg,
> 
> Suppose that the expander phy transmits a lower priority request after AIP to a 
> SAS phy.  A SAS phy backs off by assuming that the incoming request has higher 
> priority after receiving AIP.  This is the wrong decision, in this case, 
> however.
> 
> Gil
> 
> 
>>Date: Thu, 05 Aug 2004 21:15:33 -0600
>>From: Greg Tabor <greg at vitesse.com>
>>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
>>X-Accept-Language: en-us, en
>>MIME-Version: 1.0
>>To: Gil Romo <gil.romo at qlogic.com>
>>CC: t10 at t10.org
>>Subject: Re: [BULK] - SAS Backoff Retry Priority
>>Content-Transfer-Encoding: 7bit
>>X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 
> 
> 2004.8.5.109751
> 
>>X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, 
> 
> __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 
> 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, 
> __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __C230066_P5 0, EMAIL_ATTRIBUTION 0, 
> QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, 
> USER_AGENT 0.000'
> 
>>Gil,
>>
>>Is your concern that the Retry Priority Status rule contradicts the 
>>statement in 7.12.5:
>>
>>"After an expander device transmits an AIP, it shall not transmit an 
>>OPEN address frame unless it has higher arbitration priority than the 
>>incoming connection request."
>>
>>?
>>
>>If so, here are two points to consider:
>>
>>1. In 7.12.4.1 the definition of "arbitration priority" is changed when 
>>IGNORE_AWT is set.
>>
>>2. If, in your example, expander 2 phy Y transmitted an OPEN frame after 
>>AIP with a lower arbwait time than the one it received crossing on the 
>>same link, then the expander to the right of expander 2 would also wind 
>>up backing off and retrying the OPEN it originally forwarded to exp 2.Y 
>>and set IGNORE_AWT when it rearbitrates as well.  So, the decision 
>>settles into a consistent state in both expanders.
>>
>>Regards,
>>-- 
>>////////////////////////////////////////////////////
>>// Greg Tabor - Vitesse Semiconductor Corporation //
>>// voice: (719) 867-4414      fax: (719) 867-6203 //
>>//            email: greg at vitesse.com             //
>>////////////////////////////////////////////////////
>>
>>
>>Gil Romo wrote:
>>
>>>An expander obeying backoff retry priority could violate rules stated in 
>>>subclause 7.12.5 "Expander rules and connection requests".
>>>
>>>The attached document describes a scenario where this may occur.
>>>
>>>------------
>>>Gilbert Romo
>>>Circuits & Integration
>>>QLogic Corporation, Aliso Viejo, California
>>>Office: 949-389-6266
>>>E-mail: gil.romo at qlogic.com
>>
>>
> 
> ------------
> Gilbert Romo
> Circuits & Integration
> QLogic Corporation, Aliso Viejo, California
> Office: 949-389-6266
> E-mail: gil.romo at qlogic.com
> 
> *
> * 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