[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iSCSI: MaxBurstSize
For the initiator it is mostly a design issue and you can do without it (it tells what to expect an R2T to be, how much to prefetch etc.). For the target it is the A bit interval and a turnaround opportunity for bi-directional. For bridges and gateways it is obviously helpful.
I still don't see the rational for MaxBurstSize.
The initiator doesn't need it to limit its required resources. The initiator
has to have its buffers allocated when it issues a command. It has to
control the demand on its resources by limiting the commands it issues based
upon its available resources.
The target has FirstBurstSize and R2T's to control the demand on its
The other use of MaxBurstSize is to limit how often target may set the A
bit, but the utility of this is unclear.
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, February 12, 2002 12:33 AM
To: Robert D. Russell
Subject: Re: UNH Plugfest
<Section 3.8.3 should be 10.8.3>
3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
an R2T to at most MaxBurstSize. What is the rationale for this?
An R2T is sent by the target to the initiator, so why can't the
target specify any size it wants in the R2T? The target already
uses R2Ts to control the flow of Data-Out PDUs from the initiator,
so why impose this restriction on the R2Ts?
Could someone please explain the benefit to this limitation on R2Ts?
+++ Is this a plugfest question or one of your own? For your own questions
the channels are always open. The MaxBurstSize is there to enable the
initiator to share resources between several executing commands and limit
the number of "pending buffers" a target will have to keep
in case one of the Data Out PDUS is damaged and transfer to a device is not
Last updated: Fri Feb 22 05:18:08 2002
8841 messages in chronological order