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

[Mike Brown <mbrown@cs.uml.edu>]

>For convience of programming at the initiator, it would be best to let the 
>initiator decide if it wants to use the ITT or not.

Actually, adding this check should be quite trivial for initiators.
Something like:

if (!ulp_scsi_command->is_tagged) {
  iscsi_scsi_cmd.itt = 0xffffffff;
} else {
  iscsi_scsi_cmd.itt = iscsi_itt++;
}

Linux initiators could do something like:
/* in queuecommand() */

if (!SCpnt->tag) {
  iscsi_scsi_cmd.itt = 0xffffffff;
} else {
  iscsi_scsi_cmd.itt = iscsi_itt++;
}

This doesn't seem to be an unreasonable request if it significantly
simplifies target code.

>What is the problem from the target's standpoint if there is a value in the 
>ITT for an untagged request?
>
>Eddy
>
>
>----Original Message Follows----
>From: Mike Brown <mbrown@cs.uml.edu>
>To: rod.harrison@windriver.com
>CC: ips@ece.cmu.edu, sandeepj@research.bell-labs.com
>Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd)
>Date: Mon, 23 Jul 2001 14:21:59 -0400 (EDT)
>
>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
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>


-Michael F. Brown, UMass Lowell Computer Science

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

"Black holes are where god divided by 0."