Subject: RE: iSCSI: MaxBurstSize

From: "Elliott, Robert" <[email-masked]>
Date: Thu, 21 Feb 2002 16:05:04 -0600

MaxBurstSize is probably helpful for protocol bridges (e.g. FCP to
iSCSI).  If a destination FCP device has a MaxBurstSize, but the source
iSCSI device does not, the bridge may need to buffer lots of data as it
breaks up the iSCSI sequences into FCP sequences.  Being able to enforce
the same limit on iSCSI makes this a bit easier.

Another field called ConnectTimeLimit is the field that guarantees that
parallel SCSI goes bus free.  MaxBurstSize only limits time in data
phase (in non-packetized mode) or the size of a data IU (in packetized
mode.  Without ConnectTimeLimit, the target could hold the bus in
another phase (message, command, etc.) forever.  ConnectTimeLimit has no
value in fabrics and is not in iSCSI.

---
Rob Elliott, Compaq Server Storage
[email-masked]

> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> Sent: Thursday, February 21, 2002 3:36 PM
> To: [email-masked]
> Subject: Re: iSCSI: MaxBurstSize
> 
> 
> Pat,
> 
> The MaxBurstSize login key is a don't care for iscsi initiators. It
> serves mostly an informational purpose, letting the initiator know at
> login time as to what is the maximum amount of data it can expect the
> target to request in 1 R2T request, or the maximum amount of 
> data it can
> receive from the target in 1 data-in sequence.
> 
> Most initiators should be negotiating this to the maximum possible
> value, thereby, indicating to the target to just return the maximum
> value it supports for MaxBurstSize.
> 
> The MaxBurstSize itself is inherited as one of the tunables from the
> scsi Disconnect-Reconnect Mode Page as defined in SPC-2, 
> which is to be
> re-defined for each SCSI transport as appropriate.
> 
> IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode
> page makes sense in the parallel scsi context alone, where, 
> either side
> (initiator or target) can specify how long the scsi bus can remain in
> the data phase before a disconnect must be done.
> 
> In a fabric based SCSI transport, where, the data transfer does not
> cause any bus to be tied down, and the initiator's data buffers are
> allocated up-front before the SCSI command is sent to the target, I
> don't see any practical use of this key for initiators other 
> than being
> informational, and allowing them to learn of the target's limits
> up-front at login time.
> 
> I don't see why iSCSI needs to define this key, if its informational
> utility is of little or no value. I am also curious about what value
> FCP-2 initiators would find in this tunable. (?)
> 
> Regards,
> Santosh
> 
> 
> 
> "THALER,PAT (A-Roseville,ex1)" wrote:
> > 
> > Julian,
> > 
> > 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
> > resources.
> > 
> > The other use of MaxBurstSize is to limit how often target 
> may set the A
> > bit, but the utility of this is unclear.
> > 
> > Regards,
> > Pat Thaler
> > 
> > ---Original message----
> > From: Julian Satran [mailto:[email-masked]]
> > Sent: Tuesday, February 12, 2002 12:33 AM
> > To: Robert D. Russell
> > Cc: [email-masked]
> > 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
> > possible.
> > 
> > +++
> 
> -- 
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : [email-masked]
> Phone : 408-447-3751
> ##################################
>

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 21 Feb 2002 14:22:13 -0800

I believe, we need to consider this as issue with devices that can be both
initiators and targets.

Take for example a streaming tape; when it is reading the data from a Disk
Storage Controller.  Often these device start a long I/O streaming action
and have less memory then will contain the data they are requesting.
Through various double buffering techniques, they can keep the data coming
in, and going out to tape, without back-hitching.

So I believe MaxBurstSize has value, even if the disk storage folks think
it is minimal.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Santosh Rao <[email-masked]>@ece.cmu.edu on 02/21/2002 01:35:49 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:

Pat,

target to request in 1 R2T request, or the maximum amount of data it can

The MaxBurstSize itself is inherited as one of the tunables from the
scsi Disconnect-Reconnect Mode Page as defined in SPC-2, which is to be
re-defined for each SCSI transport as appropriate.

IMO, the "MAXIMUM BURST SIZE" tunable of the disconnect-reconnect mode
page makes sense in the parallel scsi context alone, where, either side
(initiator or target) can specify how long the scsi bus can remain in
the data phase before a disconnect must be done.

don't see any practical use of this key for initiators other than being

Regards,
Santosh

"THALER,PAT (A-Roseville,ex1)" wrote:
> 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
> The other use of MaxBurstSize is to limit how often target may set the A
> 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
>   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
> in case one of the Data Out PDUS is damaged and transfer to a device is
not

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 21 Feb 2002 14:22:13 -0800

.
.
.
John L. Hufferd

To:    [email-masked]
cc:

Pat,

Regards,
Santosh

initiator
based
questions
not

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 22 Feb 2002 11:20:11 +0200

Pat,

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. 

Julo

"THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
21-02-02 21:47

        To:     Julian Satran/Haifa/IBM@IBMIL, "Robert D. Russell" <[email-masked]>
        cc:     [email-masked]
        Subject:        iSCSI:  MaxBurstSize

Julian,

Regards,
Pat Thaler

---Original message----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 12:33 AM
To: Robert D. Russell
Cc: [email-masked]
Subject: Re: UNH Plugfest 
+++

+++