Questions on proposal 08-015

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Wed Dec 3 15:30:00 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Thanks for your reply, Brian.
I like the idea of keeping all of the SMP function changes in the same
document. Since you have started 08-420 for this purpose, that would be a
good place to bundle the SMP PHY CONTROL, SMP DISCOVER, and SMP DISCOVER
LIST (if changes to short discover version is needed). I will add a
placeholder referring to 08-420 for those details.
I will continue to describe the mode page changes (for the target device)
in 08-015.
	     "Day, Brian"						   
	     <Brian.Day at lsi.co						   
	     m> 							To 
	     No Phone Info	       "Gerry.Houlder at seagate.com"	   
	     Available		       <Gerry.Houlder at seagate.com>,	   
				       "t10 at t10.org" <t10 at t10.org>	   
									cc 
	     12/03/2008 03:12						   
	     PM 						   Subject 
				       RE: Questions on proposal 08-015    
Hi Gerry....
Please see below with BD>>
Brian Day
LSI Corp.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Tuesday, December 02, 2008 3:37 PM
To: t10 at t10.org
Subject: Questions on proposal 08-015
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I have some questions on which I need advice of expander folks.
(1) 08-015r5 currently uses byte 13, bits 5 and 4, of the DISCOVER response
to report the Phy PS Condition field. It has been pointed out that is area
of the DISCOVER response is intended to line up with related fields in the
IDENTIFY address frame and should not be used for things that are not in
the IDENTIFY address frame. However we are adding capability bit(s) (there
is an outstanding question of whether we need one or two bits here) to the
IDENTIFY address frame.
BD>> This area isn't intended to exactly line up byte-for-byte with the
received IDENTIFY frame, so having the current power mode of the phy
reported here similar to the NEGOTIATED LINK RATE seems appropriate.  This
also allows the short format for DISCOVER LIST response to work the same
(re question 1c and 1d below).
(1a) If we add two bits for "capability" in the IDENTIFY address frame,
should those capability bits be reflected in the DISCOVER response?
BD>> The expander capabilities reporting have already been proposed and
discussed some at Nov meeting for proposal 08-420.  A take-away from that
discussion was that Brad will be adding the "attached" version of the
cababilities bits of the received IDENTIFY frame.
(1b) Can we use the related two bit field for reporting Phy PS Condition
instead of the capability bits? Is there a need to report both the
capability bit field(s) in DISCOVER response as well as the actual Phy
Condition field?
BD>>  We want capable, enabled, and current state.  Should we just
incorporate the current power condition reporting into 08-420, and remove
|from 08-15?  That might be nice to keep all the SMP changes in one
proposal.
(1c) Presuming I have to move the two bit Phy Condition field elsewhere, is
it important that the field also show up in the short format DISCOVER
response? Most of those fields overlap with the fields intended to overlap
with IDENTIFY address frame usage, so if this is important we may have to
break that overlap rule.
(1d) I am expecting to move the two bit Phy Condition field either to byte
34 bits 7 & 6 or byte 6 bits 7 & 6. Any preference on these?
(2) There is a need to create two bits to enable use of partial and slumber
on expander phys. The most obvious choice is the CONFIGURE GENERAL request.
Would byte 8 of CONFIGURE GENERAL be a good choice?
BD>> 08-420 has already proposed PHY CONTROL... since we need to control
each phy individually.
(3) It has been suggested that the Protocol Specific Port mode page is not
the right choice for controlling the target device. It has been suggested
that the two enable bits for slumber and partial phy power conditions
should be in the Enhanced Phy Control mode page (page 19h, subpage 3). I
think the best place is byte 19 bits 2 & 1. Any disagreement with this?
Please post opinions to me or to the reflector on these options by Dec. 12.
*
* 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