Subject: Re: iSCSI: Byte padding requirement question

From: [email-masked]
Date: Fri, 5 Jan 2001 10:46:11 +0200

Wan-Hui,

Yes it is a side effect of the marker and we could have made it optional
but it ends up being messy if you admit
non-symmetric situations in which you send markers but do not receive them
or viceversa.
As padding does not practically add too much I thought it would be simpler
for the implementers to have it always (and I've resisted previous requests
to include padding!).

Regards,
Julo

"Lee, WanHuiHendra" <[email-masked]> on 05/01/2001 04:49:00

Please respond to "Lee, WanHuiHendra" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  iSCSI: Byte padding requirement question

Julian,

In the length field description (section 2.2.3 Length):
"... The length field accounts for proper iSCSI PDU content; whatever
padding is required to reach a 4 byte boundary in the TCP stream is implied
by the protocol but not accounted for in the length field."

Is this a side effect requirement due to the added "framing using marker at
fixed interval" mechanism ?

If yes, since framing is a negotiated feature, would it make sense to make
the byte padding only a requirement if framing is enabled ?

If this is not due to the framing feature, could you let us know why it is
a
requirement (I did not see it in previous drafts) ?

Thanks,
Wan-Hui

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 09 Jan 2001 15:06:51 -0800

> non-symmetric situations in which you send markers but do not receive them

What makes it messy in non-symmetric situations?

> for the implementers to have it always (and I've resisted previous requests

Besides keeping markers out of iscsi headers, the main reason for padding is
that drivers want integers in the iscsi headers to always align on integer
boundaries.  Otherwise, most risc based processors will have to do a byte copy
to align the headers on integer boundaries.

-Matt Wakeley
Agilent Technologies