SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI : Concerns regarding DataRN in READ Data PDU.



    
    
    And BTW the same coments where made with regard to ftp!
    
    Was it a good thing that it it was unrecoverable?
    
    Should we repeat this story for the SCSI Extended Copy?
    
    Julo
    
    Santosh Rao <santoshr@cup.hp.com> on 09/01/2001 06:03:03
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   IPS Reflector <ips@ece.cmu.edu>
    cc:
    Subject:  iSCSI : Concerns regarding DataRN in READ Data PDU.
    
    
    
    
    Julian/All,
    
    Can anybody comment on the true benefit that the DataRN feature provides
    that justifies the complexity and performance issues it introduces to
    the protocol ?
    
    I see the following issues with DataRN :
    
    1) It adds a performance penalty in that on every READ Data PDU
    targets will have to initialize one additional 32-bit word in the
    header.
    
    2) Extra traffic on the outbound context from initiators sending
    NOP-OUTs to acknowledge the DataRNs.
    
    3) Performance path checks for the "P" bit on every READ PDU.
    (Alternatively, checks for the DataNumber field from the Login
    Text Keys).
    
    4)  Implementing DataRNs per task is too short-lived to provide any
    real benefit. Implementing them per connection or session can result
    in quick use up of the 32-bit DataRN space (since each frame consumes
    one DataRN), adding additional complexity to the target code to use the
    "P"
    bit appropriately.
    
    5) Further, "DataNumber", which is the size of the un-acknowledged
    DataRN window is negotiated at login time, whereas this is really
    desired to be a dynamic variable based on the target's current I/O load
    and the number of initiators speaking to it. Thus, DataRN can end up
    being
    under-utilized resulting in too much NOP-OUT traffic, or it can be
    over-utilized resulting in too much usage of the "P" bit in the READ
    PDUs, which, again, can cause too much NOP-OUT traffic.
    
    6) Considering that the DataRN generation and acknowledgement are
    functions
    that would typically be in SCSI hardware assist engines and there is a
    need to
    keep these as simple as possible, adding such features in the spec means
    
    that these SCSI assist engines MUST implement DataRN generation
    and acknowledgement [since initiators have no way to turn it off if a
    target decides to use it]
    
    What is the true benefit of this feature ? Is it intended to be used as
    :
    
    a) Will allow targets to do partial freeing of their memory buffers as
    and when DataRNs are received ?
    
    b) Will allow targets to send back only the un-acknowledged data (as
    seen from the ExpDataRN received on the last NOP-OUT from the initiator)
    when the initiators retry commands with the "Retry" bit set ?
    
    If the benefit intended is (a), then, in order to derive this benefit,
    targets will have to advertise their DataNumber login key to be < the
    avg. number of frames transmitted per READ I/O. Having a DataNumber >
    the avg. number of frames per READ I/O implies the life of the task ends
    [and buffers for the task get released] before the initiator sends
    NOP-OUT, thereby, defeating benefit (a).
    
    If the benefit intended is (b) [and i do not see this explicitly stated
    in the draft], then, this is a dangerous assumption which can lead to
    data corruption issues.
    
    When commands are retried with the "Retry" bit set, are targets allowed
    to send back partial data based on the last ExpDataRN they received ? If
    so, this can have multiple issues like :
    
    o    complexity in handling I/O underrun cases for the retried command
          which only saw partial data transfer from the target.
    
    o    If the target only sent back partial data based
          on its last ExpDataRN received, then, it can open up possible data
    
          corruption windows.
    
    All in all, I believe that the DataRN is adding too much complexity and
    potential performance impact to iSCSI for the benefits it may provide.
    
    Moreover and most importantly, the draft does not give initiators any
    control over the usage of this feature and if a target decides to use
    this feature, initiators will have to support it. This exposes the
    initiators to all of the above issues without being able to turn off
    this feature.
    
    I would like to therefore ask that :
    
    either,
    a) DataRN support be removed from the iSCSI draft.
    
    or
    b) The support for DataRN be negotiated at login time giving initators
    control over this feature and allowing them to disable this feature.
    This will allow SCSI hardware assist engines to skip implementation of
    this functionality and their associated software can merely turn off
    DataNumber in the login negotiation.
    
    Thanks,
    Santosh
    
    
    
    
     - santoshr.vcf
    
    
    
    


Home

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