Re: iSCSI draft-07 Padding

["Eddy Quicksall" <ESQuicksall@hotmail.com>]

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

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