SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: burst size, response and sense data



    
    
    Mallikarjun,
    
    The way I read the burst items they apply for output mainly (both the
    initial and the max burst size - the thing comes from the "connect context"
    of parallel buses).
    
    I am working now on errors. I am not convinced that we need an iSCSI status
    field and that is why it is (perhaps temporarily) out.
    
    I am looking at solving the iSCSI format errors through either "command not
    understood" or an appropriate SCSI error.  But this may change after I
    finish a first inventory.
    
    Regards,
    Julo
    
    "Mallikarjun C." <cbm@rose.hp.com> on 08/12/2000 05:04:36
    
    Please respond to cbm@rose.hp.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: burst size, response and sense data
    
    
    
    
    Julian,
    
    1. The new iSCSI draft states that:
      "An initiator may send unsolicited data (immediate or in a separate
      PDU) up to the SCSI limit (initial burst size - mode page 02h)." (section
      1.2.5, para 4).
    
    SPC-2 has the following on "FIRST BURST SIZE" in mode page 02h -
      "The FIRST BURST SIZE indicates the maximum amount of data that a
      target may transfer for a command during the same interconnect
      tenancy in which it receives the command." (Clause 8.3.7, last para)
    
    Note that the mode page 02h is specifying the burst size in the *opposite*
    direction - from target to initiator.  I would suggest that a new "iSCSI
    mode page" be created to specify parameters of this nature.  Or, rely only
    on what is negotiated in the iSCSI login dialogue, on a per-session basis.
    
    
    2. Could you please comment on what is a valid response data format?
    I expected all iSCSI protocol failures to find place in this response
    data (similar to how FCP defines), but didn't find that stated in
    section 2.3.7.
    
    
    3. Same section 2.3.7 states that:
      "Some sense codes will relate to iSCSI check conditions (e.g. excessive
       number of outstanding commands, immediate data blocks too large etc.)."
    
    Two concerns -
    
    - Instead of using the SCSI application layer sense codes for denoting
      the SCSI transport layer (iSCSI)'s error conditions (and thus perhaps
      have a new set of sense codes standardized by T10), I would suggest
      that we keep off SCSI sense codes.  This provides for clean layered
      implementations as well.
    
    - The examples given above seem like iSCSI protocol issues, and in my
      opinion, are apt to be represented in response data than in sense data.
    
    Thanks.
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    M/S 5601
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:06 2001
6315 messages in chronological order