Subject: RE: iscsi : default iscsi mode page settings.

From: "Binford, Charles" <[email-masked]>
Date: Mon, 24 Sep 2001 10:00:24 -0400

I believe it is the transport's job to deliver the data.  Buffering
unsolicited data that has arrived at the target *before* the SCSI engine has
even had a chance to evaluate the CDB is part of the data delivery system -
the transport.

Charles Binford
Pirus Networks
316.315.0382 x222

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, September 21, 2001 11:06 PM
To: [email-masked]
Subject: Re: iscsi : default iscsi mode page settings.

That is not my reading of the map. The unsolicited payload buffer size is a
"data sink" attribute. The data sink is the SCSI engine and not the iSCSI
layer.

Julo

                    Santosh Rao

                    <santoshr@cup.       To:     [email-masked]

                    hp.com>              cc:

                    Sent by:             Subject:     Re: iscsi : default
iscsi mode    
                    owner-ips@ece.        page settings.

                    cmu.edu

                    21-09-01 21:50

                    Please respond

                    to Santosh Rao

Julian,

The FirstBurstSize is governing an iscsi parameter which is : "how much
un-solicited
data can the initiator send" ? I concur with Charles' suggestion that
FirstBurstSize be
moved to a login key.

By doing this, we can improve scan times, due to the elimination of the
mode
sense/select & avoid the side effects of shared mode pages. This allows
easier use of
un-solicited data.

Regards,
Santosh

---

From: Santosh Rao <[email-masked]>
Date: Mon, 24 Sep 2001 09:38:26 -0700

Julian,

The FirstBurstSize is an iscsi property and not an attribute of the scsi ULP.
Evidence of this lies in its location itself, the disconnect-reconnect mode
page. This mode page is used to tune the parameters of the service delivery
subsystem (in our case, this would be iscsi).

I would like to re-iterate my request that FirstBurstSize be placed as a login
key.

Regards,
Santosh

---

From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <[email-masked]>
Date: Mon, 24 Sep 2001 19:34:21 +0200

well we are now debating two things

1. Whether Firstburstsize comes in iSCSI realm or does it come in SCSI
realm.
2. Whether Firstburstsize should be sent as login key or should it be a part
of mode sense/select page

For the first point, As charles explained below Firstburstsize is a part of
data delievery system (transport layer as described in SAM-2), so it
certainly is not a parameter of SCSI. . SCSI as such does not even need to
have any Firstburstsize because it is capable of transferring any amount of
data. Firstburstsize basically only helps in faster implementation of data
being transferred on network.

As such the "SCSI Mode Pages" as described in iSCSI document should rather
be renamed to iSCSI Mode pages.

I think the FirstBurstSize be kept as login key but here we will have a
problem as to which value be over-ridden whether the one sent by initiator
or target. This depends upon whether

a. the iSCSI target should be made so efficient as to support different
values of Firstburstsize for different initiators. If it is so then the
target accepts the Initiator value. This increases complexity on target side
or
b. the iSCSI target should operate on one particular mode of FirstBusSize.
If it is so then initiator accepts target value. But in this case also I
foresee a problem in this case when multiple intiators are accessing a iSCSI
target and one of the iSCSI initiator changes the value of FirstBusSize

If we keep FirstBurstSize as a part of mode sense/mode select page then the
problem described above in (b) still exists

Regards,
Sanjeev

---

From: Santosh Rao <[email-masked]>
Date: Mon, 24 Sep 2001 11:09:09 -0700

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:

> or target.

Sanjeev,

I don't think there is an ambiguity on which value is to be accepted. The final
negotiated value is agreed upon by both parties. See below definition of
numerical key negotiation, taken from Section 2.2.4 of Rev 7.97 :

" In numerical negotiations, the offering and responding party state a
numerical value. The result of the negotiation is key dependent; frequently the
lower or the higher of the two values is used. "

By defining the FirstBurstSize as a login key and specifying that the lower of
the 2 numbers is accepted, there is no ambiguity over the final chosen value.
This is true of all numerical negotiations. See the definition of
MaxConnections as an example :

"MaxConnections=<number-from-1-to-65535>

Default is 8.

Initiator and target negotiate the maximum number of connections
requested/acceptable.  The lower of the 2 numbers is selected."

Regards,
Santosh

> This depends upon whether
>

---

From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <[email-masked]>
Date: Mon, 24 Sep 2001 23:24:12 +0200

Santosh,

Yes agreed!!, this works fine with me. But now the target will have to
support different values of FirstBurstSize for different initiators.

But should this field be kept in mode page if it will be dynamically
configurable and it value may vary for different inititators. This goes
against the semantics of mode pages. However keeping them in mode page may
mean similarity and compatibility with FCP-2

Sanjeev