A SAS Outstanding Xfer_RDY Question.

George Penokie gop at us.ibm.com
Tue Jul 1 06:23:48 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 004962BC86256D56_=
Content-Type: text/plain; charset="us-ascii"


Bob, 

A value of zero in the first burst size field in the
disconnect/reconnected mode page turns off first burst. There is no need
for any other mechanism. If initiators start making changes to mode
pages without cooperation from other initiators things will get ugly
real quick but so be it, that's the way mode pages work and have always
worked. There are many examples of this with first burst only being one.
I believe the way it is defined is just fine and that adding anything to
the command to turn it on/off would only add complexity with no added
practical value.

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880





	"Nixon, Bob" <Bob.Nixon at emulex.com> 
Sent by: owner-t10 at t10.org 


06/30/2003 03:51 PM 
        
        To:        t10 at t10.org 
        cc:         
        Subject:        RE: A SAS Outstanding Xfer_RDY Question. 





* From the T10 Reflector (t10 at t10.org), posted by:
* "Nixon, Bob" <Bob.Nixon at Emulex.Com>
*
How does an initiator indicate to a target whether to use first burst or
not?  

Both SAM-3 and SAS specify that the Send SCSI Command and SCSI Command
Received transport services include a parameter indicating whether first
burst is enabled or not.  The prior discussion in this thread makes it
obvious the choice of the initiator has to be communicated to the target
in
order that XFER_RDY can be sent when needed.

We could claim setting the first burst size to zero in the
disconnect-reconnect mode page accomplishes the necessary communication.
But this would lead to possibly disastrous inefficiency...the first
burst
size setting affects all initiators for a port and can be changed by any
of
them at any time.  Every initiator would have to assure the correct mode
page setting before every command.  The means of doing this are messy at
best.

FCP-2 is the only other protocol that I could find that supports first
burst.  It implements the required means to disable first burst by a
per-initiator login flag (though this falls a little short of the
per-command implication of the transport service specification in
SAM-3).  I
would recommend SAS 1.1 meet the requirement by adding a bit to the SSP
COMMAND IU indicating whether the target is to honor (bit=0) or ignore
(bit=1) first burst size for the command.

I'll write this up for next week unless one of you educates me before
then.


  - Bob

-----Original Message-----
From: Evans, Mark [mailto:Mark_Evans at maxtor.com]
Sent: Friday, June 27, 2003 2:29 PM
To: 'Sheffield, Robert L'; t10 at t10.org
Subject: RE: A SAS Outstanding Xfer_RDY Question.


* From the T10 Reflector (t10 at t10.org), posted by:
* "Evans, Mark" <Mark_Evans at maxtor.com>
*
Hi Bob,

If the value in the FIRST BURST SIZE field is not zero, all of the rules
for
first burst are the same as for an XFER_RDY, that is, a SAS target port
shall not send an XFER_RDY until all of the data for the first burst has
been sent.  This is explicit in the standard in 10.2.6.1.5 FIRST BURST
SIZE
field.  The following is the fourth paragraph in that clause:

"If the amount of data to be transferred for the command is less than
the
amount of data specified by the FIRST BURST SIZE field, the SSP target
port
shall not transmit an XFER_RDY frame for the command.  If the amount of
data
to be transferred for the command is greater than the amount of data
specified by the FIRST BURST SIZE field, the SSP target port shall
transmit
an XFER_RDY frame after it has received all of the data specified by the
FIRST BURST SIZE field from the initiator.  All data for the command is
not
required to be transferred during the same connection in which the
command
is transferred."

I guess we could make this stronger by changing, "...the SSP target port
shall transmit an XFER_RDY frame after it has received all of the data
specified by the FIRST BURST SIZE field..." to "...the SSP target port
shall
not transmit an XFER_RDY frame until it has received all of the data
specified by the FIRST BURST SIZE field...", but the first was intended
to
mean the second.

Regards,

Mark Evans
Maxtor Corporation

