Subject: Re: iSCSI : On the subject of R2T and Task Tags.

From: [email-masked]
Date: Mon, 8 Jan 2001 09:58:16 +0200

Answers in text  - Julo

Santosh Rao <[email-masked]> on 08/01/2001 05:34:52

Please respond to Santosh Rao <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  iSCSI : On the subject of R2T and Task Tags.

On the subject of R2T and task tags .....

Section 2.16. R2T
=============
1) Differing nomenclatures "Target Task Tag" and
"Target Transfer Tag" for the same field. Only 1 of the 2 should
be used. The current semanticsof this field seem to call for a
"Target R2T Tag" name and not a "Target Task Tag",
since this is not per task.

<js> will fix </js>

2) The READ I/O PDUs do not use a "Target Task Tag".
The WRITE I/O PDUs use a "Target Task Tag" per R2T
and not per task.

It seems like the only unique per I/O identifier is the Initiator
Task Tag. (?) Is it the intention of iSCSI that targets should be
using the Initiator Task Tag as the per I/O lookup tag ?

If this is true, then, the name "Initiator Task Tag" is a misnomer
and it should just be "Task Tag", since it is used by both initiators
and
targets.
<js> We use initiator and target for the task to state who is "generating"
the tag </js>
Explicitly stating the semantics of "Target Task Tag" in
Section 2.2 would help, particularly since, it seems like iSCSI's
concept of "Target Task Tag" differs from the semantics of the
equivalent(?) RX_ID in the Fibre Channel header.

iSCSI seems to be more closely aligned with Parallel SCSI's
single Queue Tag model than Fibre Channel's OX_ID/RX_ID
tag model.
<js> iSCSI is completely neutral to the targets use of the target transfer
tag
it can follow both models. The iSCSI protocol treats the as an opaque
handle to
give back to the target to do the association.
</js>
3) Quoting from the draft :
"The present document does not limit the number of outstanding
datatransfers."

As we had discussed earlier, this needs to be removed, since
MaxOutstandingR2T bounds the number of outstanding R2Ts.
<js> will remove the offending statement </js>
Thanks,
Santosh

 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Mon, 8 Jan 2001 23:30:35 -0800 (PST)

Julian,

Thanks for the clarifications. One further question below (that I've asked

> <js> We use initiator and target for the task to state who is "generating"

Since a READ Data PDU has no Target Task Tag, is it the expectation that
iSCSI targets should perform a lookup on the Initiator Task Tag to obtain
their per-task data structure ? This is a performance penalty, if so.

Again, with WRITE Data PDUs there is no target assigned
per-task tag. While one could argue about vertically encoding the Target
Task Tag and the Target Transfer Tag into the same "Target Transfer Tag",
this would seem like an ugly hack to work around a shortcoming in the PDU
header. It would be desirable to have seperate Target Task Tag fields for
both READ and WRITE Data PDUs.

Thanks,
Santosh 

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################