RE: iscsi : iscsi parameter default values

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

Is there any target today that will handle ImmediateData
without a significant change to the transport API? Also
is there any target that does use out of order R2Ts?
(Just curious)

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Thursday, September 27, 2001 9:50 AM
> To: ips@ece.cmu.edu
> 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
> 
> 
> 
> 
> 
> 
> 
>