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



    I agree with Eddy -- if we want a Target Transfer Tag in the
    DataIn PDU, then it is better to do whatever is needed to
    keep consistency in the location of fields across all PDUs,
    even if it means changing 2 PDUs to do so.
    The final result is a much better, easier to comprehend and
    easier to implement spec.  Just imagine trying to justify the
    inconsistency a year from now :)
    
    Bob Russell
    
    
    On Wed, 20 Feb 2002, Eddy Quicksall wrote:
    
    > My feeling is to bight the bullet now and keep the consistency.
    >
    > Eddy
    >
    > -----Original Message-----
    > From: John Hufferd [mailto:hufferd@us.ibm.com]
    > Sent: Tuesday, February 19, 2002 9:52 PM
    > To: Eddy Quicksall
    > Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu
    > Subject: 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 12:17:59 2002
8804 messages in chronological order