FCP-3: Obsolete FCP_DL and FCP_BIDIRECTIONAL_DL

Robert Snively rsnively at Brocade.COM
Thu Sep 30 14:49:09 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Robert Snively" <rsnively at Brocade.COM>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C4A737.50BECB1C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Phil reflects my original statement that the SCSI command set and its
data
counts are at a different architectural and implementation level than
the
FCP_DL.  The SCSI command set reflects a software-like understanding
between the application client and the device server about the length
of each logical block and the number of logical blocks.  The FCP_DL
reflects a hardware-like understanding of the number of bytes that
will flow to or from host memory hardware as FCP_DATA IUs for a
single exchange.  That hardware understanding is useful in setting up
and verifying the properties (including protection) of appropriate
buffers=20
in both the host memory and the attached device.
=20
I continue to believe that both these values are interesting and =
useful.
They provide important pieces of information to different levels of the
architecture.  They are especially useful to certain virtualization
implementations
that choose not to have a full understanding of the underlying data
properties.
=20
Just because some hosts choose not to interpret the response codes
associated with errors does not mean that these are useless
parameters.  It simply adds another requirement for presenting
the information, like the one Dave has been preparing.
=20
However, if all the HBA, RAID, and virtualizer implementers agree that
they no longer need FCP_DL for FCP devices, I would be swayed from
my position.  Note that Dot Hill is one of those RAID implementors, and
they seem to find the value useful.=20
=20
Bob

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of
phil.colline at dothill.com
Sent: Thursday, September 30, 2004 1:31 PM
To: david_peterson at cnt.com
Cc: t10 at t10.org; t11_3 at mail.t11.org
Subject: Re: FCP-3: Obsolete FCP_DL and FCP_BIDIRECTIONAL_DL


I believe it would be a big mistake to obsolete FCP_DL.  The only other
way to determine the transfer size is to crack the payload (CDB) which
would put undue burden on hardware or software layers that currently
rely exclusively on FCP_DL.  While it is a true statement that the
FCP_DL is redundant with the CDB transfer length, forcing the many
existing implementations relying on FCP_DL to utilize the CDB instead
over an orthogonal issue is not the proper solution.  It also seems =
like
an invitation to renew a whole new set of interoperability problems.
=20
Regards,
=20
Phil
=20
=20
On Tue, 28 Sep 2004, David Peterson (Eng) wrote:
=20
> * From the T10 Reflector ( t10 at t10.org <mailto:t10 at t10.org> ), posted
by:
> * "David Peterson \(Eng\)" < david_peterson at cnt.com
<mailto:david_peterson at cnt.com> >
> *
> Howdy All,
>=20
> During the discussion of T10/03-393 at the recent CAP meeting the
notion
> of obsoleting the FCP_DL and FCP_BIDIRECTIONAL_READ_DL fields in =
FCP-3
> was mentioned.
>=20
> A bit of history that got us to this point:
>=20
> The FCP-3 working has been looking at an issue where the FCP_DL value
is
> not equal to the CDB transfer length. The goal is/was to provide a
> method to report this condition to the upper layer(s). The need for
this
> method drops significantly if the FCP_DL fields are obsolete. The
method
> may still have merit since there are other conditions such as the
WRDATA
> bit is set to one in a read type command and vice-versa. But no one
has
> really identified this is a problem case to date.
>=20
> Additional reasons to obsolete such as "its redundent with the CDB
> transfer length" and "FCP is the only SCSI transport protocol that
> specifies a data length" have been mentioned.
>=20
> Please indicate any preferences for or against obsoleting the FCP_DL
and
> FCP_BIDIRECTIONAL_DL fields along with your reasoning.
>=20
> Thanks...Dave
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to  majordomo at t10.org
<mailto:majordomo at t10.org>=20
>=20
=20

=20


------_=_NextPart_001_01C4A737.50BECB1C
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>



<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>Phil=20
reflects my original statement that the SCSI command set and its=20
data</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>counts=20
are at a different architectural and implementation level than=20
the</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>FCP_DL.&nbsp; The SCSI command set reflects a software-like=20
understanding</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>between the application client and the device server about the =

