Re: iSCSI Plugfest at UNH

["Julian Satran" <Julian_Satran@il.ibm.com>]

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

sandeepj@research.bell-labs.com (Sandeep Joshi) on 19-07-2001 20:17:39

Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)

To:   "ips" <ips@ece.cmu.edu>
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.++++