[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