Re: iSCSI Plugfest at UNH (misc issues)

["Matt Wakeley" <matt_wakeley@agilent.com>]

Sandeep Joshi wrote:
> 
> 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.

What is so bad about an initiator assigned a task tag even if the command is
flagged as "untagged"?  In the FC world, initiators use the tag to route
commands through the hardware.

I don't want to restrict h/w implementations from using a task tag even if the
command is marked untagged.

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

The iSCSI standard says that once SCSI commands get put into the task queue,
the CmdSN no longer associated with the command.  The initiator is NOT
supposed to associate commands with responses based on the CmdSN or ExpCmdSN.

But more importantly, what is the issue trying to be resolved here?

>    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 :-)

Until you identify the problem, I don't want any more "tests" mandated.

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

It is already mandatory to implement status in the read PDU.

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

-Matt