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

From: Santosh Rao <[email-masked]>
Date: Sun, 07 Jan 2001 19:34:52 -0800

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.

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.

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.

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.

Thanks,
Santosh

---

From: Raghavendra Rao <[email-masked]>
Date: Wed, 10 Jan 2001 14:39:23 -0500 (GMT)

>
> It imposes the target to do  score boarding  to know when all the data have
> been received. Letting the possiblility to the
>

I'm missing something here - When the 'F' bit is per R2T, why would one need
to spend additional effort to know whether the all the data has arrived for
the R2T ?

The 'F' bit helps in finding out if all the data for the R2T arrived or not.

The length + buffer offset help in finding out if all the data for the task
has arrived or not.

-JP

---

From: Raghavendra Rao <[email-masked]>
Date: Thu, 11 Jan 2001 16:17:50 -0500 (GMT)

> 
>
> When multiple R2Ts are outstanding, the targets need a tag per R2T to track 
> their
> SCSI State Table Entries for each R2T. While its usage depends on how each
> individual programming model implements this feature, I believe the header 
should
> provide support to track each R2T using an id that the target can lookup for 
its
> R2T data buffer pointers.
> 

If a target is doing the I/O in a lot of bits-n-pieces with several R2Ts,
it must already be spending a lot of cycles to complete the I/Os - And
I can't believe a lookup (if it needs to) is going to be excessively
harmful compared to the magnitude of processing it must already be doing
(in getting buffers available in piecemeal, allocating, building, and
transmiting R2T for each such buffer and tracking the I/O progress).

Let us also not overlook the link bandwidth utilization of such examples
of doing I/Os. Please explain what is the gain in improving a bad transfer
example ?

-JP

---

From: [email-masked]
Date: Fri, 12 Jan 2001 08:06:15 +0200

64 bit tags - that is a bit bloated.

Will have to look into it and consider has strong the mandate is.

I assume people where thinking of using addresses as tags.

Julo

Raghavendra Rao <[email-masked]> on 09/01/2001 21:18:49

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

To:   [email-masked]
cc:
Subject:  Re: iSCSI : On the subject of R2T and Task Tags.

> 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.
>

For a SCSI READ command, I don't think it'll be really useful to have a
target
task tag.

> Again, with WRITE Data PDUs there is no target assigned
> per-task tag. While one could argue about vertically encoding the Target

There is - this is done during R2T time and every solicited data PDU
from the initiator goes out with this tag.

BTW, SAM-2 rev 14 has 64 bit task tags; How are we handling situations
like these ?

-JP

---

From: [email-masked]
Date: Fri, 12 Jan 2001 11:58:46 +0200

That is taking a narrow view on the capabilities of implementers and
protocol analyzer designers.
Another viewpoint is have a minimalist design - do no specify what you
don't have to!

Julo

Santosh Rao <[email-masked]> on 11/01/2001 09:20:20

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

To:   [email-masked] (Venkat Rangan)
cc:   [email-masked] (Douglas Otis), [email-masked] (Matt
      Wakeley), [email-masked] (IPS Reflector)
Subject:  Re: iSCSI : On the subject of R2T and Task Tags.

The draft must provide for seperate fields to track the task and the R2T
along the lines of RX_ID and SEQ_ID in Fibre Channel. Implementations are
free to use them as they please and must use 0xFFFFFFFF as their un-used
values in these fields.

The advantage of defining the fields explicitly in the header as opposed
to allowing targets to vertically encode a portion of the tag field for
tracking the R2T is that these standard fields are interpret-able
by iSCSI Analyzers and will make debugging and tracking the
sequence of the I/O easier than implementation specific
vertical encoding into a single field.

Merging the 2 into a single field is akin to attempting to merge the
OX_ID, SEQ_ID and SEQ_CNT fields of FC into a single field and
allowing implementation specific vertical encoding. Standard defined
fields make for easier introp verification and debugging.

- Santosh

>
> Doug,
>
> The draft make should not make any statements about how a target chooses
to
> assign Target Task Tags. Some may choose to assign it per R2T, others may
> choose to assign it per task, based on how they choose to implement the
> target. Since the initiator is required to reflect it, I do not believe
> there are any interoperability issues. If an implementation wishes to do
a
> Task-SubTask breakdown, they can choose to partition the 32 bits into
> portions that can be used for identifying resources within the target.
>
> Venkat Rangan
> Rhapsody Networks Inc.
> http://www.rhapsodynetworks.com
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Douglas Otis
> Sent: Wednesday, January 10, 2001 5:27 PM
> To: Matt Wakeley; IPS Reflector
> Subject: RE: iSCSI : On the subject of R2T and Task Tags.
>
>
> Matt,
>
> With independent error checking requiring an additional level of error
> handling requesting repeated reads, there could be old responses combined
> with the retry from failed data digests. (If requesting overlapped reads
are
> prohibited, retry is an exception.) Without some means of identifying
which
> retry phase data is associated, a complete set would be difficult to
> confirm.  As order of each data portion is not mandated and these
transfers
> themselves may overlap, byte counts can not reveal completion.  Should
does
> not mean 'must.'
>
> Doug
>
> > Pierre Labat wrote:
> >
> > > I agree that the draft must not impose to the target to have a
> > different tag
> > > for each R2T (it is up to the target implementation to decide).
> >  I disagree
> > > to impose a unique target tag for the whole IO.  It imposes the
> > target to do
> > > score boarding
> > > to know when all the data have been received. Letting the
> > possiblility to the
> > > target
> > > to have one tag per R2T (or add a subtag identifying the R2T as
> > proposed Santosh)
> > >
> > > allows the target to dispense with the score boarding. The
> > target knows that all
> > > the
> > > data has been received when a data PDU with the "F" bit set has
> > been received
> > > for each R2T.
> >
> > There is no need to do scoreboarding.  Just count the number of bytes
> > received.  If they all add up, then you've received all the data.
> >  I for one
> > would not rely on a PDU with the "F" bit set.  I would want to
> > cross check it
> > with the correct number of bytes.
> >
> >
> > >
> > > Regards,
> > >
> > > Pierre
> > >
> > > >
> > > >
> > -Matt Wakeley
> > Agilent Technologies
> >
>
>
>

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