RE: iSCSI draft-07 Padding

["Julian Satran" <Julian_Satran@il.ibm.com>]

I'll add to 2.7.6:

   The Data Segments of Data-in and Data-out PDUs SHOULD be filled to
   integer number of 4 byte words (real payload) unless the F bit is set to
   1.

Julo

Michael Schoberg <michael_schoberg@cnt.com> on 24-07-2001 18:13:14

Please respond to Michael Schoberg <michael_schoberg@cnt.com>

To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI draft-07 Padding




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.
: >
: