SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: unsolicited Vs immediate; restart delay



    
    
    Mallikarjun,
    
    I will make those statements clearer and perhaps change the name of the key
    from UseR2T to InitialR2T.
    
    Julo
    
    "Mallikarjun C." <cbm@rose.hp.com> on 10/03/2001 06:07:34
    
    Please respond to cbm@rose.hp.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: unsolicited Vs immediate; restart delay
    
    
    
    
    Julian,
    
    >I would be glad to be corrected, if I am misinterpreting the usage of
    >UseR2T.
    >+++ the confusion stems from the  role of UseR2T.  UseR2T is all about
    >allowing an unsolicited first burst.  After the first burst you need
    always
    >R2T.
    
    Thanks for the clarification.  I was about to conclude this is the case
    earlier, but found the following in section 2.17, page67 -
         "In order to allow write operations without R2T, the initiator and
         target must have agreed to do so by both sending the UseR2T=no key-
         pair attribute to each other (either during Login or through the Text
         Command/Response mechanism)."
    
    And then the following in section 1.2.5, page 16 -
         "Targets operate in either solicited (R2T) data mode or unsolicited
         (non R2T) data mode."
    
    And then the following in Appendix D, page 109, item 19 (UseR2T key):
         "The UseR2T key is used to turn off the default use of R2T, thus
         allowing an initiator to send data to a target without the target
         having sent an R2T to the initiator."
    
    None of these give any indication that UseR2T only applies for the first
    burst!
    PLEASE rephrase all these appropriately to reflect the intent.
    
    >You are left now with only 2 parameters controlled by the two variables.
    >The only think still open is that for comletness it is probably advisable
    >to have for Immediate also a bit in the corresponding mode page bit+++
    >+++++++++++++++++++++++++++++++++++++++
    
    Immediate data is not the only thing that needs a bit.  Even the
    unsolicited
    data needs one since we want to be able to control both independently.
    Also (as I have been harping on), SPC-2 defines a zero FirstBurstSize
    as "unlimited" than "not allowed".  This needs to be redone to mean "not
    allowed".
    
    Should we request T10 for action on these (Rob Elliott helped the last
    time with SPC-2's definition of direction of FirstBurstSize)?
    
    Thanks.
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668   Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    
    


Home

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