Additional ADT Questions/Comments

Robert Snively rsnively at Brocade.COM
Fri Jan 9 09:43:47 PST 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_01C3D6D8.2289BFDE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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_01C3D6D8.2289BFDE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

 Message Michael,
  
 I am=20 not quite sure I understand your question.
  
 Transfer Ready is sent by a target to = solicit required=20 data from an initiator.
 It may do so in any order and with any = overlap that it=20 needs, consistent
 with the posted capabilities of the = initiator=20 negotiated with the requirements
 of the target.  Checking for complete = transfers in=20 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 = 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 7:24=20 AM
To: t10 at t10.org
Cc: Towler, Russell; Davies,=20 Myles
Subject: Additional ADT=20 Questions/Comments


 Regarding question=20 4 of my previous e-mail (dated 6 January 2004 and attached), allowing = a port=20 to send multiple SCSI Transfer Ready IU's with Buffer Offset values = such that=20 the buffer space allocated is less than the sum of the Burst Lengths = can=20 potentially require a substantial amount of storage in the receiving=20 port.
  
 For = example=20 consider a foolish implementation that allocates 100 Kbytes by = sending 99 SCSI=20 Transfer Ready IU's each with a Burst Length of 2 Kbytes where the = Buffer=20 Offset follows the sequence 0, 1K, 2K, ..., that is the first SCSI = Transfer=20 Ready IU allocates 2 Kbytes, the second SCSI Transfer Ready overlaps = the=20 buffer space of the first one such that the total allocated equals 3 = Kbytes,=20 the third SCSI Transfer Ready IU overlaps the second one such that = the total=20 allocated space equals 4 Kbytes, and so 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 the=20 SCSI Transfer Ready IU includes the Buffer Offset field principally = for error=20 recovery.  However the absence of normative text limiting the = use of this=20 field, implies an overly complex implementation to ensure=20 interoperability.
  
 Regards,
  
 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117)=20 312-9503
  


------_=_NextPart_001_01C3D6D8.2289BFDE--




More information about the T10 mailing list