Subject: RE: sector alignment for DataOut PDUs?

From: "Martin, Nick" <[email-masked]>
Date: Tue, 26 Feb 2002 18:14:28 -0600

Paul,

For all data carrying PDUs except the last in a sequence, the sender is
expected to send maximum sized PDU allowed.  When the negotiated maximum
is a multiple of 512, this effect is what you request.

I thought this was a requirement, but I did not find it as such in draft
10.  I did find this:

: 8.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 sending data). In addition,
: immediate data are meant to reduce the protocol overhead (both
bandwidth
: and execution 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 performance and may not be supported by all the targets.

This is a warning that an initiator sending less than the negotiated
maximum when the expected data transfer is greater than the maximum a)
may reduce performance and b) may not be supported by all targets.

IMHO, it makes more sense to include stronger wording encouraging
maximum negotiated length transfers rather than to add another parameter
requiring PDU breaks on different boundaries.

If such initiator behavior may not be supported by all targets, then the
initiators SHOULD NOT do it.

A disk target which can not handle such behavior is forgiven in advance
;).

Thanks,
Nick

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2002 3:51 PM
> To: [email-masked]
> Subject: sector alignment for DataOut PDUs?
> 
> 
> In the past, a number of login parameters were specified as multiples
> of 512 bytes, which makes a lot of sense for disk targets (but not so
> much for tape targets).  With the spec as it stands now, you can
> negotiate pretty much arbitrary burst sizes etc.  And in any case, the
> sender can pick "strange" PDU sizes even if the negotiated sizes are
> multiples of 512, because after all those are limits, not required
> sizes. 
> 
> It would be very attractive for disk targets to be able to specify
> that they require DataOut PDUs to be multiples of 512 bytes in length.
> That way, any PDU would correspond exactly to one or more sectors,
> rather than potentially having several PDUs straddling sector
> boundaries as is currently permitted.  This could be done by a Boolean
> key (512 byte alignment, yes or no).  (An integer key would allow
> other values than 512, but I'm not sure that such flexibility is a
> whole lot more useful.)
> 
> Basically, the effect of this feature would be to tell the initiator
> that it must send DataOut PDUs and immediate data whose length is
> always a multiple of 512.  Obviously, targets can't ask for that
> unless the devices on that target already come with such a limitation.
> 
>        paul
> 
>

---

From: "Rod Harrison" <[email-masked]>
Date: Wed, 27 Feb 2002 02:08:27 -0000

Nick,

	This makes sense for unsolicited data but it doesn't stop the
initiator sending more than one "weird" sized DATA-OUT PDU in
response to an R2T, even if the R2T is for a multiple of 512
bytes.

	Strengthening the wording to make sending "full" PDUs a
requirement is not really practical in the post v08 world where
we don't have a negotiated PDU size. It would have made sense
when the max PDU size was agreed upon but given the current
scheme of allowing the receiver to name an arbitrary sized
maximum receive PDU it would place an unreasonable burden on the
initiator.

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of
Martin, Nick
Sent: Wednesday, February 27, 2002 12:14 AM
To: Paul Koning; [email-masked]
Subject: RE: sector alignment for DataOut PDUs?

Paul,

For all data carrying PDUs except the last in a sequence, the
sender is
expected to send maximum sized PDU allowed.  When the negotiated
maximum
is a multiple of 512, this effect is what you request.

I thought this was a requirement, but I did not find it as such
in draft
10.  I did find this:

: 8.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 sending data). In
addition,
: immediate data are meant to reduce the protocol overhead (both
bandwidth
: and execution 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 performance and may not be supported by all the targets.

This is a warning that an initiator sending less than the
negotiated
maximum when the expected data transfer is greater than the
maximum a)
may reduce performance and b) may not be supported by all
targets.

IMHO, it makes more sense to include stronger wording encouraging
maximum negotiated length transfers rather than to add another
parameter
requiring PDU breaks on different boundaries.

If such initiator behavior may not be supported by all targets,
then the
initiators SHOULD NOT do it.

A disk target which can not handle such behavior is forgiven in
advance
;).

Thanks,
Nick

---

From: Paul Koning <[email-masked]>
Date: Wed, 27 Feb 2002 13:57:17 -0500

>>>>> "Nick" == Martin, Nick <[email-masked]> writes:

 Nick> Paul, For all data carrying PDUs except the last in a sequence,
 Nick> the sender is expected to send maximum sized PDU allowed.  When
 Nick> the negotiated maximum is a multiple of 512, this effect is
 Nick> what you request.

 Nick> I thought this was a requirement, but I did not find it as such
 Nick> in draft 10. ...

 Nick> IMHO, it makes more sense to include stronger wording
 Nick> encouraging maximum negotiated length transfers rather than to
 Nick> add another parameter requiring PDU breaks on different
 Nick> boundaries.

That sounds like a fine suggestion, if it gives the target enough
power to achieve the alignment I'm looking for.  Strengthening the
text you quoted is a start, but other places would have to be
strengthened as well -- for example the rules on responding to an R2T.

 Nick> If such initiator behavior may not be supported by all targets,
 Nick> then the initiators SHOULD NOT do it.

That's not sufficient.  You need "MUST NOT".  The reason: if you say
"should not" then you can build a conforming initiator that cannot
interoperate with a conforming target.  All correctly written protocol
specs have the property that conformance implies interoperability.
(Unfortunately, few specs pass this test... :-( )  So a target can be
allowed to rely on full size PDUs only if initiators are required (not
merely encouraged) to send full size PDUs.

       paul