iscsi : mode sense/select vs. login keys.

[Santosh Rao <santoshr@cup.hp.com>]

All,

In order to give the group some further perspective on the in-effeciencies of using a mode
sense/select based mechanism for negotiating iscsi parameters (especially, numerical parameters
like MaximumBurstSize & FirstBurstSize), I've outlined further below the steps an initiator would
need to take to negotiate iscsi numerical parameters through mode select/sense.

Note that performance aggresive initiators would like to negotiate FirstBurstSize to as high a
value as possible in order to boost performance on their WRITE I/Os. Thus, the below negotiation
would be required, for at least, FirstBurstSize, if one were to use mode select/sense.

Steps involved in mode select/sense negotiation :
====================================

When initiator needs to only read the target's mode page settings
-----------------------------------------------
1) Issue a mode sense(page control = "current values") for the desired mode page.


When initiator needs to negotiate mode page settings (i.e. read and modify settings)
--------------------------------------------------------
1) Issue a mode sense(page control = "changable values") for the desired mode page. This allows
the initiator to determine which parameters it is allowed to change. If none of the parameters
are changable, then, the target responds with a CHECK CONDITION scsi status to the mode sense.
(sense key = "illegal request", asc = "invalid field in cdb"). In this case, initiator issues a
mode sense(page control = "current values") to determine the target's current settings for those
parameters.

2) If the initiator could determine that the parameters are changable, it then issues a
mode select(sp = 1) or mode select(sp = 0) for the desired mode page. (sp = save page. depending
on whether the initiators wishes to save the mode page change).

