[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: sector alignment for DataOut PDUs?
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:email@example.com] Sent: Wednesday, February 27, 2002 11:26 AM To: Paul Koning; Eddy_Quicksall@ivivity.com Cc: firstname.lastname@example.org 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: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of Paul Koning Sent: Wednesday, February 27, 2002 5:20 PM To: Eddy_Quicksall@ivivity.com Cc: email@example.com 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
Last updated: Wed Feb 27 21:18:07 2002
8919 messages in chronological order