To: "Elliott, Robert (Server Storage)" <Elliott@hp.com> Cc: t10@t10.org, laurels@us.ibm.com Subject: RE: Addition of REQUEST LENGTH field to SMP frame From: George Penokie <gop@us.ibm.com> Date: Wed, 12 Sep 2007 16:06:38 -0500 X-Message-Number: 8060 Formatted message: HTML-formatted message 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@us.ibm.com Internal: 553-5208 External: 507-253-5208 "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. -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott 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? Bye for now, George Penokie Dept 9A8 030-3 A410 E-Mail: gop@us.ibm.com Internal: 553-5208 External: 507-253-5208yes