3) The target may not support the exact value requested by the initiator. It may then choose to
perform parameter rounding and sets the parameter to a rounded value. It then fails the mode
select with a CHECK CONDITION scsi status (sense key = "recovered error", asc = "rounded
parameter").

The initiator on seeing the above CHECK CONDITION would need to perform another mode sense("page
control = current values") to determine the final negotiated value chosen by the target.

The target may also choose not to implement parameter rounding. In this case, it would respond to
the mode select from the initiator with a CHECK CONDITION scsi status with (sense key = "illegal
request", asc = "invalid field in parameter list"). In this case, the initiator has failed to
change the target's current parameters and it would need to perform a mode sense(page control =
"current values") to determine the current page setting.

As a short-cut, the initiator may choose to skip step (1) and attempt to change a parameter and
then figure out the result the hard way. Note that in this case if any 1 field was non-changable,
then, all other parameter negotiations within that page would also be failed.



As you can see for yourself from the above, to negotiate any numerical parameter, the initiator
will have to perform 2 mode sense operations and 1 mode select operation per mode page. The above
steps are a very cumbersome & ineffecient negotiation technique, compared to the alternative of a
simple 1-step handshake that the login key negotiation provides. An added advantage is that usage
of login keys implies no additional on-the-wire SCSI commands for the purpose of parameter
negotiation.

Given the above inefficiencies, I suggest that iscsi skip the use of mode select/sense technique
for negotiation and stick to login keys as far as possible. In any case, all of these mode pages
have transport specific semantics and iscsi is within its rights to not use these mode pages.

Comments ?

Thanks,
Santosh


"Mallikarjun C." wrote:

> Julian and Santosh,
>
> Whether FirstBurstSize should be a text key or not,
> IMHO, is (mostly) dependent on the current implementations.
> Santosh rightly pointed out several drawbacks of
> mandating a new set of mode select/sense operations
> that are totally iSCSI-specific since the legacy SCSI
> stack (class drivers, services/midlayer) will have no
> clue about them.  OTOH, if most of today's SCSI stacks
> _do_ perform this mode parameter manipulation in disconnect-
> reconnect mode page, that would be a strong argument to
> leave FirstBurstSize as a mode page parameter.
>
> A somewhat larger issue is whether this should be a nexus
> parameter of a given I-T nexus (which login keys enable),
> or not (which a *typical* shared mode page would preclude).
> While I cannot identify an obvious advantage of using
> a different FirstBurstSize for each I-T nexus in a
> target, the fact that the login key enables either shared
> or per-nexus parameter in a given target implementation
> seems to tilt the balance in favor of a login key.
>
> Regards.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
> Santosh Rao wrote:
> >
> > Julian Satran wrote:
> >
> > > I can sympathize with you wanting to use most of the parameters in iSCSI -
> > > but the values are in fact restrictions that SCSI places on iSCSI.
> >
> > Julian,
> >
> > I'm confused by your response.
> >
> > The SPC-2 description of Disconnect-Reconnect mode page indicates that :
> > "The parameters appropriate to each protocol and their interpretation for that protocol may
> > be specified in the individual protocol documents".
> >
> > FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for the pSCSI
> > transport. Thus, iscsi is within its rights to declare this field as reserved and attach no
> > meaning to it in the mode page. The FirstBurstSize can be negotiated during iscsi login
> > through a login key.
> >
> > > Nevertheless the discussion is rather academic because SCSI can hand those
> > > parameters to iSCSI.
> >
> > Again, I'm confused by your response. The reasons I'm suggesting the use of a login key
> > instead of the mode page method are :
> >
> >    * More accurate scope (applies only to this I-T nexus).
> >
> >    * More optimal negotiation and reduced overhead in the establishment of the I-T nexus. (2
> >      less SCSI commands per I-T nexus establishment.).
> >
> >    * Enables faster I/O scan times due to lesser on-the-wire activity during I-T nexus
> >      establishment.
> >
> >    * Allows less room for error in the I-T nexus establishment (no possiblity of failure to
> >      establish I-T nexus due to mode sense/select command failure).
> >
> >    * Avoids mode select wars that can occur when target uses shared mode pages.
> >
> >    * Simpler initiator implementations since they can avoid embedding SCSI command set
> >      knowledge as well as code to build/parse SCSI commands. Also, they can avoid extra code
> >      that is required to snoop for CHECK CONDITION with (sense key=UA, ASC="mode parameters
> >      changed") in order to re-issue a mode sense to determine new values for FirstBurstSize.
> >
> >    * Less code to interact with SCSI ULP application client to co-ordinate the mode page
> >      values b/n the ULP & LLP.
> >
> >    * Can use un-solicited data from the very first scsi command in the session.
> >
> > I don't consider any of the above reasons to be academic and would like to know which ones
> > among the above do you believe are academic and why ?
> >
> > > SCSI can handle those parameters dynamically. iSCSI may have trouble
> > > handling this type of negotiation dynamically over several connections.
> >
> > This is exactly the kind of stuff we don't need and should actually be trying to avoid. What
> > good does dynamically changing FirstBurstSize serve ? Dynamically changing FirstBurstSize
> > would only be achieved with least side-effects if :
> > 1) The mode select implementation on target is not using shared mode pages.
> > 2) The initiator has quiesced I/O prior to issuing the mode select for the change.
> >
> > Neither of the above 2 conditions would typically apply and any dynamic change of
> > FirstBurstSize would only cause initiators to see a bunch of side-effects such as :
> > a) Active outbound I/Os aborted by the target with a CHECK CONDITION due to "not enough
> > un-solicited data".
> > b) UA CHECK CONDITION for "mode parameters changed".
> >
> > In the interests of simplification and avoiding disruption of active I/O, such modifications
> > must be avoided as far as possible. One way to achieve that is to use a login key and make
> > it LO.
> >
> > >
> > > Resource-wise (as Bob Snively has pointed out) those are SCSI issues.
> > >
> > > A nice way out would be to ask T10 for a text mode negotiaton :-)
> >
> > Once again, I'm perplexed by your response. I'm not saying that text mode negotiation is the
> > reason I suggest moving this to a login key. The main objective is to isolate such
> > negotiation within the iscsi layer in an iscsi specific PDU that is a part of the iscsi
> > login process.
> >
> > Hope you will consider all of the above factors.
> >
> > Thanks,
> > Santosh
> >
> > ps : [I wonder if there are any others on this list who care to voice their opinion on this
> > issue. (??). ]
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