Subject: Re: iSCSI Plugfest at UNH

From: "Julian Satran" <[email-masked]>
Date: Fri, 20 Jul 2001 08:23:01 +0300

Sandeep,

Correct, but the delay is introduced by the initiator in question and the
bad behaving initiator is the only one to suffer the penalty.
Nobody else is harmed.  A badly behaved initiator may do many other things
that can negatively impact it's performance.
On the other hand if we insist on enforcing the negotiated limit we might
end-up prohibiting legitimate behavior like using the unsolicited data as a
variable length control section and have the R2T come from a device that
paces (forces the rate) the initiator.  Again we think that a variable
length unsolicited data piece is legitimate and as long as the performance
will be impacted only for the specific initiator we should abstain from
imposing additional restrictions to it.

As a side note I would like to point out that a clever target that has no
restriction on data order (can work wit EMDP=1) can issue R2T immediately
after seing that the immediate data are not enough to satisfy
ExpectedDataLength in any case, and if realizing later that it misses data
(the gap) it can request them with an additional R2T.

And BTW - congratulations for your implementation - one of the firsts to
use multiple connections flawlessly.

Regards,
Julo

[email-masked] (Sandeep Joshi) on 19-07-2001 20:17:39

Please respond to [email-masked] (Sandeep Joshi)

To:   "ips" <[email-masked]>
cc:
Subject:  Re: iSCSI Plugfest at UNH

> > +++ Should we really? A good driver will do what it can to optimize its
use
> > of resources while getting maximum performance. IMHO a warning to
> > implementers will be enough and I will try to put it in.++++

Julian,

Matthew Burnbridge explained this well at the plugfest meeting.

The problem is that the target does not know if its dealing
with a good initiator or a bad one.   The protocol is introducing
needless network delay (wait states!).

Why wait for the final bit if the target has enough memory to
handle all the data right away (and could send R2Ts *NOW*) ?

Regards,
-Sandeep

>  12.If unsolicited data is negotiated, it appears that it still does not
>     have to be used.  In practice this can lead to performance
> inefficiencies.
>
>     Consider the following:
>         - Unsolicited data has been negotiated to YES but immediate data
>           is NO (although a problem still exists even if this is YES).
>
>         - The initiator sends a SCSI command with F=0, W=1 and a large
>           Expected Transfer Length field (greater than FirstBurstSize).
>
>         - When the target receives this command, it knows that
unsolicited
>           data follows (because F=0), but does NOT know how much (there
>           is a maximum determined by the negotiated FirstBurstSize, but
> there
>           is no requirement that the initiator actually send this much).
>           Therefore, the target cannot at this time send out an R2T to
get
>           the "rest" of the data --  it must wait to receive data PDUs
>           until it gets the F=1 set on one of these data PDUs, and then
>           compute the amount of data to ask for in the R2T.  This may
>           introduce needless delay.
>
>           To avoid this situation, the standard should either:
>           - require that when unsolicited data is to be sent, that the
>             amount be min(Expected Transfer Length, FirstBurstSize),
>           - alternatively, provide a field in the SCSI command that
>             allows the initiator to indicate how much unsolicited data
>             follows.
>
> > +++ Should we really? A good driver will do what it can to optimize its
use
> > of resources while getting maximum performance. IMHO a warning to
> > implementers will be enough and I will try to put it in.++++

---

From: "Rod Harrison" <[email-masked]>
Date: Mon, 23 Jul 2001 12:44:48 -0500

Sandeep,

	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.

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of
Sandeep Joshi
Sent: Monday, July 23, 2001 10:31 AM
To: [email-masked]
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

---

From: Sandeep Joshi <[email-masked]>
Date: Mon, 23 Jul 2001 11:30:39 -0400

Hi Julian,

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

   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

---

From: "Matt Wakeley" <[email-masked]>
Date: Mon, 23 Jul 2001 16:20:32 -0700

>    set the Initiator Task Tag to 0x'ffffffff if its an

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.

>    than the cmdSN of the original command (for which response

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?

>    prevent such targets from being deployed :-)

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

>    this feature had to be enabled or disabled frequently at

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

>    or we should add a key "SendStatusInReadPDU=yes/no".  The first

-Matt