Subject: RE: iSCSI draft-07 Padding

From: Robert Snively <[email-masked]>
Date: Tue, 24 Jul 2001 06:34:07 -0700

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" <[email-masked]>
To: <[email-masked]>
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.
>

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 24 Jul 2001 19:00:10 +0300

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 <[email-masked]> on 24-07-2001 18:13:14

Please respond to Michael Schoberg <[email-masked]>

To:   "[email-masked]'" <[email-masked]>
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:[email-masked]]
: Sent: Tuesday, July 24, 2001 8:34 AM
: To: [email-masked]
: 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" <[email-masked]>
: To: <[email-masked]>
: 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.
: >
:

---

From: Robert Snively <[email-masked]>
Date: Tue, 24 Jul 2001 16:37:44 -0700

The burst of data (sequence in FCP-2, I assume a PDU in iSCSI) 
carrying the last byte (as defined by the highest displacement of
the SCSI data pointer) may be padded by 0,1,2,or 3 bytes to bring
the last PDU to a 4-byte transfer boundary.  The number of bytes
padded is included in the last transfer header, so they can be
ignored and not passed to memory in an automated manner.

Bob

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 10:30 AM
To: Michael Schoberg; [email-masked]
Subject: Re: iSCSI draft-07 Padding

What does a Fibre Channel driver do when the ULP wants to receive data into
memory which is not a multiple of 4 bytes long?

Eddy

---

From: "Robert Griswold" <[email-masked]>
Date: Wed, 25 Jul 2001 15:38:26 -0500

I am generally in agreement with those discussing the 'bad iSCSI'
behavior on this thread, but am reluctant to spend too many words
defining implementation guidelines in the body of the specification.  By
Julian using 'should' we allow the bad to take place, but do not lock
out the unknown legitimate use of such a transfer.  I would like to
think that if the I_T nexus can operate on a set of parameters governing
communication, and within the bounds of the transport and protocol, that
the communication would be allowed to take place.  A simple annex or
white paper would be good to explain why not to do something bad.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Julian Satran [mailto:[email-masked]] 
Sent:	Tuesday, July 24, 2001 11:00 AM
To:	[email-masked]
Subject:	RE: iSCSI draft-07 Padding

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

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.