Re: iscsi : default iscsi mode page settings.

["Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <iscsi_t10@sanjeevbhagat.com>]

Julian, Santosh,

Can we make all the SCSI mode page paramters be made as login keys? Why
should they be kept in a seperate mode page at all??

Sanjeev
----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Santosh Rao" <santoshr@cup.hp.com>
Cc: "Julian Satran" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.


>
> In addition to what Santosh said,  If I understand this right,
> I think it is a problem for iSCSI to have to keep going across layers to
> determine what the values are.  Since iSCSI Target will not see the CDB
> that caused the values to change.
>
> Now if the value in the mode page is only the default, that would be a
> different issue.
>
> .
> .
> .
> 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/24/2001 12:28:43 PM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iscsi : default iscsi mode page settings.
>
>
>
> 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. (??). ]
>
>
>
>
>
>