On the webpage [(http://https://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusTCP/EmbeddedEthernetPorting.html#creatingasimplenetworkinterfaceportlayer)] The porting instructions for moving a packet from the MAC receive bufer and pushing it onto the IP stack shows: ~~~ … if( xBytesReceived > 0 ){ pxBufferDescriptor = pxGetNetworkBufferWithDescriptor( xBytesReceived, 0 ); if( pxBufferDescriptor != NULL ){
ReceiveData( pxBufferDescriptor->pucEthernetBuffer ); pxBufferDescriptor->xDataLength = xBytesReceived; …
~~~ I don’t understand why I would include “pxBufferDescriptor->xDataLength = xBytesReceived;”. When I call pxGetNetworkBufferWithDescriptor(), it allocates memory and writes the actual packet length. If I set it myself after calling pxGetNetworkBufferWithDescriptor(), it migth not be right. Thoughts?

I see what you mean. Have you ever seen the first and second setting of ->xDataLength being different? In the code you past ReceiveData() is use the length of the allocated buffer, which may not be the same as xBytesReceived (it should always be equal to or greater than xBytesReceived, never smaller). ->xDataLength might then be set to xBytesReceived so the TCP stack knows how many bytes within the allocated buffer actually contain data.

The comments in the BufferAllocation_2.c code that supports pxGetNetworkBufferWithDescriptor(), show that in some outgoing packets, it accounts for ICMP packets getting replaced by ARP requests, and therefore, the packet minimum sisze is adjusted. But for incoming packets, I can’t see any reason for this, and I’m new to +TCP so I don’t have enough experience.

The comments in the BufferAllocation_2.c code that supports pxGetNetworkBufferWithDescriptor(), show that in some outgoing packets, it accounts for ICMP packets getting replaced by ARP requests, and therefore, the packet minimum size is adjusted.

ARP packets are the smallest packets with 42 bytes. So changing an ICMP into an ARP packet is OK, it is getting smaller. Only when an Ethernet buffer grows, it must be re-allocated (when using BufferAllocation_2.c).

But for incoming packets, I can’t see any reason for this, and I’m new to +TCP so I don’t have enough experience.

If ipconfigFTP_RX_ZERO_COPY is non-zero: incoming packets are received in Ethernet buffers that have a maximum size of about MTU + 14. When the Network Interface uses memcpy(), it has big DMA buffers, and for the Ethernet buffers, it allocates just enough bytes to hold a packet. Still, baMINIMAL_BUFFER_SIZE is always respected as a minimum size. Does this answer your question?