-----Original Message-----
From:                  Sheffield, Robert L
[mailto:robert.l.sheffield at intel.com] 
Sent:                 Friday, June 27, 2003 12:44 PM
To:                 t10 at t10.org
Subject:                 RE: A SAS Outstanding Xfer_RDY Question.

* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
I didn't see this the last time I looked into the question, but it does
look
like only one XFER_RDY can be outstanding at a time. I looked into it
before
because of a question about the first burst transfer, and what sort of
timeout might occur in case the first burst never completes. I assumed
that
since the first burst is an implicit XFER_RDY, that the timeout would be
the
same whether it's the first burst or a transfer associated with an
explicit
XFER_RDY (the Initiator Response Timeout timer). What I'm left wondering
now
is if the target must wait for the first burst transfer to complete
before
sending the first XFER_RDY? Is that the intent, and is is stated
anywhere?

Bob Sheffield

-----Original Message-----
From: Sriram Srinivasan [mailto:srirams at lsil.com]
Sent: Friday, June 27, 2003 11:31 AM
To: t10 at t10.org 
Subject: RE: A SAS Outstanding Xfer_RDY Question.


* From the T10 Reflector (t10 at t10.org), posted by:
* Sriram Srinivasan <srirams at lsil.com>
*

 If sas-r04a.pdf is the current SAS spec, I see that in "10.2.1.8
Receive 
Data-Out transport protocol service" it talks about limiting number of 
outstanding XFER_RDY frames per command to 1.  I don't see where it
allows 
more than 1 outstanding XFER_RDY frame per command.
 
 
 \Sriram\
 
" 
" * From the T10 Reflector (t10 at t10.org), posted by:
" * "Bill Galloway" <BillG at breatech.com>
" *
" I believe the current SAS spec allows more than one outstanding
XFER_RDY 
per
" command.  There was some talk of limiting this but it never went
anywhere.
" 
" Bill Galloway
" Pivot3, Inc.
" BillG at pivot3.com
" P: (281) 530-3063
" F: (281) 988-0398 
" 
" -----Original Message-----
" From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Whitehill,
" Cliff
" Sent: Friday, June 27, 2003 11:03 AM
" To: t10 at t10.org
" Subject: A SAS Outstanding Xfer_RDY Question.
" 
" 
" * From the T10 Reflector (t10 at t10.org), posted by:
" * "Whitehill, Cliff" <cwhitehi at lsil.com>
" *
" All,
" 
" My current understanding is that for SAS you can have only one
outstanding
" Xfer_RDY per command.  Is this true? If so, where does it say this in
the
" SAS specification?
" 
" Regards,
" 
" --------------------------------------------
" Clifford A. Whitehill
" Staff Systems Engineer
" LSI Logic Corp.
" 2001 Danfield Ct.
" Fort Collins, CO. 80525
" Tel: 970-206-5024
" Fax: 970-206-5244
" email: cliff.whitehill at lsil.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



----------------------------------------------------------------------
                "FORGET NOT THAT THE EARTH DELIGHTS TO FEEL YOUR BARE
FEET,
              AND THE WINDS LONG TO PLAY WITH YOUR HAIR"
                                         -Khalil Gibran

Sriram Srinivasan                       Sriram.Srinivasan at lsil.com
ASIC Design Engineer, LSI Logic,
2001 Danfield Ct.,
Phone: 970-206-5847
Fort Collins, CO 80525
FAX  : 970-206-5244
----------------------------------------------------------------------

*
* 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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




