SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Reject, CmdSN, and DataSN



    Mark,
    
    When you say "uses up a SN", do you mean the ExpCmdSN/ExpDataSN
    is updated?  If so, I see a problem with at least CmdSN.
    
    Let's consider commands first.  The only Reject reason code that 
    I see where a target could update its ExpCmdSN is when there 
    is a payload-digest error on immediate data.  In all the other 
    cases, either the target doesn't care (immediate/retry/non-FFP), 
    or can't know for sure (format error).  I suggest that we _not_ 
    advance the ExpCmdSN on immediate data digest error to give the 
    initiator an opportunity to re-issue the command to preserve 
    command ordering.
    
    Let's now consider data.  Again the only Reject reason code I see
    for advancing ExpDataSN is payload-digest error ("2").  Either the 
    target
      (a) would generate a recovery R2T (if DataSequenceOrder was 
          negotiated as "no" and target supports Within-command 
          recovery), or 
      (b) eventually signal a service delivery subsystem failure for
          the command (iSCSI response code 0x02).
    
    For (b), it doesn't matter if the target updates ExpDataSN or not.
    For (a) OTOH, the target should update the ExpDataSN to deal with
    the current data burst (that reminds me that I need to fix this
    in Within-command algorithms in Appendix F!).
    
    So to summarize, I think a Reject'ed CmdSN should not be considered
    as successfully received on the target.
    
    Your comments are welcome.
    --
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    >When a PDU is rejected, I assume that the CmdSN is still
    >updated, as well as the DataSN where applicable.  That is,
    >a rejected command still uses up a SN.  It probably wouldn't
    >hurt to state this in the reject section.
    >
    >Since the Reject response does not contain ExpCmdSN, if the
    >last command before the window is closed is rejected, the
    >initiator has to rely on prior commands completing to re-open
    >the window.  This will usually work, but what if the window
    >size is reduced to one outstanding command for some reason?
    >Any command that is rejected will close the window for good.
    >A sequence of rejected commands equal to the window size will
    >do the same.
    >
    >Any thoughts?
    >
    >-- 
    >Mark A. Bakke
    >Cisco Systems
    >mbakke@cisco.com
    >763.398.1054
    >
    
    
    


Home

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