RE: iSCSI: DataACK SNACK

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

Yes, which means BegRun should be moved so the TTT can be in a consistent
place (20). Since it would be nice to have BegRun and RunLength contiguous,
maybe BegRun and RunLength could be moved to 40 and 44.

Eddy

-----Original Message-----
From: Chuck Micalizzi [mailto:chuck.micalizzi@qlogic.com]
Sent: Wednesday, February 20, 2002 11:07 AM
To: 'Eddy Quicksall'; John Hufferd
Cc: Julian Satran; ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK SNACK

Eddy, John,
       
        I assume the DataACK SNACK PDU will also have to change to include
        the TTT.

chuck

-----Original Message-----
From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Wednesday, February 20, 2002 6:31 AM
To: John Hufferd
Cc: Julian Satran; Chuck Micalizzi; ips@ece.cmu.edu
Subject: RE: iSCSI: DataACK SNACK


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.