Subject: RE: sector alignment for DataOut PDUs?

From: "Julian Satran" <[email-masked]>
Date: Thu, 28 Feb 2002 21:19:51 +0200

It reffers explicitely (and with good reason) to unsolicited data ONLY.
See the archives for a reason.
Solicited bursts are what the target asks through R2T.

Julo

Paul Koning <[email-masked]>
28-02-02 16:40

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        RE: sector alignment for DataOut PDUs?

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Where is the hint you are alluding to? 

 >> ....  (It does
 >> hint that targets may object if you don't do it that way --
 >> which makes no sense at all unless there's a MUST for
 >> initiators to do what targets are allowed to expect.)

In this section:

     9.5  Unsolicited Data and Performance

        Unsolicited data on write are meant to reduce the effect 
        of latency on throughput (no R2T is needed to start send-
        ing data).  In addition, immediate data are meant to 
        reduce the protocol overhead (both bandwidth and execu-
        tion time).

        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 perfor-
        mance and may not be supported by all the targets.

Specifically, the last sentence.  That statement is not a good thing,
because it explicitly permits failures to interoperate, which a
protocol standard must never do.  Instead, a receiver must always be
required to accept anything that the standard permits the sender to
send in a state that the sender can legitimately get to. 

There are two ways to fix this: one is to forbid the sender sending
less than the negotiated unsolicited data length.  The other is to
require the receiver to accept unsolicited data of less than the
negotiated length.  Either change works because either change
establishes interoperability.

                     paul

---

From: Paul Koning <[email-masked]>
Date: Thu, 28 Feb 2002 16:04:08 -0500

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> It reffers explicitely (and with good reason) to unsolicited
 Julian> data ONLY.  See the archives for a reason.  Solicited bursts
 Julian> are what the target asks through R2T.

Yes, I realize that.

I'm afraid what happened is that the discussion drifted off to a
different (but related) topic.  Please ignore the "Subject" string on
the mail.  The new subject is: what should the sender and receiver
payload length rules be, to ensure interoperability?

My comment was specifically to the text of section 9.5.  It allows a
sender to send less than the negotiated unsolicited data length even
though there is more to be sent.  Yes, it says that's not optimal.
But it is allowed.

It then goes on to say that targets are allowed not to support
initiators that do this.  In other words, you're explicitly allowing
non-interoperable implementations.

I believe that this is not a good thing for a standard to do.
Unfortunately, it certainly happens that a standard, by accident, ends
up specifying legal combinations of choices that cause interop
failures.  But those should be viewed as bugs in the spec and should
be repaired when they are found.

So what I would like to see for section 9.5: either require senders to
send the full negotiated unsolicited data length as unsolicited data,
whenever they have that much total data to send -- or say that
receivers MUST accept unsolicited data of less than the negotiated
length even when the total I/O length is larger than that.  I prefer
the first choice (keep the target simpler).

As for R2T, is the same sort of question valid there?  As far as I can
tell, it is legal for the initiator to send less data than the amount
requested in the Desired Data Transfer Length.  If so, then for
interoperability the target must be required to handle that case.  On
the other hand, if you don't want to make the target deal with that
extra complexity, then the rule for R2T needs to be that the initiator
must respond with DataOut PDUs that add up to exactly the amount asked
for (rather than at most the amount asked for).  And just as for the
unsolicited case, either answer works but I prefer the one that keeps
the target simpler (i.e., require the full length).

    paul