SPC-4 question on disconnect-reconnect mode page parameter

Penokie, George George.Penokie at lsi.com
Mon Jan 26 11:24:38 PST 2009


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

A few comments.
First Burst Size and Maximum Burst Size may sound like they should be similar
but they are totally unrelated. The size specified in one never was intended
to, nor does it, have any relation to the size specified in the other.
On the issue about 512 being the size incrementor. That was just a convenient
number to pick at would allow larger sizes that was possible in the limited
field space. Devices that have other logical block sizes (e.g., 520 bytes)
have been around long before there was any DIF defined and they managed to
work just fine with a 512 incrementor.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Sheffield,
Bob
Sent: Monday, January 26, 2009 12:14 PM
To: Kevin D Butt
Cc: Knight, Frederick; Gerry.Houlder at seagate.com;
Narayan.Ayalasomayajula at emulex.com; owner-t10 at t10.org; t10 at t10.org
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
Sorry for the technical errors in my earlier posting.
Each 512-byte burst increment counts bytes of frame payload, whether it's a
DIF-enabled READ/WRITE, a legacy READ/WRITE, or some other command like MODE
SENSE or WRITE BUFFER. DIF (if present) is part of the frame payload (the
transport layer doesn't know if DIF is present or not), and so DIF counts
towards the 512 bytes of the burst increment it falls within. So, for
example, if the device is formatted to 512+DIF (520 total per block), and a
WRITE(10) command specifies WRPROTECT = 001b (transfer DIF), the first burst
increment transferred contains 512 bytes for the first block specified, and
the second burst increment contains the 8-bytes of DIF for the first block,
and the first 504 bytes of the second block, etc...
FIRST BURST SIZE and MAXIMUM BURST SIZE should be specified the same way.
Implementations that support first burst size are no doubt implemented so as
to count bytes of frame payload (which includes DIF) as part of the burst
count. If the standard were modified to force larger (frame payload) bursts
when DIF is present, it would likely break some existing implementations, so
that is not a reasonable path to take.
Bob Sheffield
Engenio Storage Group
MegaRAID Architecture
LSI Corporation

www.lsi.com<<a href="http://www.lsi.com/&gt">http://www.lsi.com/&gt;
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Monday, January 26, 2009 10:52 AM
To: Sheffield, Bob
Cc: Knight, Frederick; Gerry.Houlder at seagate.com;
Narayan.Ayalasomayajula at emulex.com; owner-t10 at t10.org; t10 at t10.org
Subject: RE: SPC-4 question on disconnect-reconnect mode page parameter
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