Edge Expander Set and STP/SATA

Elliott, Robert (Server Storage) Elliott at hp.com
Wed Oct 9 09:15:04 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
The edge expander devices that form the cloud need to be carefully
selected to work together for route table size.  I don't think every
edge expander device will support 64 route entries per phy (this is the
burden we place on the fanout expander device, where each phy is an
interoperability point). Anything less means that whoever puts the set
together has to pick edge expander devices that will work together.  

I think buffer allocation is best handled the same way.  Otherwise, we'd
have to require every edge expander device have a large buffer with a
programmable buffer depth, set up by software based on the topology.  To
make such software as generic as possible, the expanders would have to
report their latency.  Software would still have to guess the latency of
the wire (admittedly tiny in SAS). 

--
Rob Elliott, elliott at hp.com
Industry Standard Server Storage Advanced Technology
Hewlett-Packard



> -----Original Message-----
> From: Seto, Pak-lung [mailto:pak-lung.seto at intel.com] 
> Sent: Wednesday, October 09, 2002 9:42 AM
> To: t10 at t10.org; Fairchild, Steve
> Cc: Seto, Pak-lung
> Subject: Edge Expander Set and STP/SATA
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Seto, Pak-lung" <pak-lung.seto at intel.com>
> *
> In the Edge Expander Set proposal (02-359r2):
> 
> The definition of Edge Expander Set is "A set of edge 
> expander devices that are bounded by a subtractive routing 
> port from one member of the set."
> 
> "Edge expander devices may be grouped into edge expander 
> device sets.  The edge expander device sets are bounded by 
> the direct routing phys attached to end devices and the phys 
> supporting subtractive routing that are:
> 	a) Attached to the phys of a fanout device; or,
> 	b) Attached to the phys supporting subtractive routing 
> on another edge expander device set; or;
> 	c) Attached to an end device."
> 
> From the definition of Edge Expander Set, there are no 
> restriction on the number of level of edge expanders within a 
> "set of edge expander" can cascade.  It can be configured 
> like a tree structure with many level as long as it meets the 
> above definition and with no more than 64 end devices.  Or it 
> can be constructed with a string of 3 port edge expanders of 
> up to 64 levels (practical/meaningful limit) on each side of 
> the Fanout expander, etc (.  For SAS, it may be OK (with long 
> latency) but with STP/SATA, it can cause a lot of problem 
> because in STP, the expander provides SATA emulation within 
> the expander link.  It requires certain amount of buffering 
> (depending on the expander latency) to satisfy the HOLD/HOLDA 
> SATA flow control protocol.  For each additional level of 
> cascading, it will require additional X amount of buffering.  
> Architecturally, it is a problem, for real implementation 
> there may be a practical limit of a few levels.  In the 
> proposal, all the diagrams only show 2 levels of cascading.
> 
> In this Edge Expander Set proposal, since there is no 
> restriction on the number of expander levels in expander set 
> configuration, it will require a lot of buffering within the 
> expander to anticipate many levels of expander cascading, it 
> is very costly.
> 
> Either the SAS specification sets the limit the number of 
> level of cascading or individual implementation will set 
> their own limit.  It will be better for interoperability 
> reason that the SAS specification set a reasonable limit 
> number of levels.
> 
> Pak Seto
> Intel Corporation
> Intel Communications Group
> Storage Components Division
> pak-lung.seto at intel.com
> 978-553-2159
> 
> *
> * 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