[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Last updated: Wed Feb 27 15:18:07 2002
8911 messages in chronological order