RE: iSCSI draft-07 Padding

[Michael Schoberg <michael_schoberg@cnt.com>]

Yes, at the very least the spec should not allow padding on intermediate
ReadData/WriteData bursts.  I can't think of a reason why one would want to
use odd length intermediate bursts, so hopefully it's safe to restrict it.
Padding the last burst still seems reasonable for easy CRC calculation.

Setting a fixed size is optional.  A minimum would avoid memory
fragmentation when working with memory descriptors.  

: -----Original Message-----
: From: Robert Snively [mailto:rsnively@Brocade.COM]
: Sent: Tuesday, July 24, 2001 8:34 AM
: To: ips@ece.cmu.edu
: Subject: RE: iSCSI draft-07 Padding
: 
: 
: Fibre Channel's approach to this problem is to prohibit padding
: for all transfers except the transfer that moves the last bytes
: in the last (or highest pointer value) burst of data.  Intermediate
: bursts are required to end on 4-byte boundaries, regardless of
: tranfer order as allowed by EMDP.
: 
: Bob
: 
: ----- Original Message -----
: From: "Michael Schoberg" <michael_schoberg@cnt.com>
: To: <ips@ece.cmu.edu>
: Sent: Friday, July 20, 2001 4:27 PM
: Subject: iSCSI draft-07 Padding
: 
: 
: > I couldn't find anything in the latest iSCSI spec 
: (draft-07) that prevents
: > someone from issuing multiple padded PDU's for iSCSI Data 
: In/Out segments.
: > I guess I'm worried that someone could issue padded 
: odd-length write/read
: > data when it wasn't necessary.  Example: When moving a 512 byte disk
: sector
: > an initiator/target could legally issue 512 1-byte DataSegmentLength
: > messages (each padded up to a 32-bit boundary).  This isn't 
: the sort of
: data
: > stream one would expect, but it's allowed in the draft.
: >
: > This also leads into whether fixed or minimum length data 
: segments (for
: all
: > but the last) would be nice to include as part of the spec. 
:  It may result
: > in a simpler software/hardware design.
: >
: