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.
"Elliott, Robert (Server
Storage)" <Elliott@hp.com> Sent by: owner-t10@t10.org
09/11/2007 06:50 PM
To
<t10@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.
From: owner-t10@t10.org [mailto:owner-t10@t10.org]
On Behalf Of George Penokie
Sent: Tuesday, September 04, 2007 12:54 PM
To: t10@t10.org
Cc: laurels@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?