Network Driver length

jeronimo479 wrote on Friday, March 09, 2018:

On the webpage [(http://https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/Embedded_Ethernet_Porting.html#creating_a_simple_network_interface_port_layer)]

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?

rtel wrote on Friday, March 09, 2018:

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.

jeronimo479 wrote on Friday, March 09, 2018:

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.

heinbali01 wrote on Saturday, March 10, 2018:

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?