Re: iSCSI: iSCSI untagged task and SAM-2 SIMPLE task?

["John Hufferd" <hufferd@us.ibm.com>]

Let me see if I can explain it.

All the Commands carried by iSCSI carry a ITT, independent of whether SCSI
believes it is an untagged task or not.  When SCSI initiator sends the
command to the transport (iSCSI), it either assigns a Tag or not.  But
independent of that, iSCSI creates a tag of its own, so that it can have
its own control, and buffer management.

On the target side when the transport (iSCSI) gives the SCSI command to the
SCSI layer, it will also have a Tag, or not (depending on whether it was
tagged originally by the SCSI initiator).  There is nothing on the Target
side that needs the same tag that was originally created by the SCSI
Initiator.

Tagged and Untagged has nothing to do with iSCSI directly, except that the
SCSI command, when delivered to the SCSI Layer by iSCSI, must NOT be given
a Tag if the command was NOT given a tag by the SCSI initiator.  Hence
iSCSI needs to know how to deliver the untagged tasks to the Target SCSI
layer, and therefore, iSCSI needs an indication of whether this command was
originally tagged by the SCSI initiator or not.  (When the above is done
correctly, the issue of task queuing in the target SCSI layer, can then be
done as specified in SAM2.)

As far as the SCSI Task Tag itself, it is really a handle that permits the
SCSI Initiator process to "post" status of the I/O, etc. to the correct
thread after it has been handled by the Target SCSI Layer, as well as
various Task Management Functions, etc.

Many iSCSI implementations will be using the iSCSI ITT as an indirect
handle that points to the control block that contain the pointers to memory
where the data can be placed directly.  The same control block will also
probably have the SCSI Initiator's  64 Bit Task Tag.  The question then is
why also carry this additional 64 bit value back and forth across the link
when it is really only needed on the initiator side.  And some time ago it
was agreed not to do that.

How an iSCSI ITT is used to point to the control block that contains the
Initiator 64 bit value is an implementation issue, but it is clearly
straight forward to do.  The requirement for the target iSCSI
implementation is to hand to the target SCSI layer a unique value within
the I_T_L_Q Nexus.   Since the session itself bounds the I_T Nexus, the
issue of uniqueness within that session is basically what the ITT provides.
So I believe that many implementations, simply morph the 32 bit ITT into a
64 bit value, and hand that to the Target SCSI layer (for all SCSI tagged
tasks).

I hoped this helped and did not make it more confusing.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Luben Tuikov <luben@splentec.com>@ece.cmu.edu on 06/21/2002 01:56:55 PM

Sent by:    owner-ips@ece.cmu.edu


To:    iSCSI <ips@ece.cmu.edu>
cc:
Subject:    iSCSI: iSCSI untagged task and SAM-2 SIMPLE task?



What is the iSCSI ``Untagged'' task (9.3.1)?

SAM-2, 4.9.1 The Task Object, says:

`` An untagged task is represented by an I_T_L nexus
  (see 4.10) and is composed of a definition of the work
  to be performed by the logical unit, and implicitly
  a SIMPLE task attribute (see 7.5).''

and

`` Also, an untagged task is assumed to have a SIMPLE task
  attribute, leaving the initiator no control over its
  relationship to other tasks in the task set.''

So, what is the iSCSI ``Untagged'' task?
Shouldn't that be a SIMPLE task? And get rid of
the ``Untagged'' task?

Also SAM-2, 4.9.2 Task Tags says:

`` A tag is a field containing up to 64 bits that is a
   component of an I_T_L_Q nexus. An initiator assigns
   tag values in each I_T_L_Q nexus in a way that ensures
   that the nexus uniqueness requirements stated in 4.9.1
   are met.''

If the initiator assigns task tags in an I_T_L_Q nexus,
how are they known to the target in terms of iSCSI?

--
Luben