--=_alternative 004962BC86256D56_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Bob,</font>
<br>
<br><font size=2 face="sans-serif">A value of zero in the first burst size field in the disconnect/reconnected mode page turns off first burst. There is no need for any other mechanism. If initiators start making changes to mode pages without cooperation from other initiators things will get ugly real quick but so be it, that's the way mode pages work and have always worked. There are many examples of this with first burst only being one. I believe the way it is defined is just fine and that adding anything to the command to turn it on/off would only add complexity with no added practical value.<br>
<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Nixon, Bob" <Bob.Nixon at emulex.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">06/30/2003 03:51 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;t10 at t10.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: A SAS Outstanding Xfer_RDY Question.</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Nixon, Bob" <Bob.Nixon at Emulex.Com&gt;<br>
*<br>
How does an initiator indicate to a target whether to use first burst or<br>
not? &nbsp;<br>
<br>
Both SAM-3 and SAS specify that the Send SCSI Command and SCSI Command<br>
Received transport services include a parameter indicating whether first<br>
burst is enabled or not. &nbsp;The prior discussion in this thread makes it<br>
obvious the choice of the initiator has to be communicated to the target in<br>
order that XFER_RDY can be sent when needed.<br>
<br>
We could claim setting the first burst size to zero in the<br>
disconnect-reconnect mode page accomplishes the necessary communication.<br>
But this would lead to possibly disastrous inefficiency...the first burst<br>
size setting affects all initiators for a port and can be changed by any of<br>
them at any time. &nbsp;Every initiator would have to assure the correct mode<br>
page setting before every command. &nbsp;The means of doing this are messy at<br>
best.<br>
<br>
FCP-2 is the only other protocol that I could find that supports first<br>
burst. &nbsp;It implements the required means to disable first burst by a<br>
per-initiator login flag (though this falls a little short of the<br>
per-command implication of the transport service specification in SAM-3). &nbsp;I<br>
would recommend SAS 1.1 meet the requirement by adding a bit to the SSP<br>
COMMAND IU indicating whether the target is to honor (bit=0) or ignore<br>
(bit=1) first burst size for the command.<br>
<br>
I'll write this up for next week unless one of you educates me before then.<br>
<br>
<br>
 &nbsp; - Bob<br>
<br>
-----Original Message-----<br>
From: Evans, Mark [mailto:Mark_Evans at maxtor.com]<br>
Sent: Friday, June 27, 2003 2:29 PM<br>
To: 'Sheffield, Robert L'; t10 at t10.org<br>
Subject: RE: A SAS Outstanding Xfer_RDY Question.<br>
<br>
<br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Evans, Mark" <Mark_Evans at maxtor.com&gt;<br>
*<br>
Hi Bob,<br>
<br>
If the value in the FIRST BURST SIZE field is not zero, all of the rules for<br>
first burst are the same as for an XFER_RDY, that is, a SAS target port<br>
shall not send an XFER_RDY until all of the data for the first burst has<br>
been sent. &nbsp;This is explicit in the standard in 10.2.6.1.5 FIRST BURST SIZE<br>
field. &nbsp;The following is the fourth paragraph in that clause:<br>
<br>
"If the amount of data to be transferred for the command is less than the<br>
amount of data specified by the FIRST BURST SIZE field, the SSP target port<br>
shall not transmit an XFER_RDY frame for the command. &nbsp;If the amount of data<br>
to be transferred for the command is greater than the amount of data<br>
specified by the FIRST BURST SIZE field, the SSP target port shall transmit<br>
an XFER_RDY frame after it has received all of the data specified by the<br>
FIRST BURST SIZE field from the initiator. &nbsp;All data for the command is not<br>
required to be transferred during the same connection in which the command<br>
is transferred."<br>
<br>
I guess we could make this stronger by changing, "...the SSP target port<br>
shall transmit an XFER_RDY frame after it has received all of the data<br>
specified by the FIRST BURST SIZE field..." to "...the SSP target port shall<br>
not transmit an XFER_RDY frame until it has received all of the data<br>
specified by the FIRST BURST SIZE field...", but the first was intended to<br>
mean the second.<br>
<br>
Regards,<br>
<br>
Mark Evans<br>
Maxtor Corporation<br>
<br>
 -----Original Message-----<br>
