Subject: [Ips] task aborts, r2t, and the F bit

From: Paul Koning <[email-masked]>
Date: Tue, 13 Sep 2005 16:45:10 -0400

The spec in the discussion of task management says (page 129) that an
initiator MUST continue to respond to things like R2T after issuing an
Abort Task Set command.  But it is encouraged to make things finish
faster by sending F=1 in its responses.

That sounds reasonable... if you're trying to abort a write, it would
be good not to have to send that 2 megabytes of data you tried to
write.

However, the description of R2T clearly says that sending F=1 in a
DataOut at any byte count other than the exact byte count requested in
the R2T is an error.

So... did I misunderstand, and you really do have to send all the
write data for a write being aborted?  Or is the R2T rule supposed to
apply only when the task isn't being aborted?

      paul

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: William Studenmund <[email-masked]>
Date: Tue, 13 Sep 2005 16:02:29 -0700

> apply only when the task isn't being aborted?

As a target implementer I took the R2T rule to only apply when the task 
is healthy. If it's being aborted, it's ok to finish a target task 
early.

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Wed, 14 Sep 2005 15:22:46 +0300

Paul,

The rule about the R2T was meant for the case the target issued some R2Ts 
before receiving or acting on abort.
In this case a target may want to have all its R2T accounted for before it 
finishes the abort.

The data have to be all there if the initiator can't ascertain that the 
data will be received after the abort is initiated.

I assumed that when the initiator can be certain the data will be seen 
after the abort (e.g., they come on the same connection) it may ignore the 
"completeness" rule.
It should also be possible to ignore the rule unilaterally (at the 
initiator) but then the "SCSI" part of the initiator should be prepared to 
act on errors resulting from this behavior.

Julo

Paul Koning <[email-masked]> 
Sent by: [email-masked]
13-09-05 23:45

To
[email-masked]
cc

Subject
[Ips] task aborts, r2t, and the F bit

      paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 14 Sep 2005 11:01:18 -0400

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Paul, The rule about the R2T was meant for the case the
 Julian> target issued some R2Ts before receiving or acting on abort.
 Julian> In this case a target may want to have all its R2T accounted
 Julian> for before it finishes the abort.

 Julian> The data have to be all there if the initiator can't
 Julian> ascertain that the data will be received after the abort is
 Julian> initiated.

 Julian> I assumed that when the initiator can be certain the data
 Julian> will be seen after the abort (e.g., they come on the same
 Julian> connection) it may ignore the "completeness" rule.  It should
 Julian> also be possible to ignore the rule unilaterally (at the
 Julian> initiator) but then the "SCSI" part of the initiator should
 Julian> be prepared to act on errors resulting from this behavior.

Thanks, that makes sense.

There seems to be a difference in the spec when it talks about Abort
Task Set vs. Abort Task.  For the former, it explicitly requires that
all pending R2Ts must be answered.

For Abort Task, it doesn't say that, at least not explicitly.  We're
seeing an situation where we send R2T, the initiator answers with a
couple of the Data Out PDUs but not the complete set, and then instead
it sends Abort Task, and does NOT complete the R2T response.

So it seems that we have to get rid of the task when we receive the
abort, and assume that the rest of the DataOut burst will NOT arrive.
(But then if it does arrive because some different initiator does
complete the burst even after sending an Abort Task, we end up
complaining about DataOut for a TTT we no longer know...)

	    paul

---

From: Julian Satran <[email-masked]>
Date: Wed, 14 Sep 2005 19:37:26 +0300

Abort task MUST be issued on the same connection as the aborted command.
The R2T requirement becomes useless (you won't send data after the abort).

Julo

14-09-05 18:01

To
Julian Satran/Haifa/IBM@IBMIL
cc
[email-masked]
Subject
Re: [Ips] task aborts, r2t, and the F bit

                     paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 14 Sep 2005 12:57:28 -0400

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Abort task MUST be issued on the same connection as the
 Julian> aborted command.  The R2T requirement becomes useless (you
 Julian> won't send data after the abort).

That assumes that the part of the initiator that issues Abort Task is
synchronized with the fastpath machinery that answers R2T.  Is that
required? 

And yes, I agree that (if there is that synchronization) then
answering R2T after the Abort Task is not useful.  Does the spec
explicitly say that you MUST NOT send any more Data Out after an Abort
Task?  I couldn't find that.  

       paul

---

From: Julian Satran <[email-masked]>
Date: Thu, 15 Sep 2005 10:44:16 +0300

Paul,

The text does not say that you must not send Data Out after receiving 
abort.
However the text does not mandate them either. I was trying to explain why 
responding to R2T is mandated for abort task set and it is not mandated 
for abort task (but not forbidden either).

Julo

14-09-05 19:57

To

       paul

---

From: Paul Koning <[email-masked]>
Date: Thu, 15 Sep 2005 09:11:19 -0400

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Paul, The text does not say that you must not send Data Out
 Julian> after receiving abort.  However the text does not mandate
 Julian> them either. I was trying to explain why responding to R2T is
 Julian> mandated for abort task set and it is not mandated for abort
 Julian> task (but not forbidden either).

Ok, thanks.

That lack of detail doesn't help implementers.  The spec really should
discuss this explicitly.  Mallikarjun, perhaps something for your
document?

The conclusion I come to is that targets MUST assume that there will
be no more Data Out PDUs after an Abort Target.  If any do arrive,
they can handle them in the usual way.  Initiators that continue to
send Data Out after sending an Abort Task must be prepared to see
those PDUs rejected by the target.

Right?

	paul

---

From: Julian Satran <[email-masked]>
Date: Thu, 15 Sep 2005 16:53:12 +0300

> discuss this explicitly.  Mallikarjun, perhaps something for your

Text has to express clearly the intended spec and like any spec will say 
it with as few words as possible.
Adding words just increases the probability of errors.
I don't see it as lacking detail but it certainly lacks redundancy.

> be no more Data Out PDUs after an Abort Target.  If any do arrive,

I assume you meant Abort task. Yes targets are right to assume no more 
data-out after abort task.

> those PDUs rejected by the target.

Yes.