I agree but let's hear arguments against if they are any. Julo
| Eddy Quicksall
<Eddy_Quicksall@ivivity.com>
16-02-02 19:47
| To:
Julian Satran/Haifa/IBM@IBMIL, Chuck Micalizzi
<chuck.micalizzi@qlogic.com>, cbm@rose.hp.com cc:
ips@ece.cmu.edu Subject:
RE: iSCSI: DataACK SNACK
|
Because of what Chuck pointed out, my feeling
is that the TTT should be provided when the A bit is set. It also makes the
association faster since the ITT would require a search by the target.
Eddy
-----Original Message-----
From: Julian
Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, February
16, 2002 2:52 AM
To: Chuck Micalizzi
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.com>
15-02-02 23:14
|
To:
Julian Satran/Haifa/IBM@IBMIL cc:
<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> Sent by: owner-ips@ece.cmu.edu
14-02-02 21:02
|
To:
<ips@ece.cmu.edu> cc:
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.