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

    Re: UNH Plugfest


    Comments in text -


    "Robert D. Russell" <>

    12-02-02 02:49

            To:        Julian Satran/Haifa/IBM@IBMIL
            Subject:        UNH Plugfest



    Attached are some of the issues that arose during the first day
    of the iSCSI plugfest at UNH on Monday 11-February-2001.

    Bob Russell
    InterOperability Lab
    University of New Hampshire


    1a)The following operational keys are labeled with "Use: ALL" and have
      session-wide applicability:

      This means that they can be negotiated during the login phase for
      any connection in a session, as well as during full feature phase on
      any connection in a session, but at the successful conclusion of that
      negotiation, the results apply immediately to all connections in
      the session.

      The question is: "What is the rationale for making these 3 keys
      session-wide instead of connection-specific?"

      Phrased another way, the question is: "Would it not be better if these
      keys were connection-specific instead of session-wide?"

      In particular, it appears that dynamic changes to these values on one
      connection can have an effect on outstanding commands on other
      connections that requires considerable complication in implementations
      to handle correctly, yet the benefit is not obvious from the standard.

      Could someone please supply a rationale for keeping these keys


    Those key convey propoerties that are specific to the SCSI target (not iSCSI transport).
    Using R2T means not allocating SCSI buffers for unsolicited commands (that you have no idea on what connection they will be comming).


    1b)A related issue is that the values negotiated for InitialR2T and
      ImmediateData are intimately intertwined, as evidenced by the
      table accompanying the description of ImmediateData in Appendix D.

      However, InitialR2T has a specific restriction (in the description
      of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no',
      it cannot be set back to 'yes'. BidiInitalR2T has the same restriction.
      But ImmediateData does not have this restriction.

      The question is: "Why doesn't ImmediateData have a similar restriction?"

      In particular, this restriction on (Bidi)InitialR2T limits the
      possibilities for (re)negotiation at any time on any connection
      mentioned in 1a above, because once unsolicited data PDUs have been
      negotiated off, they can never be negotiated on again, effectively
      eliminating InitialR2T from all further negotiations.

      Could someone please supply a rationale for allowing ImmediateData to
      be negotiated on/off at any time on any connection but not InitialR2T?


    We saw no reason to force the targets to handle the "uncertainty" related to the transition from No to Yes of R2T (i.e., when can the target remove resources related to the unsolicited data).  We saw a need for a yet-to-no transition (speed increase) but none for a no-to-yes.
    Immediate data on the other hand has a very restricted and well-defined resource need - a single PDU asociated with the command and there is no uncertainty in the transition (or very limited).

    2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text
      Response pdu.  It says that when the target has more work to do, it
      MUST set the Target Transfer Tag to some value other than 0xffffffff.
      When the target does not have more work to do, the standard does not
      say what value the Target Transfer Tag should have.  There are 2

      a. If the target must set the Target Transfer Tag to 0xffffffff,
         then the standard should state this explicitly.
      b. If the target can set the Target Transfer Tag to any value
         (or leave it undefined) then it appears that there is no need to
         reserve 0xffffffff for the Target Transfer Tag at all, and there
         is no need to require a value other than 0xffffffff when F = 0
         (any value will work fine).

    The value 0xfffffff should be used exclusively to covey a "soft reset" i.e., while the target has more work to do the initiator wnats to start fresh
    I will try to make clear in the text that if there is no more work to do it MUST be set to 0xffffffff


    3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
      an R2T to at most MaxBurstSize.  What is the rationale for this?

       An R2T is sent by the target to the initiator, so why can't the
      target specify any size it wants in the R2T?  The target already
      uses R2Ts to control the flow of Data-Out PDUs from the initiator,
      so why impose this restriction on the R2Ts?

      Could someone please explain the benefit to this limitation on R2Ts?

    +++ Is this a plugfest question or one of your own?  For your own questions the channels are always open.  The MaxBurstSize is there to enable the initiator to share resources between several executing commands and limit the number of "pending buffers" a target will have to keep

    in case one of the Data Out PDUS is damaged and transfer to a device is not possible.


    4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy
      a SCSI read command can be split into sequences each terminated by
      a pdu having F=1.  The standard does not seem to require that this
      be done.  However, if it is done, then the description of MaxBurstSize
      in Appendix D limits these sequences to at most MaxBurstSize bytes.

    4a.The first question is: "What is the benefit for allowing the
      Data-In pdus to be split into sequences?"

      It appears that doing so forces a dual role on the F-bit -- as end of
      sequence and as end of all input -- and complicates the interpretation
      of this bit in the initiator.  This feature seems to be necessary to
      change direction in bidirectional transfers, but are there other uses
      for this?

    +++ End of all input is the satus or Response - no ambiguity +++

    4b.The second question is: "Is the target required to split Data-In pdus
      into sequences?"

      If so, this should be made explicit in the standard, and the rationale
      for this should also be given.

    +++ It is required and the rational is in (version 10). The rational is direction change and Ack if required +++


Last updated: Wed Mar 27 15:18:21 2002
9348 messages in chronological order