SAS-2 SMP function DESCRIPTOR LENGTH fields

Elliott, Robert (Server Storage) Elliott at hp.com
Tue May 27 18:29:30 PDT 2008


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

Here is a topic for the 5/28 SAS-2 letter ballot call.
Brad Besmer (LSI) submitted this comment on SAS-2:
	We should consider adding the size of the all descriptors to the
"header" of each
	SMP response that contains descriptors (similar to REPORT
SELF-CONFIGURATION
	STATUS), if they do not already have such a field.
All the frames with descriptor lists use a NUMBER OF DESCRIPTORS field to
define the number of list entries, so at least that's consistent.
Three of the response frames already include a DESCRIPTOR LENGTH field:
- REPORT SELF-CONFIGURATION STATUS response has a SELF-CONFIGURATION [STATUS]
DESCRIPTOR LENGTH field
  (byte 12; the NUMBER OF field is in byte 19; descriptor list begins at byte
20)
- DISCOVER LIST response has a [DISCOVER LIST] DESCRIPTOR LENGTH field
  (byte 12; the NUMBER OF field is in byte 9; descriptor list begins at byte
48)
- REPORT PHY EVENT LIST response has a PHY EVENT LIST DESCRIPTOR LENGTH field
  (byte 10; the NUMBER OF field is in byte 15; descriptor list begins at byte
16)
Three of the response frames have room to add a DESCRIPTOR LENGTH field:
- REPORT ZONE PERMISSION TABLE response has room
  (bytes 8-13 are reserved; the NUMBER OF field is in byte 15; descriptor
list begins at byte 16)
- REPORT EXPANDER ROUTE TABLE LIST response has room
  (bytes 16-18, 20-31 are reserved; the NUMBER OF field is in bytes 10-11;
descriptor list begins at byte 32)
- REPORT PHY EVENT response has room
  (bytes 6-8, 10-14 are reserved; the NUMBER OF field is in byte 15;
descriptor list begins at byte 16)
One of the response frames does not have room:
- REPORT BROADCAST response does not have room (the NUMBER OF field is in
byte 7; descriptor list begins at byte 8)
A DESCRIPTOR LENGTH field is not absolutely necessary.	However, it:
- makes it easier for the application client to allocate memory
- makes it easier for the application client to skip over data that it
doesn't care about (e.g. to access fields beyond the descriptor list added in
a future version)
- lets us increase the descriptor length in a future version, relying on
current application clients to ignore any extra fields they don't understand
(see proposal 7a below). This helps them work better with old, current, and
future device servers.
Should I:
1. Add DESCRIPTOR LENGTH fields to the three response frames that have room?
2. Add 4 bytes to the REPORT EXPANDER ROUTE TABLE LIST response and include a
DESCRIPTOR LENGTH field?
3. Reduce the NUMBER OF field in REPORT EXPANDER ROUTE TABLE LIST to one byte
to match the others?  The descriptor is 16 bytes long, so one frame can only
hold 61 of them.  A one byte field is plenty.
4. Move the NUMBER OF field in REPORT EXPANDER ROUTE TABLE LIST to byte 31?
5. Move the NUMBER OF field in DISCOVER LIST to byte 47?
6a. Add a rule that the management application client should ignore fields in
a response frame that are beyond the response frame length it understands?
or 6b. Add a rule that the management application client should consider it
an error if it detects fields in a response frame that are beyond the request
length it understands?
7a. Add a rule that the management application client should ignore fields in
a response descriptor that are beyond the descriptor length it understands?
or 7b. Add a rule that the management application client should consider it
an error if it detects fields in a response descriptor that are beyond the
descriptor length it understands?
-----
Although the comment was only on response frames, request frames deserve
similar consideration (device servers have to support old, current, and
future application clients too).
Of the request frames with descriptor lists:
- CONFIGURE ZONE PERMISSION TABLE request has room
  (the NUMBER OF field is in byte 7; descriptor list begins at byte 16)
- CONFIGURE PHY EVENT request has room
  (the NUMBER OF field is in byte 11; descriptor list begins at byte 12)
- CONFIGURE ZONE PHY INFORMATION request does not have room
  (the NUMBER OF field is in byte 7; descriptor list begins at byte 8)
Should I:
9. Add DESCRIPTOR LENGTH fields to CONFIGURE ZONE PERMISSION TABLE and
CONFIGURE PHY EVENT?
8. Add 4 bytes to CONFIGURE ZONE PHY INFORMATION request and include a
DESCRIPTOR LENGTH field?
10. Move the NUMBER OF field in CONFIGURE ZONE PERMISSION TABLE to byte 15?
11a. Add a rule that the management device server shall ignore fields in a
request frame that are beyond the request frame length it understands?
or 11b. Add a rule that the management device server shall report an error if
it detects fields in a request frame that are beyond the request frame length
it understands?
12a. Add a rule that the management device server shall ignore fields in a
request descriptor that are beyond the descriptor length it understands?
or 12b. Add a rule that the management device server shall report an error if
it detects fields in a request descriptor that are beyond the descriptor
length it understands?
---
Rob Elliott, HP Industry Standard Server Storage



More information about the T10 mailing list