SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iscsi : iscsi parameter default values



    I strongly agree that EMDP should not "default" to 1.  Two reasons:
    
    1) as I recently argued on this thread, I think it is invalid for a protocol
    to define a "default" for a mode page - that's not how mode pages work.
    
    2) **main reason** The whole concept of delivering data out order (for the
    normal I/O, not error recovery) buys a lot of complexity in both initiator
    and target for marginal "improvements" in buffer management and or
    performance.  I'm not convinced most targets gain anything from sending or
    receiving normal I/O data out of order.  Therefore I think it is a mistake
    for iSCSI for force a host to be able to handle the out of order case or
    else issue a mode select *every* time a new session starts up.  Keep it
    SIMPLE.  I fully agree with Santosh that the defaults for login keys should
    be conservative.
    
    Charles Binford
    Pirus Networks
    316.315.0382 x222
    
    
    -----Original Message-----
    From: Santosh Rao [mailto:santoshr@cup.hp.com]
    Sent: Wednesday, September 26, 2001 9: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
    


Home

Last updated: Thu Sep 27 10:17:34 2001
6801 messages in chronological order