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