RE: iSCSI Plugfest at UNH (misc issues) (fwd)

["Rod Harrison" <rod.harrison@windriver.com>]

	A couple of points.

	The initiator task tag is not a SCSI object, it is an iSCSI
object. The iSCSI spec makes no correlation between the ITT
and SCSI task tags. The ITT is the only routing object
available to the initiator and should be opaque to the
target, as should the target task tag to the initiator. I am
of the opinion that the Attribute field of the iSCSI Command
PDU tells the target which type of tag it should generate
for the SCSI operation.

	Since command sequence numbers are session wide and there
are likely to be multiple LUNs in the session, forcing the
initiator to use a constant ITT for untagged commands will
be problematic.

	What exactly is the difficulty at the target side with
preserving the ITT irregardless of the attribute setting?

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Mike Brown
Sent: Monday, July 23, 2001 1:22 PM
To: rod.harrison@windriver.com
Cc: ips@ece.cmu.edu; sandeepj@research.bell-labs.com
Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd)


Rod,

>
>	The initiator needs the initiator task tag in order to
>associate inbound PDUs with the correct command. For
>untagged commands the ATTR field of the SCSI Command PDU
>should be set to 0, Untagged.

The initiator associates inbound PDU's with the itt.  I
agree with
Sandeep.  If the SCSI Command is untagged, then the itt
should
be explicitly set to 0xffffffff in the iSCSI PDU since the
initiator can
still use the itt to associate inboud iSCSI PDU's with a
current SCSI
command because SAM-2 sec 4.9.1 states:

"An untagged task does not include a tag in any of its
component
definitions, thus restricting the number of concurrent
untagged tasks in a
single task set to _ONE_ per initiator"

If there are multiple outstanding tasks, (one untagged task
and multiple
tagged tasks), each task will still have a unique itt, and
therefore the
initiator can associate inbound iSCSI PDU's with a
particular SCSI
command.

>
>	- Rod
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu
[mailto:owner-ips@ece.cmu.edu]On
>Behalf Of
>Sandeep Joshi
>Sent: Monday, July 23, 2001 10:31 AM
>To: ips@ece.cmu.edu
>Subject: Re: iSCSI Plugfest at UNH (misc issues)
>
>
>
>
>Hi Julian,
>
>Some additional items from the plugfest to resolve..
>
>1) Sec 2.3.1 : Untagged tasks.
>   If the task attribute in the SCSI Command is "untagged"
>   then the initiator task tag should be ignored, correct ?
>   Can the draft explicitly state that the initiator must
>   set the Initiator Task Tag to 0x'ffffffff if its an
>   untagged task.
>
>   Do we assume that the initiator ULP will not issue more
>than
>   one untagged tasks simultaneously ?
>
>2) ExpCmdSN
>   What are the semantics of something like this.. the
>   target does not increase the expCmdSN but keeps sending
>   the status (SCSI response) for commands after the
>expCmdSN ?
>   Clearly, the target has received and executed the
>commands
>   (in cmdSN order).
>
>   Hence, the expCmdSN in a SCSI response must not be less
>   than the cmdSN of the original command (for which
>response
>   is being received).
>
>   This seems like a valid property which could be mandated
>   and checked, to allow efficient initiator
>implementations.
>   The target eventually suffers but the standard could
>   prevent such targets from being deployed :-)
>
>3) Sending status in read PDU
>   Since quite a few initiators did not support this,
>   this feature had to be enabled or disabled frequently at
>   the target.
>
>   Either we should make it mandatory to implement (at
>initiator)
>   or we should add a key "SendStatusInReadPDU=yes/no".
The
>first
>   option seems simpler.
>
>thanks
>-Sandeep
>


-Michael F. Brown, UMass Lowell Computer Science

phone:  (978) 934-5354
email:  mbrown@cs.uml.edu

"If a driver behaves incorrectly, the Driver Verifier will
crash the system
 immediately. In this way, the Driver Verifier prevents the
driver bug from
 being masked by further processing. The result is a faster,
easier debugging
 process."          -Windows 2000 Driver Development Kit
Release Notes