SAS - PL_OC state machine - How many?

Seto, Pak-lung pak-lung.seto at intel.com
Wed May 14 14:39:18 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Seto, Pak-lung" <pak-lung.seto at intel.com>
*


-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Wednesday, May 14, 2003 4:22 PM
To: t10 at t10.org
Subject: RE: SAS - PL_OC state machine - How many?


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*


> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Seto, Pak-lung" <pak-lung.seto at intel.com>
> *
> How many PL_OC state machines per PORT LAYER?
> 
> The way that is stated 8.2 of SAS v2g - "There is one PL_OC 
> state machine per port" - it seems match the state machine 
> description.
> 
> What if I have a "chip" that can support multiple links (e.g 
> 4 links) and wide port configuration.  First, I would assume 
> the "chip" will try to attempt to make wide port link
> initialization (in this example - 4 links) by
> sending out IDENTIFY frames on all 4 links with the same SAS 
> address.  In this case, if all the returning IDENTIFY frames 
> has the same SAS address, a 4-links wide port is established 
> - therefore - ONE PL_OC state machine.

Correct (assuming the chip chose to send the same address
out its 4 phys).

>>>>>>> If a chip have multiple links and support wide port configuration.
>>>>>>> It should try to use the same SAS address to try to initialize it's
links
>>>>>>> with the maximum width because it will give the system higher
performance.
>>>>>>> If that fail, base on the returing SAS address, it can re-configure
itself
>>>>>>> to match the IDENTIFY frame response to the next best configuration.
>>>>>>> If a chipo with multiple links and support wide port, but uses
different
>>>>>>> SAS addresses for IDENTIFY frames (e.g. 1 SAS address per link), it
will
>>>>>>> not be able to configure itself to wide port.  Of course, the system
can
>>>>>>> always pre-configure to certain configuration instead of automatic
port
>>>>>>> configuration.

> What if the returning IDENTIFY frames has all different SAS 
> address and assume the "chip" will try to re-initialize the 
> link by [assigning?] different SAS addresses to each links 
> (assuming to make config stay in one SAS domain).

The chip should not change its own addresses (the ones it sends
out with outbound IDENTIFY address frames) just because the
inbound IDENTIFY address frames had different addresses.

>>>>>>> This is not true unless you want to disable some links/ports
>>>>>>> For example, a chip with 4 links, two links connected to one
expander
>>>>>>> and the other two links connected to another expander.  The two
expanders
>>>>>>> are connected to a FAN OUT expander.  If this chip does not change
the address
>>>>>>> for one of these two link set, it will have to disable two of the
links, because
>>>>>>> no two ports can have the same SAS address within a single SAS
domain - because
>>>>>>> of the FAN OUT expander

It's OK to have the same SAS address in two domains at the
same time.  (this is why is serves as a "port identifier"
in the SCSI architecture but not as a "port name.")

>>>>>> Not when it is connected like the example described above.

A "port" is a virtual concept - a collection of phys
using the same SAS address that are attached to another
set of phys using the same SAS address.

>>>>>> Yes, this is true, but the PL_OC SM is not virtual

> After link initializaiton, 4 single link - 4 ports configuration is
> established.  In this case - there will be 4 PL_OC state 
> machines with "ONE" port layer???

There are 4 ports in this case, each with a PL_OC state 
machine.  They're all at the port "layer" architecturally.

Each port object has its own transport layer state machines, 
port layer state machines, and one or more phys.

Each phy object has its own link layer state machines and 
phy layer state machines.

>>>>>>> It is easy to create "OBJECT" in software, but how can it be
>>>>>>> handled in hardware - in gates.  This is the major problem with
>>>>>>> AL3.

> Does the standard expect the SAS port layer being implemented 
> in firmware?
> Otherwise, how does hardware implemented SAS port layer can 
> dynamically support various number of PL_OC state
> machines (not easy)?

The standard is not very close to actual RTL implementation in the
port and transport layers.  The transport layer describes state 
machines being created and destroyed based on frame reception and
application layer requests.  This is not how real hardware works.

>>>>>>> Exactly, "create" and "destroy" is simple for software

One way to conceptualize an implementation is as a single
"port layer" state machine that handles up to 4 ports 
simultaneously.  Everything it deals with has a
"port number" index appended to it.

> In the SAS spec, it does not mention about this kind of 
> situation and how
> the PL_OC state machine or port layer handle this situation?  Did I
> interpert the PL_OC state machine wrong?
> 
> Pak
> 

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