Re: Fast multi-task abort model

On Dec 8, 2005, at 10:45 AM, Mallikarjun C. wrote:

>> If the target breaks the buffer associations, does
>> it really have to
>> invalidate the TTT?
>
> We may be using different terminologies.....

Probably.

> I think of:
> "invalidating the TTT" = "breaking the buffer
> association" = "not having a buffer behind a TTT"
>
> And that can be a serious problem in iSCSI-3720, and
> fatal in iSCSI/iSER.

Because of that concern, I would like to suggest we refine our 
terminology, and make a distinction that hasn't been made before.

I suggest we consider "breaking the buffer association" at the SCSI 
layer to be separate from breaking it at the iSCSI level. All the task 
state diagram in SAM-2 (and later SAM) care about is the SCSI layer.

Specifically, I think it'd be fine for an abort to leave the TTT's 
buffer around and simply do nothing with it once the TTT is done. Thus 
all the PDUs flying at the target still find a destination (either in 
TCP iSCSI or iSER).

>> I think it's fine for a task to be
>> terminated at the
>> SCSI level yet still have things going on (being
>> cleaned up) at the
>> iSCSI level.
>
> Precisely.  That's the fast multi-task abort model.
>
> I don't see a disagreement wrt the preferred behavior.
>  Only on the mechanics of how to phase it in.  I think
> if the inter-nexus TTT wait requirement from the 3720
> text is deleted, we have to add several careful
> sentences on how it would still work well with both
> iSCSI-3720 and iSCSI/iSER.  By then, we would have
> suggested enough deltas to protocol behavior that it
> would be very close to the new proposal.

Kind of. I agree we will need to add text, but I don't think it will be 
that bad.

I see the inter-nexus-TTT-fixup idea as an intermediate step between 
what we have now and the new multi-task abort model. We add the idea of 
not waiting for inter-nexus cleanup to finish (we do wait for it to 
start!) and we add the idea that data arriving after cleanup started to 
not get used by the SCSI layer. The new multi-task abort model then 
adds a method by which we can cleanly fix multiple tasks at once.

> Note that this is different from scratching the other
> two waits - inter-nexus CmdSN gap wait, inter-nexus
> StatSN ack wait.  They can be simply dropped without
> any additional mandates.

I still don't see how dropping the TTT wait will hurt more than the 
others. I'm really trying to, but can't.

I fully agree I'm proposing a notable protocol change. :-) The reason 
I'm contemplating it, much less strongly suggesting it, is that 1) I 
think the wait we have isn't workable. Something needs to be done. 2) 
I'm not really sure how initiators will notice the change. Since the 
on-the-wire PDUs won't change, I suspect many initiators will never 
notice.

Take care,

Bill

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