From: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Sheffield, Robert L [mailto:robert.l.sheffield at intel.com] <br>
Sent: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Friday, June 27, 2003 12:44 PM<br>
To: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; t10 at t10.org<br>
Subject: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; RE: A SAS Outstanding Xfer_RDY Question.<br>
<br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Sheffield, Robert L" <robert.l.sheffield at intel.com&gt;<br>
*<br>
I didn't see this the last time I looked into the question, but it does look<br>
like only one XFER_RDY can be outstanding at a time. I looked into it before<br>
because of a question about the first burst transfer, and what sort of<br>
timeout might occur in case the first burst never completes. I assumed that<br>
since the first burst is an implicit XFER_RDY, that the timeout would be the<br>
same whether it's the first burst or a transfer associated with an explicit<br>
XFER_RDY (the Initiator Response Timeout timer). What I'm left wondering now<br>
is if the target must wait for the first burst transfer to complete before<br>
sending the first XFER_RDY? Is that the intent, and is is stated anywhere?<br>
<br>
Bob Sheffield<br>
<br>
-----Original Message-----<br>
From: Sriram Srinivasan [mailto:srirams at lsil.com]<br>
Sent: Friday, June 27, 2003 11:31 AM<br>
To: t10 at t10.org</font>
<br><font size=2 face="Courier New">Subject: RE: A SAS Outstanding Xfer_RDY Question.<br>
<br>
<br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* Sriram Srinivasan <srirams at lsil.com&gt;<br>
*<br>
<br>
 &nbsp;If sas-r04a.pdf is the current SAS spec, I see that in "10.2.1.8 Receive <br>
Data-Out transport protocol service" it talks about limiting number of <br>
outstanding XFER_RDY frames per command to 1. &nbsp;I don't see where it allows <br>
more than 1 outstanding XFER_RDY frame per command.<br>
 &nbsp;<br>
 &nbsp;<br>
 &nbsp;\Sriram\<br>
 &nbsp;<br>
" <br>
" * From the T10 Reflector (t10 at t10.org), posted by:<br>
" * "Bill Galloway" <BillG at breatech.com&gt;<br>
" *<br>
" I believe the current SAS spec allows more than one outstanding XFER_RDY <br>
per<br>
" command. &nbsp;There was some talk of limiting this but it never went anywhere.<br>
" <br>
" Bill Galloway<br>
" Pivot3, Inc.<br>
" BillG at pivot3.com<br>
" P: (281) 530-3063<br>
" F: (281) 988-0398 <br>
" <br>
" -----Original Message-----<br>
" From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Whitehill,<br>
" Cliff<br>
" Sent: Friday, June 27, 2003 11:03 AM<br>
" To: t10 at t10.org<br>
" Subject: A SAS Outstanding Xfer_RDY Question.<br>
" <br>
" <br>
" * From the T10 Reflector (t10 at t10.org), posted by:<br>
" * "Whitehill, Cliff" <cwhitehi at lsil.com&gt;<br>
" *<br>
" All,<br>
" <br>
" My current understanding is that for SAS you can have only one outstanding<br>
" Xfer_RDY per command. &nbsp;Is this true? If so, where does it say this in the<br>
" SAS specification?<br>
" <br>
" Regards,<br>
" <br>
" --------------------------------------------<br>
" Clifford A. Whitehill<br>
" Staff Systems Engineer<br>
" LSI Logic Corp.<br>
" 2001 Danfield Ct.<br>
" Fort Collins, CO. 80525<br>
" Tel: 970-206-5024<br>
" Fax: 970-206-5244<br>
" email: cliff.whitehill at lsil.com<br>
" <br>
" *<br>
" * For T10 Reflector information, send a message with<br>
" * 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
" <br>
" *<br>
" * For T10 Reflector information, send a message with<br>
" * 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
<br>
<br>
<br>
----------------------------------------------------------------------<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "FORGET NOT THAT THE EARTH DELIGHTS TO FEEL YOUR BARE FEET,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AND THE WINDS LONG TO PLAY WITH YOUR HAIR"<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-Khalil Gibran<br>
<br>
 Sriram Srinivasan &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Sriram.Srinivasan at lsil.com<br>
 ASIC Design Engineer, LSI Logic,<br>
 2001 Danfield Ct., &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Phone: 970-206-5847<br>
 Fort Collins, CO 80525 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX &nbsp;: 970-206-5244<br>
----------------------------------------------------------------------<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
</font>
<br>
<br>
--=_alternative 004962BC86256D56_=--




More information about the T10 mailing list