FreeRTOS_TCP - zero copy - ipBUFFER_PADDING

heinbali01 wrote on Tuesday, June 21, 2016:

Hi Joe,

I’m sorry that I kept silent for so long, but it’s summer holiday time here :slight_smile:

The reason to have the pointer located before the network buffer is the zero-copy option for UDP. A UDP payload buffer can be translated to a network buffer and vice versa with these complementary functions:

NetworkBufferDescriptor_t *pxUDPPayloadBuffer_to_NetworkBuffer( void *pvBuffer )
uint8_t *pcNetworkBuffer_to_UDPPayloadBuffer( NetworkBufferDescriptor_t *pxNetworkBuffer )

You are right that for some platforms, the extra 4 bytes in front of the network buffer are not essential. And so this declaration:

    #define ipBUFFER_PADDING ( 8u + ipconfigPACKET_FILLER_SIZE )

may sometimes be replaced with:

    #define ipBUFFER_PADDING ( 4u + ipconfigPACKET_FILLER_SIZE )

I don’t mind allowing ipBUFFER_PADDING to get overridden by a new item called ipconfigBUFFER_PADDING from FreeRTOSIPConfig.h:

#if( ipconfigBUFFER_PADDING != 0 )
    #define ipBUFFER_PADDING    ipconfigBUFFER_PADDING
#else
    #define ipBUFFER_PADDING    ( 8u + ipconfigPACKET_FILLER_SIZE )
#endif

The following code was introduced just to avoid an exception:

    /* Here a pointer was placed to the network descriptor,
      As a pointer is dereferenced, make sure it is well aligned */
    if( ( ( ( uint32_t ) pucBuffer ) & ( sizeof( pucBuffer ) - 1 ) ) == 0 )

We were in doubt about either using the live test or use a configASSERT().
But as pxUDPPayloadBuffer_to_NetworkBuffer may also be called from user space, we decided to have the above test.

As Richard wrote, the “more than 4-byte” alignment is required by some DMA’s.
The extra 2 bytes ipconfigPACKET_FILLER_SIZE were indeed introduced to get a proper 32-byte alignment for all 32-bit fields in the IP- and protocol headers. Many EMAC’s have an option that says: “skip the first 2 bytes” (as you mentioned).

FreeRTOS+TCP is still being developed further: it will soon have the possibility to use IPv6 headers, and also allow for multiple interfaces (EMAC’s). We’re still looking for more users who want to test the new (still experimental) version.

If you want to use IPv6, the extra 4 bytes will also get a purpose: store the IP-type in case of a IPv4 packet.

Regards.