Addition of REQUEST LENGTH field to SMP frame

George Penokie gop at us.ibm.com
Wed Sep 12 14:06:38 PDT 2007


Formatted message: <A HREF="r0709126_f.htm">HTML-formatted message</A>

Rob,
You state:
SAS-2 targets are required to check the value in byte 3, since it is now a 
defined REQUEST LENGTH field.  A request length of 00h means the length is 
as defined in SAS-1.1; non-zero values mean it's grown longer (or 
shorter).  As of sas2r11, if the request frame is shorter than the target 
would like, it assumes all the missing fields are set to zero.
That statement is correct for all the SMP functions except Report General 
and Report Manufacturer Information. Both of those have a zero in the 
REQUEST LENGTH field regardless of whether SAS 1.1 or SAS 2 is supported. 
The Report Manufacturer Information is currently not an issue because the 
response length is the same in both cases (i.e, 64 bytes). However, the 
Report General for SAS 1.1 has a response length of 32 bytes where SAS 2 
has a response length of 64 bytes. That has, at least, the following 
problem that could easily cause interoperability. 
- If a SAS 2 expander receives a Report General it has no way of knowing 
if the originating device is a SAS 1.1 or a SAS 2 so it has no way what 
length to use in the response. That, of course, have not a problem for a 
SAS 2 originating device as it should set up it's receive buffers to the 
longer size, however, a SAS 1.1 originating device has not clue so it will 
get a buffer overflow error on a critical SMP function. That is 
unacceptable.
This will have to be solved before SAS 2.0 exits letter ballot as the 
current behavior is unacceptable, so we can do it now or we can do it 
then. One reasonable solution:
-Add a bit into the Report General function that would indicate that it is 
requesting the SAS-2 response. A zero value means return SAS 1.1 response. 
A value of 1 means return SAS 2 or greater response. There also needs to 
be a bit in the response indicating if the expander support the long 
(i.e., SAS 2) version of responses.
The down side is that a device that wants to use SAS-2 SMP functions would 
have to send 2 Report General functions to figure out if the expander 
supports SAS 2 or not. 
Another down side is that a SAS 1.1 expander may reject the SMP with a 
reserved field set to 1 but that would also be an indication that the 
expander was SAS 1.1. Of course returning errors to determine support is 
not a good architecture. But the only way to prevent that is to send the 
information in the IDENTIFY address frame which some consider 
unacceptable.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
"Elliott, Robert (Server Storage)" <Elliott at hp.com> 
Sent by: owner-t10 at t10.org
09/11/2007 06:50 PM
To
<t10 at t10.org>
cc
Subject
RE: Addition of REQUEST LENGTH field to SMP frame
I think SMP software developers would be happier with a full-fledged 
VERSION field, distinguishing between both major (SAS-2, SAS-3, ...) and 
minor revisions (SAS-2 revision 10, revision 11, ...).	We could use the 
SPC-4 version descriptor values, but that format requires 2 bytes.
SAS-1.1 targets were neither required to check nor prohibited from 
checking byte 3 (which was labeled Reserved).  There was no SMP response 
specifically defined to report a non-zero value in a reserved field, so 
they must resort to the generic SMP FUNCTION FAILED response if they care. 
 If the request frame is larger than SAS-1.1, they report INVALID REQUEST 
FRAME LENGTH - the unclear case is when the request frame is the correct 
SAS-1.1 length, but byte 3 contains a nonzero value.
SAS-2 targets are required to check the value in byte 3, since it is now a 
defined REQUEST LENGTH field.  A request length of 00h means the length is 
as defined in SAS-1.1; non-zero values mean it's grown longer (or 
shorter).  As of sas2r11, if the request frame is shorter than the target 
would like, it assumes all the missing fields are set to zero.
The IDENTIFY address frame doesn't seem the best place for this kind of 
application layer version information; that frame is generally used for 
lower-level information needed to communicate to the target port (you 
usually retrieve it from the attached expander, or from initiator 
vendor-specific registers if directly attached). 
I'd prefer to put this information into the REPORT GENERAL response within 
the SAS-1.1 length of 6 dwords (e.g., in byte 8, or within bytes 20-27). 
Software can send REPORT GENERAL with the REQUEST LENGTH field set to 00h 
to retrieve those 6 dwords, then start using non-zero REQUEST LENGTH 
values if the target reports that it supports SAS-2.
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George 
Penokie
Sent: Tuesday, September 04, 2007 12:54 PM
To: t10 at t10.org
Cc: laurels at us.ibm.com
Subject: Addition of REQUEST LENGTH field to SMP frame
Some time ago a REQUEST LENGTH field was added into the SMP functions. 
However, there was no way placed into SAS-2 to for an initiator to 
determine if an SMP device supports this SAS-2 request length field 
(verses the SAS 1.1 with a value of zero in that byte). 
To resolve this I will be proposing a bit in the IDENTIFY address frame 
that will indicate if the SMP device supports a length field in the SMP 
function. Any comments? 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208yes 



More information about the T10 mailing list