RE: iscsi : iscsi parameter default values

["Eddy Quicksall" <EQuicksall@mediaone.net>]

I once voted "no" on this, but the argument as to what is easiest is now a
moot point because a response is now required (it used to not be required).
All a lightweight target needs to do is to send ImmediateData=no.

As to the argument as to what is easier, it is completely implementation
dependent. For example, parallel SCSI targets many times don't take
immediate data ... they disconnect after command phase and then reselect
after assigning buffers to receive the data. So, if one is porting that kind
of code, he will probably see it easier to say ImmediateData=no. It also
makes zero copy very easy.

So I'm changing my vote to "I don't care" because I'll just send
ImmediateData=no if I can't support ImmediateData.

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, September 28, 2001 1:38 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi : iscsi parameter default values




Robert,

I disagree that Immediate is "the most demanding" mode.  That is not my
experience and not what I heard from most of the developers.  On the
contrary immediate data do not require a separate indexing operation on
the
target (as non-immediate unsolicited do) and that was the base for the
consensus to have them negotiated separately.

For the software initiator it is the most inexpensive way to perform
short
data transfers (4-8k) typical for major applications like Database
access
and so it is for lightweight target.

Julo





                    Robert Snively

                    <rsnively@broc       To:     John Hufferd/San
Jose/IBM@IBMUS, Julian
                    ade.com>              Satran/Haifa/IBM@IBMIL

                                         cc:     ips@ece.cmu.edu

                    28-09-01 17:25       Subject:     RE: iscsi : iscsi
parameter default values
                    Please respond

                    to Robert

                    Snively








I vote no as the default value on ImmediateData.

A default value of yes on ImmediateData requires implementation
of the most complex and demanding mode of operation as the
default.  SCSI has traditionally made its default behavior the
simplest and most encompassing, setting more sophisticated
behavior by subsequent agreement.  While it may be your earnest
desire to encourage the implementation of this function, it
is not appropriate to demand that as the default behavior
of all devices.  In particular, there is no special benefit
to providing ImmediateData in low-cost local sub-lans.

If you want to encourage it in a profile, fine, but demanding
it as the default in the core standard is not appropriate.

Note that the behavior of SCSI is traditionally managed
entirely by the target.  As such, there has never before now
been a requirement for the target to, as a default, accept
any PDU except a command or task management function
that was not explicitly solicited.  That is one of the mechanisms
that assists SCSI in achieving a low-overhead zero copy
capability while operating with a large number of initiators
and with deep command queues.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Friday, September 28, 2001 1:33 AM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: RE: iscsi : iscsi parameter default values
>
>
>
> I also agree with this.  It should be yes.
>
> .
> .
> .
> 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
>
>
> Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iscsi : iscsi parameter default values
>
>
>
>
> The one that I have trouble living with is ImmediateData.
> This is important
> for low-end desktops and hardly matters for large boxes.
> As such I would suggest it stays as yes.
>
> Julo
>
>
>
>                     "Eddy
>                     Quicksall"            To:     "'Santosh Rao'"
> <santoshr@cup.hp.com>,
>                     <EQuicksall@med        <ips@ece.cmu.edu>
>                     iaone.net>            cc:
>                     Sent by:              Subject:     RE:
> iscsi : iscsi
> parameter default values
>                     owner-ips@ece.c
>                     mu.edu
>
>
>                     27-09-01 17:22
>                     Please respond
>                     to "Eddy
>                     Quicksall"
>
>
>
>
>
> I like your defaults below.
>
> But, section 5 says:
>
>  The initial Login request MUST include the InitiatorName and
>  SessionType key=value pairs.
>
> Since SessionType is REQUIRED, naming a default would imply a
> possible typo
> in the spec.
>
> Eddy
>
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, September 26, 2001 10:29 PM
> To: ips@ece.cmu.edu
> Subject: iscsi : iscsi parameter default values
>
>
> All,
>
> With the issue of mode page vs. login keys having [almost] drawn to a
> close, I would like to
> raise the below issues again, on the subject of default
> values for login
> keys and other iscsi
> parameters :
>
>
>    * In keeping with traditional use of scsi mode pages, iscsi should
> not specify any default
>      settings for any mode pages that continue to exist for iscsi.
> "Default values" for mode
>      pages are target specific and should not be bound to the protocol
> draft.
>
>    * MORE IMPORTANTLY, I read the default for EMDP as being set to 1
> :-<  This implies that
>      targets must be always prepared to deal with out of
> order data and
> initiators must be
>      prepared to deal with out of order data, unless the initiator
> performs a mode select to
>      disable it. [which defeats all the previous advantages
> gained thru
> mandating use of login
>      keys for other negotiations.]. A default, if it were to exist,
> should be 0. (in-order, by
>      default).
>
>    * Conservative specification of defaults for login keys along the
> following lines :
>                             MaxConnections = 1
>                             FMarker = "no"
>                             InitialR2T = "yes"
>                             BidiInitialR2T = "yes"
>                             ImmediateData = "no"
>                             DataPDULength = 16
>                             MaxOutstandingR2T = 1
>                             DataPDUInOrder = "yes"
>                             ErrorRecoveryLevel = 0
>                             SessionType = "normal"
>
>    * Should the iscsi protocol require a "Lun Control Mode Page"? IOW,
> is an EnableCRN bit
>      required at the transport layer ? If the device server capability
> is to be negotiated , I
>      suggest this bit be moved to a SCSI ULP Mode Page such as the
> "Control Mode Page", through a
>      T10 change as a part of the SCSI changes being driven by iscsi.
>
> Comments ?
>
> Thanks,
> Santosh
>
>
> Santosh Rao wrote:
>
> > There are the separate issues of :
> >
> >    * iscsi's specification of defaults for its mode pages
> which is not
> in line with mode page
> >      usage. This impacts the target's ability to enforce
> values other
> than the protocol
> >      specified default, if the initiator were to not use mode
> sense/select.
> >
> >    * default settings for login keys.
> >
> >    * Is there a need for the "LUN Control Mode Page" and whether
> "Enable CRN" should be in a
> >      transport specific mode page ?
> >
> > which need to be driven to closure as well.
> >
> > Regards,
> > Santosh
>
>
>
>
>
>
>
>
>
>
>