|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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: ips@ece.cmu.edu
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
Julian Satran wrote:
> Separation of parameters was made on a (very good) sugestion made by
Robert
> Snively - to keep SCSI affecting values (SCSI buffer sizes etc.) in mode
> pages and iSCSI related in key=value.
>
> Julo
>
>
> "Binford,
> Charles" To: IPS Reflector
<ips@ece.cmu.edu>
> <CBinford@piru cc:
> s.com> Subject: RE: iscsi : default
iscsi mode
> Sent by: page settings.
> owner-ips@ece.
> cmu.edu
>
>
> 21-09-01 16:54
> Please respond
> to "Binford,
> Charles"
>
>
>
> Santosh, I fully agree with the intent of your comments. One small
> problem, however, is you argue for FirstBurstSize = 0. Based on your
other
> comments I believe you are saying first burst should be disabled. SPC-2
> (and I see nothing in iSCSI to change this) defines firstBurstSize of 0
to
> mean "no limit". I believe that is exactly the opposite of what your are
> arguing for. The mode page field of firstFirstSize does not have or need
> the concept of zero blocks allowed because the feature is is enabled /
> disabled via other methods; process login parameters in FCP, initialR2T
and
> ImmediateData text parameters.
>
> So, we have the problem of how does a host that wants to use immediate or
> unsolicited data know how much he can send. Options I see are:
> - define a default value for the mode page (current method in iSCSI
spec).
> As I argued in previous posting, I believe this breaks basic mode page
> concepts of SCSI.
>
> - force the host to issue a mode sense before the first command with
> Data-Out.
> Not desirable, as Santosh argued in another email.
>
> - specify the amount of data the host send before the R2T during login as
a
> text parameter
> What I prefer.
>
> If we go with the last choice, then one has the question of what to do
with
> firstBurstSize in the mode page. Two options come to mind:
> - reflect the login specified value in firstburstsize during mode sense.
> Memory says this is how it used to be?
>
> - do nothing with it. Let iSCSI say that parameter in the mode page has
no
> meaning for the iSCSI protocol. Move the "firstBurstSize" concept to the
> iSCSI login/text parameters and let it stay there, don't try to tie it in
> to
> the mode pagan at all. (my preferred choice)
>
> Charles Binford
> Pirus Networks
> 316.315.0382 x222
>
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Thursday, September 20, 2001 6:44 PM
> To: IPS Reflector
> Subject: RE: iscsi : default iscsi mode page settings.
>
> All,
>
> I think we need to discuss the 2 issues of login key defaults & mode page
> defaults seperately :
>
> 1) Defaults on login keys :
> ===================
> I am in favor of defining conservative defaults. Those initiators needing
> additional features should be prepared to do the additional work of
> negotiating those keys. It should'nt be the other way around.
> Thus, default settings should be :
>
> MaxConnections = 1
> FMarker = "no"
> InitialR2T = "yes"
> BidiInitialR2T = "yes"
> ImmediateData = "no"
> DataPDULength = 16
> MaxOutstandingR2T = 1
> DataPDUInOrder = "yes"
> ErrorRecoveryLevel = 0
> SessionType = "normal"
>
> I'd like to propose one more change that the LogoutLoginMinTime &
> LogoutLoginMaxTime login keys be removed from the login keys.
>
> This is because these key values are only relevant for an initiator
> re-login
> following a target originated logout or connection drop (signalled
through
> an async message). The async message does contain these values and thus,
it
> provides no additional value to negotiate these during login.
>
> Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most
> likely properties of the target device (how long array "xyz" goes out to
> lunch during certain infamous conditions) as opposed to a value that can
be
> negotiated on a per-initiator basis.
>
> 2) Defaults on iscsi mode pages :
> ========================
> Typically, no protocol defaults are specified for mode page settings.
> Initiators should be able to function correctly without having to do
either
> mode select or mode sense. Any initiator that needs advanced settings
> should
> be prepared to do the extra work of issuing mode sense/select to enable
> these features. It should NOT be the other way around. (i.e. simple
> initiators should NOT have to first issue a mode select in order to
ensure
> proper operation of their sessions).
>
> If the draft does wish to profile a set of recommended defaults for the
> iscsi, these should be conservative, where they affect the operation of
> those initiators that do not wish to perform mode select.
>
> In particular, the following defaults are required, if it is decided to
> recommend a profile of default mode page settings :
>
> Disconnect-Reconnect Mode Page
> --------------------------
>
> * EMDP = 0
>
> * MaximumBurstSize = 512 units (as it currently defined. Targets can
> request less data in its R2T and send shorter data-in sequences, if
> mode select is not used by initiators to reduce this value.)
>
> * FirstBurstSize = 0
>
> The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to
use
> solicited data MUST first perform mode sense/select operations to
query/set
> these values. The above default setting of 128 is in-appropriate since :
>
> a) it can cause erroneous behaviour for those initiators that do not
> perform
> mode select to explicitly turn it off, since targets for which
un-solicited
> data is enabled but not used may reject/abort the I/O.
>
> b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data
is
> allowed for every logged-in initiator and they have no control over
turning
> this off, since mode select is an initiator-driven operation.
> Closing the command window causes performance drops and is not a very
> satisfactory solution to this problem.
>
> Logical Unit Control Mode Page
> ========================
> This mode page definition can be removed from the iscsi draft since it
> governs per-LUN state information and LUN state is the realm of the
> SCSI ULP. In particular, it is the SCSI ULP that decides whether to
> enable/disable CRN, since CRN is generated by the SCSI ULP.
>
> Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol
level
> & not at a SCSI ULP mode page such as the Control Mode Page. (??).
>
> Could anybody comment on why CRN (a ULP feature) needs to be enabled in
an
> iscsi protocol mode page ?
> Perhaps, for FCP it made sense to negotiate something like "Enable CRN"
in
> FCP specific mode pages, since early revisions of FCP did'nt specify the
> CRN
> field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was
> required to be queried/set using mode sense/select, prior to using CRN.
>
> Since iscsi supports CRN in its scsi command pdu from its initial rev, I
> don't see why "Enable CRN" is needed to be done at the iscsi protocol
> level.
> (?).
>
> Regards,
> Santosh
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
>
> > I vote for making the exchange of some text parameters MANDATORY, with
no
> > defaults.
> >
> > Marj
> >
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > Sent: Thursday, September 20, 2001 10:48 AM
> > > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS
> > > Reflector
> > > Subject: RE: iscsi : default iscsi mode page settings.
> > >
> > >
> > > It is true that default mode settings for Mode Pages
> > > are usually arranged between buyer and vendor for
> > > maximum convenience in the buyer's systems. It is
> > > generally true that any setting of a Mode Page will
> > > allow the protocol to operate correctly, except a few,
> > > notably the first burst size parameter if
> > > ImmediateData is set to yes.
> > >
> > > On the other hand, some of the iSCSI text keyed
> > > parameters MUST be known before the protocol will
> > > operate correctly. ImmediateData is certainly
> > > one of those. As a result, you have two choices:
> > >
> > > a) Make the negotiation of all such parameters
> > > MANDATORY during the login and after any
> > > reset that may change them, or;
> > >
> > > b) Define a default state that will be guaranteed
> > > unless and until the parameter has been explicitly
> > > changed.
> > >
> > > Your choice.
> > >
> > > Bob
> > >
> > > > -----Original Message-----
> > > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer)
> > > [mailto:sbhagat@tripace.com]
> > > > Sent: Thursday, September 20, 2001 6:59 AM
> > > > To: 'Santosh Rao'; IPS Reflector
> > > > Subject: RE: iscsi : default iscsi mode page settings.
> > > >
> > > >
> > > > Santosh,
> > > >
> > > > Where did you find these SCSI Mode page settings? At least I
> > > > could not find
> > > > it in SAM-2 document? The mode select command is available in
> > > > SPI documents
> > > > but they are meant for particular SCSI device and not for
> > > > iSCSI device?
> > > >
> > > > Be it whatever the case I would like to ask why the default value
of
> > > > MaximumBurstSize is 512 units and why is the default value of
> > > > FirstBurstSize
> > > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x
> > > > revisions so setting the default value of FirstBurstSize to
> > > > 128 units means
> > > > 65536 bytes or 64K Bytes and similarly the value of
> > > > Maximumburstsize is 256K
> > > > Bytes. Is it Ok to have the FirstBurstsize of 64KB??
> > > >
> > > > Sanjeev
> > > >
> > > > -----Original Message-----
> > > > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > > > Sent: Thursday, September 20, 2001 2:04 AM
> > > > To: IPS Reflector
> > > > Subject: iscsi : default iscsi mode page settings.
> > > >
> > > >
> > > > All,
> > > >
> > > > Speaking on the subject of default settings, some questions
> > > on recent
> > > > changes to the iscsi mode select pages......
> > > >
> > > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call
> > > > out default
> > > > values for the iscsi mode pages. Per my understanding, there are
no
> > > > defaults for SCSI mode pages, and all the setting are assumed to be
> > > > disabled, unless explicitly turned on/enabled through a mode
select.
> > > >
> > > > IOW, the keys in scsi mode pages are defined to be enabling certain
> > > > features and the default settings are that these features are
> > > > turned off
> > > > unless a mode select is explicitly used to enable them.
> > > >
> > > > However, the iscsi mode pages seems to be using the opposite
> > > > policy and
> > > > is advertising default settings for mode pages, that too,
> > > > agreesive ones
> > > > at that! IOW, an initiator implemenation has to explicitly
> > > > issue a mode
> > > > select to disable/turn_off features rather than issue a
> > > mode select to
> > > > turn them on.
> > > >
> > > > Here's a few examples :
> > > >
> > > > * default MaximumBurstSize : 512 units
> > > > * default EMDP : 1 (i.e. modify data pointers is enabled
> > > by default
> > > > !)
> > > > * default FirstBurstSize : 128 units. (i.e. initiators MUST use
> > > > solicited
> > > > data, unless they explicitly turn it off using mode
> > > > select, since,
> > > > not
> > > > sending solicited data when it has been negotiated
> > > > implies a target
> > > > may
> > > > abort the I/O.
> > > >
> > > > I suggest that in keeping with the scsi mode pages, NO
> > > > default settings
> > > > be advertised for any iscsi mode
> > > > pages. i.e. all defaults are conservative (set to 0), unless
> > > > explicitly
> > > > turned on thru a mode select.
> > > >
> > > > Comments ?
> > > >
> > > > Regards,
> > > > Santosh
> > > >
> > > > "Mallikarjun C." wrote:
> > > >
> > > > > Matthew,
> > > > >
> > > > > I completely agree that the default should be "no"! I
> > > pointed this
> > > > > out sometime ago myself. Apart from what you point out,
> > > the default
> > > > > setting for "ImmediateData" seems to be at variance with the
> > > > > conservative default for "InitialR2T" ("yes").
> > > > >
> > > > > Julian, could you please consider this request?
> > > > >
> > > > > Regards.
> > > > > --
> > > > > Mallikarjun
> > > >
> > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> > > > > >
> > > > > > Julian,
> > > > > >
> > > > > > Appendix D24 (ImmediateData) does not describe the result of
> > > > negotiation if
> > > > > > the two sides differ. I presume that since the default is
"yes",
> > > > then only
> > > > > > if both sides agree to "no" is immediate data turned
> > > off. Please
> > > > can this
> > > > > > be stated.
> > > > > >
> > > > > > Additionally, I feel that the default value for
> > > > ImmediateData should
> > > > be
> > > > > > "no".
> > > > > >
> > > > > > Similarly, there is no statement on MaxOutstandingR2T.
> > > Presumable
> > > > the
> > > > > > minimum is selected.
> > > >
> > > >
> > >
#### santoshr.vcf has been removed from this note on September 22 2001 by
Julian Satran
Home Last updated: Sun Sep 23 20:17:21 2001 6682 messages in chronological order |