Re: iscsi : default iscsi mode page settings.

["Mallikarjun C." <cbm@rose.hp.com>]

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