How do SAS self-configuring expanders self configure?

Ralph Weber roweber at
Fri Jan 27 08:47:34 PST 2006

* From the T10 Reflector (t10 at, posted by:
* Ralph Weber <roweber at>
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,


Elliott, Robert (Server Storage) wrote:

>* From the T10 Reflector (t10 at, posted by:
>* "Elliott, Robert (Server Storage)" <Elliott at>
>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
>Hewlett-Packard Industry Standard Server Storage Advanced Technology

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list