Change count & Route Table clearing

Fairchild, Steve steve.fairchild at hp.com
Thu Sep 2 06:12:33 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Fairchild, Steve" <steve.fairchild at hp.com>
*
Subra,

See my answers below.

Thanks,

Steven Fairchild
Senior Member Technical Staff
Hewlett-Packard Corporation
MS150901
20555 SH 249
Houston, TX 77070
281 514 6448
steve.fairchild at hp.com

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of
Subramanian Kuppusamy, Noida
Sent: Thursday, September 02, 2004 7:14 AM
To: ''t10 at t10.org ' '
Cc: 'Johnson, Stephen B. '
Subject: RE: Change count & Route Table clearing


* From the T10 Reflector (t10 at t10.org), posted by:
* "Subramanian Kuppusamy, Noida" <subramaniank at noida.hcltech.com>
*
 Thank you John for the immediate reply,
Still its not convincing
1.Checking Changecount value in all expanders is time consuming.
Since Steve Fairchild has included this check in Annex-K, I just wanted to
know whether there is any other significance for this check or can we
discard it.
Because Broadcast (Change) primitive will anyway reinitiate the discover
process.

<fairchild> 

The reason for the additional checks is that the Broadcast (Change) is not a guaranteed delivery to the host.  It could be missed, so the extra check was done to ensure that the downstream topology was stable before doing the additional checks on the route table.  The additional checks are done to ensure that backward compatibility with the SAS 1.0 non-optimized route table layout.  The total time checking the change count is pretty minor compared to the full discovery process (including device identification for SATA devices).

If you believe the risk to losing the Broadcast (Change) is too small to worry about, then the other opportunity is to short circuit the full discovery process in a large populated tree.  You could avoid doing configuration down selected branches if the expander at the branch shows no change count.

</fairchild>

2.Once connection is established, clearing the Route table should not affect
the traffic which is in progress. 
Moreover route table must be cleared before reconfiguring to avoid dead
entries. 
So a SMP Request function to clear the route table will make reconfiguration
clean and can save time.

<fairchild> 

Clearing the route tables would prevent connections from the devices back to the host from being established.  There should be no reason to clear the tables, 

-- if entries are stale (that is a device is removed) leaving the entry in the table doesn't cause a problem, any attempt to address the device will result in a OPEN_REJECT from the last expander in the link.

-- if a device is added there is no disruption to other devices with commands outstanding they can still make connections even while the discovery process is in progress (obviously this depends on the capabilities of the host).

</fairchild>

Thanks for your time

Regards,
Subra

-----Original Message-----
From: owner-t10 at t10.org
To: Subramanian Kuppusamy, Noida; 't10 at t10.org '
Sent: 9/1/04 7:10 PM
Subject: RE: Change count & Route Table clearing

* From the T10 Reflector (t10 at t10.org), posted by:
* "Johnson, Stephen B." <Stephen.B.Johnson at lsil.com>
*
Please see below

-----Original Message-----
From: Subramanian Kuppusamy, Noida
[mailto:subramaniank at noida.hcltech.com]
Sent: Tuesday, August 31, 2004 8:05 PM
To: 't10 at t10.org '
Subject: Change count & Route Table clearing


* From the T10 Reflector (t10 at t10.org), posted by:
* "Subramanian Kuppusamy, Noida" <subramaniank at noida.hcltech.com>
*
Hi,
I am new to this group. I have some basic doubts in Annex-K of SAS 1.1
specs

1. If I correclty understood Changecount value is checked by the
intiator
only for the top most Expander or the Hub expander.
   From the specification,Changecount value is incremented in an
Expander
device only if it initiates a Broadcast(Change). So if a
Broadcast(Change)
is initiated by some Expander somewhere in same SAS Domain, the topmost
expander will just forward the Broadcast(Change). 
  In this case obviously the changecount value of topmost expander is
not
changed. Then Why this changecount value check is needed after
completing
the configuration of route table?

<SJ> All expanders ChangeCount can be checked using Report General.
For all expanders found with a updated change count, 
the initiator can look at each phy of the expander to understand what
has
changed.

2. How the routing table in all the configurable expander devices are
cleared before starting rediscover process for some reason.
   It is ok for a self configuring expander as it may handle with some
internal function. But for other configurable expander devices How the
route
table is cleared? 
  Am I missing any SMP Request function meant for this??

<SJ> The initiator should not clear the routing tables at the start of
each
rediscover.
This would disrupt current IO or SMP traffic. 
The initiator should only change what route entries that needs to be
changed

and leave all table entries that are correct as is. 
 

Any input on this will be helpful

Thanks & Regards
Subra
*
* 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
*
* 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