length</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>of=20
each logical block and the number of logical blocks.&nbsp; The=20
FCP_DL</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>reflects a hardware-like understanding of the number of bytes=20
that</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>will=20
flow to or from host memory hardware as FCP_DATA IUs for =
a</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>single=20
exchange.&nbsp; That hardware understanding is useful in setting=20
up</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>and=20
verifying the properties (including protection)&nbsp;of appropriate =
buffers=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>in=20
both the host memory </FONT></SPAN><SPAN =
class=3D005213521-30092004><FONT=20
face=3DArial color=3D#0000ff size=3D2>and the attached =
device.</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
continue to believe that both these values are interesting and=20
useful.</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>They=20
provide important pieces of information to different levels of=20
the</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>architecture.&nbsp; They are especially useful to certain =
virtualization=20
implementations</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>that=20
choose not to have a full understanding of the underlying=20
data</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>properties.</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>Just=20
because some hosts choose not to interpret the response=20
codes</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>associated with errors does not mean that these are=20
useless</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>parameters.&nbsp; It simply adds another requirement for=20
presenting</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>the=20
information, like the one Dave has been preparing.</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>However, if all the HBA, RAID, and virtualizer implementers =
agree=20
that</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>they=20
no longer need FCP_DL for FCP devices, I would be swayed=20
from</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>my=20
position.&nbsp; Note that Dot Hill is one of those RAID implementors,=20
and</FONT></SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff size=3D2>they=20
seem to find the value useful.</FONT>&nbsp;</SPAN></DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D005213521-30092004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Bob</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> owner-t10 at t10.org =

  [mailto:owner-t10 at t10.org]<B>On Behalf Of=20
  </B>phil.colline at dothill.com<BR><B>Sent:</B> Thursday, September 30, =
2004 1:31=20
  PM<BR><B>To:</B> david_peterson at cnt.com<BR><B>Cc:</B> t10 at t10.org;=20
  t11_3 at mail.t11.org<BR><B>Subject:</B> Re: FCP-3: Obsolete FCP_DL and=20
  FCP_BIDIRECTIONAL_DL<BR><BR></FONT></DIV>
  <DIV class=3DSection1><PRE><FONT face=3D"Courier New" size=3D2><SPAN =
style=3D"FONT-SIZE: 10pt">I believe it would be a big mistake to =
obsolete FCP_DL.&nbsp; The only other way to determine the transfer =
size is to crack the payload (CDB) which would put undue burden on =
hardware or software layers that currently rely exclusively on =
FCP_DL.&nbsp; While it is a true statement that the FCP_DL is redundant =
with the CDB transfer length, forcing the many existing implementations =
relying on FCP_DL to utilize the CDB instead over an orthogonal issue =
is not the proper solution.&nbsp; It also seems like an invitation to =
renew a whole new set of interoperability =
problems.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">Regards,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">Phil<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">On Tue, 28 Sep 2004, =
David Peterson (Eng) wrote:<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> * From the T10 =
Reflector (t10 at t10.org), posted =
by:<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> * "David Peterson =
\(Eng\)" <<A =
href=3D"mailto:david_peterson at cnt.com">david_peterson at cnt.com><o:=
p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> =
*<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> Howdy =
All,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> =
During the discussion of T10/03-393 at the recent CAP meeting the =
notion<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> of obsoleting the FCP_DL =
and FCP_BIDIRECTIONAL_READ_DL fields in =
FCP-3<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> was =
mentioned.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> A =
bit of history that got us to this =
point:<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> The =
FCP-3 working has been looking at an issue where the FCP_DL value =
is<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> not equal to the CDB =
transfer length. The goal is/was to provide =
a<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> method to report this =
condition to the upper layer(s). The need for =
this<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> method drops =
significantly if the FCP_DL fields are obsolete. The =
method<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> may still have merit =
since there are other conditions such as the =
WRDATA<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> bit is set to one in a =
read type command and vice-versa. But no one =
has<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> really identified this is =
a problem case to date.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> =
Additional reasons to obsolete such as "its redundent with the =
CDB<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> transfer length" and "FCP =
is the only SCSI transport protocol =
that<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> specifies a data length" =
have been mentioned.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> =
Please indicate any preferences for or against obsoleting the FCP_DL =
and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> FCP_BIDIRECTIONAL_DL =
fields along with your =
reasoning.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> =
Thanks...Dave<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> =
*<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> * For T10 Reflector =
information, send a message with<o:p></o:p></SPAN></FONT></PRE><PRE><FON=
T face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> * =
'info t10' (no quotes) in the message body to <A =
href=3D"mailto:majordomo at t10.org">majordomo at t10.org<o:p></o:p></SPAN=
></FONT></PRE><PRE><FONT face=3D"Courier New" size=3D2><SPAN =
style=3D"FONT-SIZE: =
10pt">><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HT=
ML>

------_=_NextPart_001_01C4A737.50BECB1C--




More information about the T10 mailing list