Additional ADT Questions/Comments

Robert Snively rsnively at Brocade.COM
Mon Jan 12 07:41:54 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_01C3D922.9ABEAD2E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Then it is simple.  ADT gets to specify a protocol specific negotiation
mechanism between
the "initiator" and "target" to indicate what the initiator's
capabilities are with respect to=20
receiving multiple transfer ready operations.  Either that or , as you
suggest,
you must create specific restrictions on ADT that limit the number of
transfer readys to one
outstanding or possibly to require the transfer ready to be large =
enough
to transfer
the entire set of information required by a command.
=20
Another possibility is to remove the transfer ready capability from the
protocol and use
instead an end-to-end buffer credit flow control scheme, with each
"buffer ready" signal
granting a certain amount of data flow.  That would prohibit
out-of-order data transfer
and make retries possible only on the whole data, but would solve your
other problems.
=20
Bob
=20

-----Original Message-----
From: Banther, Michael [mailto:michael.banther at hp.com]
Sent: Monday, January 12, 2004 5:51 AM
To: Robert Snively; t10 at t10.org
Cc: Towler, Russell; Davies, Myles
Subject: RE: Additional ADT Questions/Comments


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

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

 Message Then=20 it is simple.  ADT gets to specify a protocol specific negotiation = mechanism between
 the=20 "initiator" and "target" to indicate what the initiator's capabilities = are with=20 respect to 
receiving multiple transfer ready = operations. =20 Either that or , as you suggest,
 you=20 must create specific restrictions on ADT that limit the number of = transfer=20 readys to one
 outstanding or possibly to require the = transfer ready=20 to be large enough to transfer
 the=20 entire set of information required by a command.
  
 Another possibility is to remove the = transfer ready=20 capability from the protocol and use
 instead an end-to-end buffer credit flow = control=20 scheme, with each "buffer ready" signal
 granting a certain amount of data = flow.  That=20 would prohibit out-of-order data transfer
 and=20 make retries possible only on the whole data, but would solve your = other=20 problems.
  
 Bob
  
 -----Original Message-----
From: Banther, Michael=20 [mailto:michael.banther at hp.com]
Sent: Monday, January 12, = 2004 5:51=20 AM
To: Robert Snively; t10 at t10.org
Cc: Towler, = Russell;=20 Davies, Myles
Subject: RE: Additional ADT=20 Questions/Comments


 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=20 am 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=20 transfers in the presence of = overlapped
 or out-of-order requests is one of those = things=20 that may encourage an
 initiator to prohibit overlap and = out-of-order=20 requests.
  
 Each Transfer Ready must be = fulfilled.  At=20 least in Fibre Channel, the
 protocol prohibits the generation of a = new Transfer=20 Ready before the
 previous one has been fulfilled by using = the=20 transfer 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=20 Offset values such that the buffer space allocated is less than = the sum of=20 the Burst Lengths can potentially require a substantial amount of = storage=20 in the 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=20 the buffer space allocated.  Instead it must keep all of the = SCSI=20 Transfer 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=20 for error recovery.  However the absence of normative text = limiting=20 the use of this field, implies an overly complex implementation = to ensure=20 interoperability.
  
 Regards,
  
 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117) = 312-9503
 =  


------_=_NextPart_001_01C3D922.9ABEAD2E--




More information about the T10 mailing list