Re: iscsi : default iscsi mode page settings.

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

Hi,

I suggest the following simplifications to the iscsi draft on the subject of
mode pages :

1) Disconnect reconnect Mode Page
===========================

   * The FirstBurstSize field be moved to a login key and this field be
     declared as reserved.

2) LUN Control Mode Page
=====================
I suggest this mode page be removed from the iscsi draft. There's no need for
iscsi to be using a "Enable CRN" field, since it supports the CRN field in its
SCSI Command PDU from its initial revs.

I'm not sure if this field is intended to check the ability of the target
SCSI transport or the target's application client or both (?). IMO, there's no
need for iscsi to negotiate CRN support at a transport level. If the
SCSI ULP needs to determine support for CRN by the target application client,
this is the job of a bit in the "Control Mode Page" or some other SCSI ULP mode
page, not in a protocol dependent mode page.

If iscsi initiators receive a CRN in its command requests from their SCSI ULP
(device server), they must initialize the CRN in the scsi command pdu with this
value and transmit the command. The target iscsi layer hands over the command
to the target SCSI ULP (application client) along with its CRN. CRN support and
ordering is the subject of peer SCSI ULP layers. iscsi must have nothing to do
with this.

Thanks,
Santosh



"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:

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