[BULK] - Re: [BULK] - SAS Backoff Retry Priority
greg at vitesse.com
Wed Aug 11 09:34:30 PDT 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* Greg Tabor <greg at vitesse.com>
Gil - Sorry, I misread your latest comment.
But the statement I made is still true and applies to SAS end device
phys as well. If a SAS end device phy receives an AIP before an OPEN,
it has to disregard any OPEN request it sent out which passed on the
link and consider the one it received (it needs to either send an
OPEN_ACCEPT or some type of OPEN_REJECT in response to it).
The bottom line here is that the AIP signifies that the expander has
received the OPEN from the end device, has considered it in arbitration,
and has decided that it has another higher priority request to send back
across on the same link. In a sense, how it defines "priority" at this
point is not even of concern to the end device. Once the end device
sees the AIP, the expander's subsequent decision is final and must be
considered. In a sense, it really makes arbitration by end devices much
simpler, since there is no link-layer concept of backoff/retry. When an
end device sends out an OPEN, one of the following must be true:
1. The end device sent the only OPEN on the wire, with no other OPEN
passing on the link.
2. The expander sent a lower priority OPEN (based on the passing OPEN
frame arbitration rules in table 80) without preceeding AIP, and the end
device ignores it.
3. The expander sent a higher priority request (again based on table 80)
without preceeding AIP, and the end device must accept or reject it.
4. The expander sent *any* request with a preceeding AIP, and the end
device must accept or reject it.
So, end devices really shouldn't concern themselves with Retry Priority
Greg Tabor wrote:
> 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).
> 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.
>>> 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)
>>> 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: 18.104.22.168886, Antispam-Core: 22.214.171.124542, Antispam-Data:
>>> 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'
>>> 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 126.96.36.199 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
>>> // 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
// Greg Tabor - Vitesse Semiconductor Corporation //
// voice: (719) 867-4414 fax: (719) 867-6203 //
// email: greg at vitesse.com //
* 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