RE: sector alignment for DataOut PDUs?

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

I agree with Rod. If we changed the rule to require full PDUs, then we would
have to also change the negotiation for the related keys.

Pat

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Wednesday, February 27, 2002 11:26 AM
To: Paul Koning; Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: sector alignment for DataOut PDUs?


Paul,

	I strongly object to your alternative of tightening the spec
wording to force all PDUs to be max sized except the last. As I
mentioned in an earlier email, since draft v09 we don't have a
negotiated PDU size we have arbitrary maximums set by the
receivers. Forcing an initiator to send "full" PDUs is
unreasonable since the target may set a huge MaxRecvPDULength.

	The intent of the current wording was, if I remember correctly,
to have the initiator always send as much unsolicited data as
possible. This was to avoid the target having to wait for the F
bit on the unsolicited data before issuing R2T(s) for the
remaining payload. Note that unsolicited data, and its maximum
size, are negotiated parameters and that that current SHOULD is
quite different from forcing initiators to always send "full"
DATA-OUT PDUs.

	Please note that I don't object to your original proposal, just
to the alternative which I believe would be a huge functional
change.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Paul Koning
Sent: Wednesday, February 27, 2002 5:20 PM
To: Eddy_Quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: sector alignment for DataOut PDUs?


>>>>> "Eddy" == Eddy Quicksall <Eddy_Quicksall@ivivity.com>
writes:

 Eddy> Given that the TCP issues of reassembly are so much more
 Eddy> complicated than the concatenation issues necessary for
target
 Eddy> data alignment, is there really a problem here?

 Eddy> If there is a problem, can someone explain that in more
detail?

I'd describe it as an opportunity for optimization.

Yes, at the TCP level your segments can be strange sizes.  My
goal is
to make things better once you get up to the iSCSI level, and
you're
looking at an iSCSI PDU.

Right now, the initiator is allowed to send data out in strange
sized
chunks.  There's a requirement for 4 byte multiples but nothing
stronger than that.

If you're implementing a disk target, what you want to do is to
take
in the arriving stream of data from the initiator (DataOut or, if
applicable, immediate data) and send that off to disk as it
arrives.
If data out boundaries are 512 byte multiples, this is
straightforward: each time an iSCSI PDU arrives, you can send a
disk
write down your local disk I/O stack.  But as matters stand now,
it's
more complex because the data out may end in the middle of a disk
block, so the bookkeeping for what disk I/Os go with what iSCSI
PDUs
gets a lot more painful.

To add to this, it seems entirely likely that initiators will use
512
byte multiples, especially if you negotiate burst sizes and max
pdu
sizes that are 512 byte multiples.  But the current wording in
the
spec doesn't require that.  (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.)

So that's why I made the proposal.  An alternative would be to
tighten
the spec so it requires all but the last PDU to be exactly the
size of
the negotiated max size that applies.  That already appears to be
the
intent, so it may be the easier change.

	paul