Unsolicited data

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Julian:

The warning in section 8.6 of draft 06-99 still does not solve the
problem and is in fact wrong.  It now reads:

  "However negotiating an amount of unsolicited data for writes and
   sending less than the negotiated amount when the total data amount to
   be sent by a command is larger than the negotiated amount may
   negatively impact performance as the targets will not be able to ask
   for the remainder of the data."

The problem is, even if the initiator DOES send the full negotiated
amount, the target does NOT know this in advance and therefore cannot
send out the R2T for the rest until getting the unsolicited data PDU
with the F bit set to 1.  In other words, even the very best
implementation of an initiator does NOT solve the problem -- the target
still does NOT know what is coming because the initiator can NOT tell him.
Performance is ALWAYS impacted, regardless of what the initiator does.

The simplest solution would be to REQUIRE the initiator to send
the negotiated amount (after all, if he doesn't want to send that much
every time then why did he negotiate that much?).  Then the target
will know, in advance, what is coming and send out the R2T for the
rest of the data WITHOUT WAITING!  This is where the performance gain
is to be found.

(In all of the above discussion I am assuming the Expected Transfer
Length is greater than the First Burst Size.  The acutal requirement
for sending unsolicited data is that the initiator be required to
send min(Expected Transfer Length, First Burst Size) as unsolicited
data if unsolicited data has been negotiated.)

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774