SPC-4 question on disconnect-reconnect mode page parameter

Kevin D Butt kdbutt at us.ibm.com
Mon Jan 26 09:52:02 PST 2009


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0901263_f.htm">HTML-formatted message</a>

These fields are indeed related to what is needed in the transport. 
Separate the layers and focus only on the transport please.
This is what you would use to limit your maximum frame size you would 
allow in your transport.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
"Sheffield, Bob" <Bob.Sheffield at lsi.com>
To:
"Knight, Frederick" <Frederick.Knight at netapp.com>, 
"Gerry.Houlder at seagate.com" <Gerry.Houlder at seagate.com>, "t10 at t10.org" 
<t10 at t10.org>
Cc:
"Narayan.Ayalasomayajula at emulex.com" <Narayan.Ayalasomayajula at emulex.com>
Date:
01/26/2009 10:20 AM
Subject:
RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Bob" <Bob.Sheffield at lsi.com>
*
It's more complicated than that.
I belive MAXIMUM BURST SIZE and FIRST BURST SIZE should be specified the 
same way.
FIRST BURST SIZE is also specified in 512-byte increments. The question 
is, does the burst size (FIRST or MAXIMUM) have more to do with the 
blocksize or the transport. SAS has a maximum frame payload of 1024 bytes, 
so a FIRST BURST SIZE set to a value that is a multiple of 2 (times 512) 
works nicely, regardless of the underlying blocksize.
Would parameter rounding be a way to deal with this for target devices 
that prefer to align bursts on block boundaries with DIF?
Another issue - a device that supports transferring DIF is also required 
to support legacy commands (xxPROTECT = 0) that do not transfer DIF 
fields. Is the maximum burst size going to be different for one command 
versus another, depending on the setting of xxPROTECT?
I think what this means is the burst size is more tightly coupled to the 
requirements of the transport rather than the granularity of blocks within 
the device. 512 seemed like a reasonable "minimum chunk" for specifying 
burst sizes. But maybe both should be specified in bytes? If it's a big 
enough issue, then the solution is proably to define a new bit (probably 
|from the reserved byte 13) to specify that the burst sizes are specified 
in bytes rather than bits (or use the entire byte to specify a different 
value as the multiplier for burst size, with a value of zero meaning 512).
Bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight, 
Frederick
Sent: Monday, January 26, 2009 8:47 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
My opinion is that this information existed pre-DIF, and was not updated 
when protection information was added to SBC.  Yes, time makes more sense, 
but the values are already specified as 512-byte block based, not time 
based.
So, I would suggest that the proper interpretation is to read the word 
"data" as "user data".	The problem is that "user data" is defined in SBC, 
not in SPC, but here is the idea:
The MAXIMUM BURST SIZE field indicates the maximum amount of <user> data 
that the target port shall transfer during a single data transfer 
operation. This value is expressed in increments of 512 <user data> bytes 
(i.e., a value of one means 512 bytes <of user data>, two means 1 024 
bytes <of user
data>, etc.). The relationship, if any, between data transfer operations
and interconnect tenancies is defined in the individual SCSI transport 
protocol standards. A value of zero specifies there is no limit on the 
amount of <user> data transferred per data transfer operation.
The issue of course, is that "user data" is defined in SBC (and relates to 
protection information that is defined in SBC), but the above text is from 
SPC (where "user data" is not defined, and there is no concept of 
protection information).
Another choice might be to add something in SBC that further clarifies the 
SPC text, and more specifically states that the value in that field 
represents "user data".  Or, in SBC, you could say:
If protection information is enabled, then this value is expressed in 
increments...
If protection information is not enabled, then this value is expressed in 
increments...
Either way, it sounds like we'll be seeing a proposal at the next meeting 
to suggest how to deal with this issue. 
		 Fred Knight
		 NetApp
		 SAN Standards Technologist
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, January 23, 2009 2:02 PM
To: t10 at t10.org
Cc: Narayan.Ayalasomayajula at emulex.com
Subject: Re: SPC-4 question on disconnect-reconnect mode page parameter
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Most people think of the maximum burst size in terms of how long a system 
is willing to dedicate bandwidth to a particular task. The time concept is 
easier to keep in focus when it is related to bytes transferred, not a 
multiple of logical blocks that can vary in size.
	     Bill.Martin at emule
	     x.com
	     Sent by:
To 
	     owner-t10 at t10.org	       <t10 at t10.org>
cc 
<Narayan.Ayalasomayajula at emulex.com 
				       >
	     01/21/2009 04:46
Subject 
	     PM 		       SPC-4 question on
				       disconnect-reconnect mode page
				       parameter
In looking at the disconnect-reconnect mode page in SPC4r17, the 
definition for the MAXIMUM BURST SIZE is:
The MAXIMUM BURST SIZE field indicates the maximum amount of data that the 
target port shall transfer during a single data transfer operation. This 
value is expressed in increments of
512 bytes (i.e., a value of one means 512 bytes, two means 1 024 bytes, 
etc.). The relationship, if any, between data transfer operations and 
interconnect tenancies is defined in the individual SCSI transport 
protocol standards. A value of zero specifies there is no limit on the 
amount of data transferred per data transfer operation.
This works for devices that formatted for data in multiples of 512 bytes 
per block; however, this does not map well for devices that formatted for 
Protection information and the block size is 520 bytes.  I understand that 
the data transfer length can be easily compared to number of 512 byte 
blocks; however, if you want to have a max burst size of 32 blocks that 
are 520 bytes each then this field does not easily map to the number that 
you want because 33 would map to 32.49 520 byte blocks.  Was there any 
thought about tying this to the block size that a storage device was 
formatted for?
Thanks,
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com
*
* 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
*
* 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