Additional ADT Questions/Comments

Banther, Michael michael.banther at hp.com
Mon Jan 12 05:51:20 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Banther, Michael" <michael.banther at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C3D913.28938A96
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Bob,
=20
At present ADT allows the generation of a Transfer Ready before the
previous one has been fulfilled.  We've specified it in this way to
minimise delays in data throughput.  Does that shed any light?
=20
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503

-----Original Message-----
From: Robert Snively [mailto:rsnively at Brocade.COM]=20
Sent: 09 January 2004 10:44
To: Banther, Michael; t10 at t10.org
Cc: Towler, Russell; Davies, Myles
Subject: RE: Additional ADT Questions/Comments


Michael,
=20
I am not quite sure I understand your question.
=20
Transfer Ready is sent by a target to solicit required data from an
initiator.
It may do so in any order and with any overlap that it needs, =
consistent
with the posted capabilities of the initiator negotiated with the
requirements
of the target.  Checking for complete transfers in the presence of
overlapped
or out-of-order requests is one of those things that may encourage an
initiator to prohibit overlap and out-of-order requests.
=20
Each Transfer Ready must be fulfilled.  At least in Fibre Channel, the
protocol prohibits the generation of a new Transfer Ready before the
previous one has been fulfilled by using the transfer of initiative
function.
=20
Essentially, each Transfer Ready then becomes a stateless request
for data, with no further implication to the initiator.
=20
So I don't see any problems here.  What am I missing?
=20
Bob

-----Original Message-----
From: Banther, Michael [mailto:michael.banther at hp.com]
Sent: Friday, January 09, 2004 7:24 AM
To: t10 at t10.org
Cc: Towler, Russell; Davies, Myles
Subject: Additional ADT Questions/Comments


Regarding question 4 of my previous e-mail (dated 6 January 2004 and
attached), allowing a port to send multiple SCSI Transfer Ready IU's
with Buffer Offset values such that the buffer space allocated is less
than the sum of the Burst Lengths can potentially require a substantial
amount of storage in the receiving port.
=20
For example consider a foolish implementation that allocates 100 Kbytes
by sending 99 SCSI Transfer Ready IU's each with a Burst Length of 2
Kbytes where the Buffer Offset follows the sequence 0, 1K, 2K, ..., =
that
is the first SCSI Transfer Ready IU allocates 2 Kbytes, the second SCSI
Transfer Ready overlaps the buffer space of the first one such that the
total allocated equals 3 Kbytes, the third SCSI Transfer Ready IU
overlaps the second one such that the total allocated space equals 4
Kbytes, and so on.
=20
Because the receiver of the SCSI Transfer Ready IU's must fulfill them
with data as specified by the sender, the receiver cannot simply keep =
an
aggregate of the buffer space allocated.  Instead it must keep all of
the SCSI Transfer Ready IU's whose associated bursts have not been
satisfied.
=20
I believe that the SCSI Transfer Ready IU includes the Buffer Offset
field principally for error recovery.  However the absence of normative
text limiting the use of this field, implies an overly complex
implementation to ensure interoperability.
=20
Regards,
=20
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503
=20


------_=_NextPart_001_01C3D913.28938A96
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Message Hi=20 Bob,
  
 At=20 present ADT allows the generation of a Transfer Ready before the = previous one=20 has been fulfilled.  We've specified it in this way to minimise = delays in=20 data throughput.  Does that shed any light?
  
 Regards,
 Michael Banther
 Hewlett-Packard Ltd.
 +44=20 117 312 9503
 
-----Original Message-----
From: = Robert Snively=20 [mailto:rsnively at Brocade.COM] 
Sent: 09 January 2004=20 10:44
To: Banther, Michael; t10 at t10.org
Cc: = Towler,=20 Russell; Davies, Myles
Subject: RE: Additional ADT=20 Questions/Comments


 Michael,
  
 I am=20 not quite sure I understand your question.
  
 Transfer Ready is sent by a target to = solicit=20 required data from an initiator.
 It may do so in any order and with any = overlap that=20 it needs, consistent
 with the posted capabilities of the = initiator=20 negotiated with the requirements
 of the target.  Checking for complete = transfers=20 in the presence of overlapped
 or out-of-order requests is one of those = things that=20 may encourage an
 initiator to prohibit overlap and = out-of-order=20 requests.
  
 Each Transfer Ready must be = fulfilled.  At least=20 in Fibre Channel, the
 protocol prohibits the generation of a new = Transfer=20 Ready before the
 previous one has been fulfilled by using = the transfer=20 of initiative function.
  
 Essentially, each Transfer Ready then = becomes a=20 stateless request
 for data, with no further implication to = the=20 initiator.
  
 So I don't see any problems here.  = What am I=20 missing?
  
 Bob
 -----Original Message-----
From: Banther, = Michael=20 [mailto:michael.banther at hp.com]
Sent: Friday, January 09, = 2004=20 7:24 AM
To: t10 at t10.org
Cc: Towler, Russell; = Davies,=20 Myles
Subject: Additional ADT=20 Questions/Comments


 Regarding=20 question 4 of my previous e-mail (dated 6 January 2004 and = attached),=20 allowing a port to send multiple SCSI Transfer Ready IU's with = Buffer Offset=20 values such that the buffer space allocated is less than the sum of = the=20 Burst Lengths can potentially require a substantial amount of = storage in the=20 receiving port.
  
 For example=20 consider a foolish implementation that allocates 100 Kbytes by = sending 99=20 SCSI Transfer Ready IU's each with a Burst Length of 2 Kbytes where = the=20 Buffer Offset follows the sequence 0, 1K, 2K, ..., that is the = first SCSI=20 Transfer Ready IU allocates 2 Kbytes, the second SCSI Transfer = Ready=20 overlaps the buffer space of the first one such that the total = allocated=20 equals 3 Kbytes, the third SCSI Transfer Ready IU overlaps the = second one=20 such that the total allocated space equals 4 Kbytes, and so=20 on.
  
 Because the=20 receiver of the SCSI Transfer Ready IU's must fulfill them with = data as=20 specified by the sender, the receiver cannot simply keep an = aggregate of the=20 buffer space allocated.  Instead it must keep all of the SCSI = Transfer=20 Ready IU's whose associated bursts have not been=20 satisfied.
  
 I = believe that=20 the SCSI Transfer Ready IU includes the Buffer Offset field = principally for=20 error recovery.  However the absence of normative text = limiting the use=20 of this field, implies an overly complex implementation to ensure=20 interoperability.
  
 Regards,
  
 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117)=20 312-9503
  


------_=_NextPart_001_01C3D913.28938A96--




More information about the T10 mailing list