How do SAS self-configuring expanders self configure?

Elliott, Robert (Server Storage) Elliott at hp.com
Fri Jan 27 10:49:24 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
One of the goals of SAS-2 is to improve the rules for self-configuring
expanders.  I guess we're starting that topic :-)

If an expander is busy configuring, OPENs to devices attached to that
expander will work but OPENs to devices attached to expanders attached
to that expander might not.

Kevin raises good points about defining how long a management
application client (either in a self-configuring expander or elsewhere)
should allow for CONFIGURING to change to 0 before giving up on that
expander.  To be robust and tolerate errors, some timeout is necessary.

Each expander sends BROADCAST (CHANGE) when it finishes a discover
process and needs the others to rescan.  The BROADCAST (CHANGE)s may
thrash for a while, but will stop when the expanders are not detecting
any more changes.

This rule about when to send BROADCAST (CHANGE) needs to be modified so
it is not sent if there ended up being no changes detected:
"h) after a self-configuring expander device has completed configuration
and has changed its CONFIGURING bit from one to zero in the SMP REPORT
GENERAL function (see 10.4.3.3);"

Just basing it on the bit toggling won't resolve.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


 

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Ralph Weber
> Sent: Friday, January 27, 2006 10:48 AM
> To: t10 at t10.org
> Subject: Re: How do SAS self-configuring expanders self configure?
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> To me, this looks like a fine kettle of fish, particularly
> in light of Kevin's comments.
> 
> If all the Expanders in a SAS Domain are self-configuring,
> how do they avoid tripping over each other while they
> march through the full topology tree? Who waits for whom
> to set their Configuring bit to zero, and how long?
> How many Broadcast (Changes) does an HBA have to see
> before it can really scan the SAS Domain for interesting
> End Devices?
> 
> It seems to me that Self-Configuring Expanders were defined
> back when the only Expander that needed to be Self-Configuring
> was the one and only Fanout Expander allowed in a SAS Domain.
> The rules for and operation of Self-Configuring Expanders have
> not been put under the interoperability magnifying glass since
> those heady, early days.
> 
> If Self-Configuring Expanders are to become the linchpin of SAS
> Domain configuration, I think the time has come for a careful
> look at these issues.
> 
> All the best,
> 
> .Ralph
> 
> 
> Elliott, Robert (Server Storage) wrote:
> 
> >* From the T10 Reflector (t10 at t10.org), posted by:
> >* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> >*
> >Yes, it performs the full discover process.  If there is a 
> >configurable expander somewhere in the topology, the management 
> >application client in the self-configuring expander is as
> >responsible as any other for programming its routing tables.
> >
> >If the domain contains only self-configuring expanders (how it
> >learns this is vendor-specific), then it has no interest in the
> >addresses found beyond a subtractive phy; it only needs to know 
> >the addresses below its table routing phys.
> >
> >If we get rid of subtractive phys in SAS-2, then exploring the
> >whole domain will be necessary even in that case.
> >
> >My feeling is that having all expanders perform just discovery 
> >(but never have to program anyone else's routing tables) yields
> >reasonable amounts of SMP traffic - one REPORT GENERAL per
> >expander + one DISCOVER per expander phy.  Better-optimized
> >functions like DISCOVER LIST will improve that.  Where
> >discovery takes an awful long time is when remote
> >application clients are configuring routing tables, adding
> >one CONFIGURE PHY ROUTE INFORMATION per table entry (e.g.
> >hundreds/thousands of SMP function calls).  Again, a LIST 
> >function could help optimize that, but it's still more 
> >traffic than not configuring at all.
> >
> >--
> >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
> 
*
* 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