wait for configuring

Ralph Weber roweber at IEEE.org
Mon Jan 30 17:26:14 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Tim,

The part about the CONFIGURING bit is in SAS.

I am not sure about the rules for the management application client
"handling this case". Maybe they are there.

What I definitely cannot find specified anywhere (even in your message)
are requirements that are sufficient to guarantee that HBAs do not
see BROADCAST (CHANGE) primitives until all the self-configuring
expanders have finished their thrashing.

Since the thrashing simply ends, how would an expander with attached
HBAs 'know' to send BROADCAST (CHANGE) primitives to them? How does
the expander 'know' not to clear its own CONFIGURING bit before this
moment in time is reached?

Is any good served by sending a BROADCAST (CHANGE) to an HBA on a Phy
where the CONFIGURING bit is set? Or, are we just going through the
BROADCAST motions so that nobody realizes that BROADCAST (CHANGE) is
more than a little quirky?

All the best,

.Ralph



Tim Symons wrote:

>* From the T10 Reflector (t10 at t10.org), posted by:
>* Tim Symons <Tim_Symons at pmc-sierra.com>
>*
>The managmenent application client (whether an HBA or a self-configuring expander device) has information on the type of attached device from the IDENTIFY frame.
>
>When a device type of greater than 001b responds  with the CONFIGURING bit set to one in the REPORT GENERAL response, then the application client shall wait until it receives a BROADCAST (CHANGE) on the port.
>What it does in the time between is vendor specific. It is logical that other ports would be checked.
>
>This condition occurs when an HBA is attached to a self-configuring device, or a self-configuring device is attached to another self-configuring device. Today's managmen application client already handles this case. Are timers used in todays HBAs for the case that a the configuring response is not received?
>
>The result of a time-out should be a BROADCAST (CHANGE) issued by the Application Client device, because this will cause a re-initialisation of the attached device.
>
>Regards
>       Tim.
>
>Tim Symons
>Principal Engineer
>PMC-Sierra Ltd.
>Burnaby
>
>Cell: 778 998 5025
>E-mail Tim_Symons at pmc-sierra.com
>
>
>-----Original Message-----
>From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Ralph
>Weber
>Sent: Friday, January 27, 2006 5:24 PM
>To: T10, Reflector
>Subject: Broadcast (Change) overload
>
>
>* From the T10 Reflector (t10 at t10.org), posted by:
>* Ralph Weber <roweber at ieee.org>
>*
>Regarding Rob's comment:
>
>  "The BROADCAST (CHANGE)s may thrash for a while, but
>  will stop when the expanders are not detecting any more
>  changes."
>
>In keeping with the bull-in-a-china-shop style I have
>exhibited so far, I cannot help but wonder if BROADCAST
>(CHANGE) is overloaded. Currently, it seems to serve two
>functions:
>
>  - Telling other Expanders to reassess their self-config-
>    uration status
>  - Telling HBAs to kick off a serious sweep through the
>    SAS Domain looking for configurable devices
>
>The HBA action induced by the expander-based thrashing of
>BROADCAST (CHANGE)s cannot be helpful in the overall config-
>uration process. Until the thrashing settles down, every
>entry of the HBAs into the picture throws more unproductive
>traffic on the links.
>
>Have I missed something?
>
>.Ralph
>
>*
>* 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
>
>
>
>  
>

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