SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: DataACK SNACK



    
    That would be possible.  Your suggestion changes two PDUs, OK, and keeps
    things somewhat more consistent
    
    The question is do we want to change two PDUs,
    or
    Change 1 PDU .
    
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Eddy Quicksall <Eddy_Quicksall@ivivity.com>@ece.cmu.edu on 02/19/2002
    03:21:03 PM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL
    cc:    Chuck Micalizzi <chuck.micalizzi@qlogic.com>, ips@ece.cmu.edu
    Subject:    RE: iSCSI: DataACK SNACK
    
    
    
    How about moving bi-di to 40 and residual count to 44?
    
    Eddy
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Tuesday, February 19, 2002 4:43 AM
    To: Julian Satran
    Cc: Chuck Micalizzi; ips@ece.cmu.edu
    Subject: RE: iSCSI: DataACK SNACK
    
    
    Julian,
    If you include the TTT in the Data-In PDU, you will need to change the
    format of the Data-In PDU.  The TTT is usually placed at displacement
    20-23, if you do that, you will have to reformat the Data-In PDU.  Perhaps
    the best thing to do is to move the residual count to displacement 44-47.
    This is the same displacement that is used by the SCSI Response PDU for the
    residual count for Bidirectional reads.  The other PDU that has a residual
    count, is the SCSI Response PDU and it also has residual in bytes 20-23, so
    there is no perfect solution.  What do you plan to do?
    
    If this change worth it?
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 02/15/2002 11:52:06 PM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    "Chuck Micalizzi" <chuck.micalizzi@qlogic.com>
    cc:    ips@ece.cmu.edu
    Subject:    RE: iSCSI: DataACK SNACK
    
    
    
    
    Chuck,
    
    The Initiator Task Tag is thhe only reliable indicator the protocol
    provides today.
    If nobody shouts against it we might let the target provide a Target
    Transfer Task for Data-In PDUs that have the A bit set
    to be returned with the ACK for target convenience.
    
    Julo
    
    
    
    
    
           "Chuck Micalizzi"
           <chuck.micalizzi@qlogic.co               To:        Julian
           m>                               Satran/Haifa/IBM@IBMIL
                                                    cc:
           15-02-02 23:14                   <ips@ece.cmu.edu>
                                                    Subject:        RE: iSCSI:
                                            DataACK SNACK
    
    
    
    
    
    
    Julian,
    
        Thank you for the response.
    
        Let me try to be  more direct. If a target has been issued multiple
        read commands, with transfer counts that exceed the negotiated
        maxBurstSize. After the target sends a data sequence for one of these
        commands must it wait for a DataACK before sending a data sequence
        for another command. Or is it free to send a data sequence for each
    outstanding
        command?
    
        If the target can have a data sequence in flight for each active
    command then
        it must expect a DataACK for each sequence sent with the Acknowledge
        bit set. If the DataACK SNACK doesn't include a task Tag the target
    can't be
        certain as to which data sequence the initiator is acknowledging.  So
    how can
        the target determine which resources to free or which sequence to send
    next?
    
    chuck
    
    
    
    
    
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Friday, February 15, 2002 9:30 AM
    To: Chuck Micalizzi
    Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
    Subject: Re: iSCSI: DataACK SNACK
    
    
    DataACK is a "bulk ack". Answering the last (in case of several) is good
    enough.
    I fail to see your point.
    
    Julo
    
    
              "Chuck Micalizzi"
              <chuck.micalizzi@qlogic.com>                 To:
              Sent by: owner-ips@ece.cmu.edu        <ips@ece.cmu.edu>
                                                           cc:
              14-02-02 21:02                               Subject:
                                                    iSCSI: DataACK SNACK
    
    
    
    
    
    
    
    All,
    
      I have a question regarding DataACK.
    
      Rev. 10 section 10.16.1 states:
    
      For a Data/R2T SNACK, the Initiator Task Tag MUST be set
      to the Initiator Task Tag of the referenced Command.
      Otherwise, it is reserved.
    
      it also states:
    
      The DataACK is used to free resources at the target and
      not to request or imply data retransmission.
    
      Is the target allowed to have more than one DataACK
      outstanding on a connection?
    
      If multiple outstanding DataACKs are allowed per connection
      then in my opinion the DataACK must have a valid task tag
      inorder for the target to associate the DataACK with the
      appropriate resources to be freed.
    
    
    chuck micalizzi
    Qlogic Corp.
    
    
    
    
    
    
    
    
    


Home

Last updated: Wed Feb 20 10:18:11 2002
8796 messages in chronological order