|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iscsi : default iscsi mode page settings.
Charles,
"Binford, Charles" wrote:
> 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".
You raise a good point here. Note that the iscsi definition of FirstBurstSize
in its disconnect-reconnect mode page differs from SPC-2 definition in that it
is silent about the semantics of a 0 value for the FirstBurstSize. Perhaps,
Julian can comment on whether this was intentional to indicate that 0 implies
no buffer available, or was an omission, in which case the wording needs to be
fixed.
> 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.
Agreed.
> 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.
I am in favor of this technique as well. As I have argued in the past,
dependence on the mode sense/select for iscsi session parameters is not a good
idea for several reasons :
* Mode Sense/Select implementation may be a shared mode page implementation
and this can cause strange side effects on initiators when other
initiators establish sessions with that target port and issue mode select.
It can result in mode select wars between initiators if they are
attempting to use different settings and are concurrently operating with
the same target port.
* Mode Sense/Select for setting session parameters is not architecturally as
clean as setting these parameters through login keys, since login keys are
an iscsi in-band technique, applied on a per session basis and only affect
the specified initiator & target port in that I-T nexus.
* Usage of mode sense followed by mode select causes an increase in I/O scan
times since this implies 2 extra scsi commands per session establishment.
Compare this with setting these parameters through the use of login keys,
which is done during login phase, has no side effects of affecting other
initiators and is a faster and more optimal method.
* Negotiating all session parameters through login keys allows initiator
implementations to be simpler since they can avoid having SCSI command set
code in the iscsi initiator drivers.
For all of the above reasons, I am very much in favor of using login keys for
negotiating session parameters, rather than dependence on mode select/sense.
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 t
> the mode pagan at all. (my preferred choice)
This is my preferred choice as well. Going with these choices will keep
initiator implementations simpler, optimize session establishment time [and
thereby, I/O scan time for initiators], avoid mode select wars and other side
effects of shared mode pages on iscsi initiator drivers.
I would like to request folks to re-consider the use of mode sense/select for
setting session parameters given the above listed reasons. My preference is to
only depend on iscsi login keys and state that iscsi has no meaning for the
disconnect-reconnect mode page.
Regarding the "Enable CRN" issue, I will reply in a separate mail.
Thanks,
Santosh
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.
> > >
> > >
> >
begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard
Home Last updated: Fri Sep 21 13:17:17 2001 6662 messages in chronological order |