Re: iscsi : mode sense/select vs. login keys.

["John Hufferd" <hufferd@us.ibm.com>]

In addition to what Santosh said,  I do not believe the SCSI Class Drivers
will be creating these SCSI Mode Page Select/Sense commands for the
Connect/Disconnect Mode Pages,  nor do I believe anything higher then the
SCSI Class Drivers will be doing that either.  Therefore, it seems rather
strange for the iSCSI initiator to be creating SCSI commands to control
these Connect/Disconnect Mode Pages.

.
.
.
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
Internet address: hufferd@us.ibm.com


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 09/25/2001 04:37:10 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips <ips@ece.cmu.edu>
cc:
Subject:  iscsi : mode sense/select vs. login keys.



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. (??). ]