Assert fail using zero copy buffers porting FreeRTOS-Plus-TCP V3.1.0 to V4.2.2

Libraries
1

Greetings,
I successfully ported our app from FreeRTOS-Plus-TCP V3.1.0 to V4.2.2. Our app is working as it did running V3.1.0 however it is necessary to comment out the line:

vPreCheckConfigs( )

in

BaseType_t FreeRTOS_IPInit_Multi( void )

The following two asserts fail:

configASSERT( ipBUFFER_PADDING >= 10U );
configASSERT( ( ( ( ipSIZE_OF_ETH_HEADER ) + ( ipBUFFER_PADDING ) ) % 4U ) == 0U );

We have been using an implementation of zero copy buffers all the way back to when we started using the stack (Build 160112 in 2016). Our configuration has:

ipconfigPACKET_FILLER_SIZE = 0
ipBUFFER_PADDING = (8U + ipconfigPACKET_FILLER_SIZE)

As far as I can tell we aren’t now or were prior suffering performance issues or failure related to unaligned access.

I hate to modify library code to use it. Is the check necessary?
Curious to hear your thoughts.

Thanks!

2

Hi @blanco-ether,

Is there any particular reason for you to custom define ipconfigPACKET_FILLER_SIZE as 0 in your FreeRTOSIPConfig.h?

The reason for the default definition of ipconfigPACKET_FILLER_SIZE as 2 in the FreeRTOSIPConfigDefaults.h is to force the IP header of network packets to start at a 32-bit aligned address (ethernet header is considered to be 14 bytes; adding 2 makes it have the required alignment) so that in most platforms it makes the code more efficient and avoids failures when used with caching enabled.

3

Apologies for the late reply but I had to spend time retracing the logic behind our implementation.

| Offset | Alignment | Length | Comments

32 64 32 64 32 64
0 0 4 8 4 8 uchar_8 * pointer; Points to the ‘NetworkBufferDescriptor_t’.
4 8 4 8 6 6 uchar_8 filler[6]; // To give the +2 byte offset.
—
10 14 4+2 8+2 6 6 uchar_8 dest_mac[6]; // Destination address . <---- processor MAC requires this offset to be 32bit aligned
16 20 4 8 6 6 uchar_8 src_mac[6]; // Source address.
22 26 4+2 4+2 2 2 uchar16_t ethertype;
24 28 4 4 ~ ~ << IP-header >> // word-aligned, either 4 or 8 bytes. <---- processor MAC requirement prevents this offset from ever being 32bit aligned

Maybe I’m missing something or implemented no copy buffers in an unanticipated manner. I haven’t worked with any MAC controllers other than the one in our processor so I do’t have a reference as to how other MAC controllers implement receiving Ethernet packets.