SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI Plugfest at UNH (misc issues)



    Comments in text - Julo
    
    Sandeep Joshi <sandeepj@research.bell-labs.com> on 23-07-2001 18:30:39
    
    Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI Plugfest at UNH (misc issues)
    
    
    
    
    
    
    Hi Julian,
    
    Some additional items from the plugfest to resolve..
    
    1) Sec 2.3.1 : Untagged tasks.
       If the task attribute in the SCSI Command is "untagged"
       then the initiator task tag should be ignored, correct ?
       Can the draft explicitly state that the initiator must
       set the Initiator Task Tag to 0x'ffffffff if its an
       untagged task.
    
       Do we assume that the initiator ULP will not issue more than
       one untagged tasks simultaneously ?
    
    +++ In fact iSCSI has no such thing as untagged tasks. It will always use a
    tag and it is up to SCSI to distinguish between them. This should not be aa
    practical issue since the task identifiers (tagged or not) have to unique
    only at the initiator (according to SAM2).
    The x'ffffffff" is a reserved value - not to be used by SCSI tasks.
    
    I will "expand" 2.2.2.8 to read:
    
    1.1.1.1   Initiator Task Tag
    
       The initiator assigns a Task Tag to each iSCSI task that it issues.
       While a task exists, this tag MUST uniquely identify it session-wide.
       The initiator task tag may be used by SCSI too as part of the SCSI task
       identifier as the time span during which an iSCSI initiator task tag has
       to be unique extends over the time span during which a SCSI task tag has
       to be unique.  However, the iSCSI Initiator Task Tag has to exist and be
       unique even for untagged SCSI commands.
    
    +++
    
    2) ExpCmdSN
       What are the semantics of something like this.. the
       target does not increase the expCmdSN but keeps sending
       the status (SCSI response) for commands after the expCmdSN ?
       Clearly, the target has received and executed the commands
       (in cmdSN order).
    
       Hence, the expCmdSN in a SCSI response must not be less
       than the cmdSN of the original command (for which response
       is being received).
    
       This seems like a valid property which could be mandated
       and checked, to allow efficient initiator implementations.
       The target eventually suffers but the standard could
       prevent such targets from being deployed :-)
    
    +++
    
    Interesting proposal. Has some academic weaknesses however. We assume that
    CmdSN has no significance after delivery.
    Assume that you have a good target and a very long lived command - outlives
    a wrap around of CmdSN!
    
    How would you distinguish the status of this command carying a low ExpCmdSN
    from your case?
    
    I will change the following in 1.2.2.1
    
    
           - CmdSN - the current command Sequence Number advanced by 1 on each
          command shipped except for commands marked for immediate delivery.
           - ExpCmdSN - the next expected command by the target. The target
          acknowledges all commands up to but not including this number and the
          initiator has to mark the acknowledged commands as such as soon as a
          PDU with the corresponding ExpCmdSN is received. The target iSCSI
          layer sets the ExpCmdSN to the largest non-immediate CmdSN that it is
          able to deliver for execution plus 1 (no holes in the CmdSN
          sequence).
           - MaxCmdSN - the maximum number to be shipped. The queuing capacity
          of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1.
    
    
    
    
    And later - at the end of 1.2.2.1
    
       A target MUST NOT issue a command response or DATA-In PDU with status
       before acknowledging the command.
    
    
    As with many other initiator deteced errors - the initiator has to decide
    what to do with such an error (logout, rest etc.)
    
    ++++
    
    
    3) Sending status in read PDU
       Since quite a few initiators did not support this,
       this feature had to be enabled or disabled frequently at
       the target.
    
       Either we should make it mandatory to implement (at initiator)
       or we should add a key "SendStatusInReadPDU=yes/no".  The first
       option seems simpler.
    
    +++ Anything that is not optional is mandatory to implement
    to make it unequivocal I will add to 2.7:
    
       Status can accompany the last Data-in PDU if the command did not end
       with an exception.  Presence of status (and of a residual count) is
       signaled though the S flag bit.  Although targets may choose to send
       even non-exception status in separate responses initiators MUST support
       non-exception status in Data-In PDUs.
    
    +++
    thanks
    -Sandeep
    
    
    
    


Home

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