Subject: iSCSI draft-07 Padding

From: Michael Schoberg <[email-masked]>
Date: Fri, 20 Jul 2001 15:27:36 -0500

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: Pierre Labat <[email-masked]>
Date: Fri, 20 Jul 2001 15:55:21 -0700

> stream one would expect, but it's allowed in the draft.

Michael,

I think that the performance will be so poor that it will bury the vendor
before
he had time to sell anything.

> in a simpler software/hardware design.

I don't like this idea. The protocol must have the flexibility to work with
PDUs
as small as needed to put one PDU per TCP segment.
This will help a lot the hardware to deal with out of order or missing TCP
segments
at high rates.
If we don't have this possibility we need to rely on an intermediate chuncking
protocol that we don't have now, or on the markers but they moved as an annex.
Hence to preserve all our chances to have a protocol that flies at 10G i would
not
put this minimum size limitation.

Regards,

Pierre

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 23 Jul 2001 18:16:01 -0400

One problem I can see with pad in data is when receiving directly to the ULP
buffers. Since you shouldn't trash the end of a ULP buffer, wouldn't it be
better not to have the pad at all?

I suppose the original idea was for a hardware reason but then the hardware
has to finally deal with this "non-trashing" situation anyway and not store
the pad into memory.

Eddy