Re: iSCSI: Byte padding requirement question

[Matt Wakeley <matt_wakeley@agilent.com>]

julian_satran@il.ibm.com wrote:
> 
> 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.

What makes it messy in non-symmetric situations?

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

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

> 
> Regards,
> Julo
> 
> "Lee, WanHuiHendra" <WanHui_Lee@adaptec.com> on 05/01/2001 04:49:00
> 
> Please respond to "Lee, WanHuiHendra" <WanHui_Lee@adaptec.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> 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