Re: v2 aligned buffer changes for erasure codes

[Janne Grunau <j@jannau.net>]

On 2014-09-18 13:01:03 +0000, Andreas Joachim Peters wrote:
> 
> >> For encoding there is normally a single buffer split 'virtually' 
> >> into
> >> k pieces. To make all pieces starting at an aligned address one 
> >> needs
> >> to align the chunk size to e.g. 16*k.
> 
> >I don't get that. How is the buffer splitted? into k (+ m) chunk size
> >parts? As long as the start and the length are both 16 (or 32) byte
> >aligned all parts are properly aligned too. I don't see where the k
> >comes into play.
> 
> The original data block to encode has to be split into k equally long 
> pieces. Each piece is given as one of the k input buffers to the 
> erasure code algorithm producing m output buffers and each piece has 
> to have an aligned starting address and length.
> 
> If you deal with 128 byte data input buffers for k=4 it splits like
> 
> offset=00 len=32 as chunk1
> offset=32 len=32 as chunk2
> offset=64 len=32 as chunk3
> offset=96 len=32 as chunk4
> 
> If the desired IO size would be 196 bytes the 32 byte alignment 
> requirement blows this buffer up to 256 bytes:
> 
> offset=00 len=64 as chunk1
> offset=64 len=64 as chunk2
> offset=128 len=64 as chunk3
> offset=196 len=64 as chunk4

I fail to see how the 32 * k is related to alignment. It's only used for 
to pad the total size so it becomes a mulitple of k * 32. That is ok 
since we want k 32-byte aligned chunks. The alignment for each chunk is 
just 32-bytes.

Janne