RE: sector alignment for DataOut PDUs?

[Paul Koning <ni1d@arrl.net>]

>>>>> "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