[SAS] Who should receive CHANGE

Elliott, Robert (Server Storage) Elliott at hp.com
Sat Oct 19 08:08:04 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
Pak, dividing your recent emails into 2 topics:

1. How does the target handle changes in supported connection link
rates in the domain?

I don't think targets should assume the worst case if they see CHANGE
and force all their outstanding requests back to 1.5 Gbps.  This
would interfere with 99.99+% of the requests that should run fine
at the requested link rate.

I prefer to add this rule:
"If a target that receives an OPEN_REJECT (LINK RATE NOT SUPPORTED) in 
response to one of its connection requests that has the CONNECTION 
LINK RATE field set to greater than 1.5 Gbps, it shall retry the 
connection request with the CONNECTION LINK RATE field set to 
1.5 Gbps."

The target already handles OPEN REJECT (RETRY).  This is just a 
variation on that - retrying and changing the rate to 1.5 Gbps.
This way the target only downshifts when needed.

If an OPEN_REJECT (LINK RATE NOT SUPPORTED) is returned for
a 1.5 Gbps request, something is broken.  The existing rule about
retrying until the I_T nexus loss timer expires still seems
adequate.


2. What CONNECTION LINK RATE should the target use in its OPENs?

I agree we do not specify this anywhere.  I suggest we model this after 
the INITIATOR CONNECTION TAG. Its rules are:
"When requesting a connection to an initiator port, a target port shall
set the INITIATOR CONNECTION TAG field to the value received in
connection requests from the initiator port. An initiator port shall 
use the same INITIATOR CONNECTION TAG field value for all connection 
requests to the same target port, and shall only change the INITIATOR 
CONNECTION TAG field value when it has no commands outstanding to that 
target port. Targets are not required to check consistency of the 
INITIATOR CONNECTION TAG field in different connection requests from 
the same initiator port."

For CONNECTION LINK RATE, the wording would be:
"When requesting a connection to an initiator port, a target port shall
set the CONNECTION LINK RATE field to the value received in
connection requests from the initiator port. An initiator port shall 
use the same CONNECTION LINK RATE field value for all connection 
requests to the same target port, and shall only change the 
CONNECTION LINK RATE field value when it has no commands outstanding 
to that target port. Targets are not required to check consistency of
the 
CONNECTION LINK RATE field in different connection requests from 
the same initiator port."

--
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: Friday, October 18, 2002 1:30 PM
> To: Reif, Jim; 't10 at t10.org'
> Subject: RE: [SAS] Who should receive CHANGE
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Seto, Pak-lung" <pak-lung.seto at intel.com>
> *
> Yes, target (disk)has decided not to support SMP, but 
> regardless whether target will support SMP or not, target 
> needs to know if there is something happened on one of the 
> links that it needs to make connection back to the initiator.
> 
> If the initiator send a command (read in this case) to the 
> target.  The target needs to remember the "link rate" (which 
> should define as end-to-end link rate) in the OPEN Address 
> Frame in order to reconnect back to the initiator to deliver 
> data when it is ready.  What happen if one of the link 
> between the initiator and the target got reset and 
> re-negotiate to a lower link speed which happens to be the 
> new "end-to-end link rate" between that initiator and the 
> target".  Now the "end-to-end link rate" saved by the target 
> which was suppose to be used to reconnect back to the 
> initiator become invalid. Therefore, the target needs to know 
> something has happened to "a" link and since target does not 
> support SMP, it has to assume all the saved link rate may no 
> longer valid and since it is the target's turn to return data 
> back to the initiator (in this example).  The target needs to 
> play it safe to temporary use the minimum link rates as 
> defined by the SAS standard to reconnect back to the 
> initiator until the initiator initiate a new connection to 
> the target to send the target the new "end-to-end link rate" 
> thru the OPEN Address Frame. The target will need to do that 
> for all initiator that it has outstanding command to return 
> data to. This has been described somewhat in detail in 
> another reflector message that I sent earlier.
> 
> There can be different ways to handle this situation, but all 
> of them require the target to know that it's saved 
> "end-to-end link rate" may no longer valid.
> 
> Pak
> 
> -----Original Message-----
> From: Reif, Jim [mailto:Jim.Reif at hp.com]
> Sent: Friday, October 18, 2002 12:00 PM
> To: Seto, Pak-lung
> Subject: RE: [SAS] Who should receive CHANGE
> 
> 
> Why do you feel that targets need to see the CHANGE primitive?
> 
> They will see them because the Expander will send out to all 
> ports regardless of the attached device type. But what would 
> it do with the information, since targets don't support SMP protocol?
> 
> Jim Reif
> Hewlett-Packard 
> 281-514-8237
> email: jim.reif at hp.com
> 
> 
> -----Original Message-----
> From: Seto, Pak-lung [mailto:pak-lung.seto at intel.com]
> Sent: Friday, October 18, 2002 9:36 AM
> To: 't10 at t10.org'
> Subject: [SAS] Who should receive CHANGE
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Seto, Pak-lung" <pak-lung.seto at intel.com>
> *
> in SAS spec. v 2a page 107, Table 32
> 
> CHANGE primitive only send from E to I
> 
> but in clause 7.1.4.4, page 115
> 
> "CHANGE is sent by and expander device to notify initiator 
> ports and other expander devices that s configuration change 
> has occurred."
> 
> 
> 
> Which one is correct?
> 
> I believe the CHANGE primitive needs to send to both expander 
> devices and targets also.
> 
> Pak
> *
> * 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