Padding Preceding CRC

["Williams, Jim" <Jim.Williams@emulex.com>]

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.