I have been looking closely at FreeRTOS+TCP(160112) source and examples related to implementing zero copy support. I have also read the following threads related to providing newtork buffers and alignment.
It is clear to me why the padding is used in the buffer, I do that kind of thing in my own code often. What I am having a hard time understanding is implementation for a case where ethernet hardware requires buffers on 32bit alignment. First assume that the buffers are sized max packet + ipBUFFER_PADDING and are indeed aligned on even 32bit boundaries. In this case I reason that the value of ipconfigPACKET_FILLER_SIZE would need to be 0 or possibly 4. Assuming that this assertion is so the value of ipBUFFER_PADDING would be an even multiple of 32 bits. The result is that the buffer (base addr + ipBUFFER_PADDING) that harware uses is on even 32bit boundary and there is still space in front of the hardware buffer for FreeRTOS+TCP to use. If I understand correctly this will satisfy hardware requirements but the consequence is that FreeRTOS+TCP will be somewhat less efficient when it “cracks” the packets because fields are more favorably aligned when ipconfigPACKET_FILLER_SIZE is 2. Is this right?