sas1r04: Arbitration and resource management in an expander device

Elliott, Robert (Server Storage) elliott at hp.com
Wed Apr 21 13:42:06 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*

> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gil Romo <gil.romo at qlogic.com>
> *
> The rules for generating Arb Won and Arb Lost, in 7.12.4.1, 
> only specify what happens when an expander phy has a request 
> and there is a higher priority request for that phy as the 
> destination.  
> 
> They don't cover the case where two or more requests contend 
> for the same destination phy.
> 
> Therefore, part c) of "The ECM shall generate the Arb Won 
> confirmation when ...", should be:
>   "no higher priority connection requests are present with 
> either this expander phy as the destination or with the 
> destination expander phy of this request as 
> the destination.".

I agree, and will add this to 04-115 which is collecting 
miscellaneous corrections.

However, this needs to account for the fact that all the
requests might be equal (since they're peer requests, they
could be from different phys in the same wide source port).  
The ECM has to pick only one, but it doesn't matter which 
one.  If it implemented "no higher priority requests are 
present" it would hang and never grant to any of them.

I think adding this would do the trick:
c) ...; and
d) the connection request is chosen as the highest priority
   connection request in the expander device mapping to the 
   specified destination expander phy.

> And, part c) of "The ECM shall generate an Arb Lost 
> confirmation when ...", 
> should be:
>   "there is a higher priority connection request for the 
> destination expander phy of this request or the destination 
> expander phy of this connection request has received a 
> higher priority OPEN address frame with this expander phy 
> as its destination ...".

This is not correct. If this phy loses to a peer competing 
request, it just continues to wait for Arb Something. 
Arb Lost means the the ECM has picked a request going into
this phy, and this phy is now going to serve as a destination 
rather than as a source.

It's more like an "Arb Backoff" than "Arb Lost."

> ------------
> Gilbert Romo
> Circuits & Integration
> QLogic Corporation, Aliso Viejo, California
> Office: 949-389-6266
> E-mail: gil.romo at qlogic.com

--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott

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