Re: ISCSI: Padding Preceding CRC

["Julian Satran" <Julian_Satran@il.ibm.com>]

Prasenjit,

Very good point.  And I have always maintained that padding on the wire 
has no meaning at all while alignment can be achieved through wise 
placement of buffers.

The only weak point in the argument arises when we decided to split the 
PDU in sub-entities and wanted to make sure that those will be also 
aligned and their "count" can be expressed in 4 byte terms (total AHS 
length).

Revising those will require some more reformatting of the iSCSI PDU.

Julo





Prasenjit Sarkar/Almaden/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
09-11-01 01:14
Please respond to Prasenjit Sarkar

 
        To:     "Williams, Jim" <Jim.Williams@emulex.com>
        cc:     "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        Subject:        ISCSI: Padding Preceding CRC

 



Isnt padding independent of CRC?



  
                    "Williams, Jim"   
                    <Jim.Williams@e       To:     "'ips@ece.cmu.edu'" 
<ips@ece.cmu.edu> 
                    mulex.com>            cc:    
                    Sent by:              Subject:     Padding Preceding 
CRC 
                    owner-ips@ece.c   
                    mu.edu   
  
  
                    11/08/2001   
                    02:29 PM   
  
  



The iSCSI spec indicates that the data will be padded
out to a length which is a multiple of 4 before the
CRC (digest) is appended.  In discussing this with our
hardware designers, I was told that this provides
no benefit to them, but causes a fair amount of pain.
As such I would like to raise the question of
whether the padding should be eliminated.

Computing unaligned CRCs is fairly trivial to do,
and must be done anyway.  This is because the
padding aligns the CRC with respect to the iSCSI
PDU, but one can't in general assume that the
iSCSI PDU is aligned with the TCP segment on
received data, and on transmitted data the
source may be a general gather list of unaligned
buffers.

I suppose this doesn't preclude doing a lot of
work to align the data before feeding it to the
CRC unit, but given how easy it is to compute
unaligned CRCs in hardware, there is no reason
to do this.

Inserting padding is extra work, however.  This
creates a bubble in the data flow pipe, extra
information that must be passed between hardware
units indicating the number of pad bytes to
be inserted, and extra logic to insert the
required pad data.

If someone can make a case why this padding is
a good thing, then certainly the hardware
problems are solvable.  But it looks to me
like a "feature" with cost but no benefit.