+TCP example for transfer bigger than MTU


Does anyone know of any examples that show how to receive data that is larger than the MTU but is part of the same transaction? I am trying to transfer 2k of data to the Zynq module and am receiving it using FreeRTOS_recv. However, I am seeing that as 2 separate packets of data. I would like the firmware to collect the entire 2k packet before doing the processing. I could not find any examples of this.

Thank you,

Hi Sid,

ba definition, you can not do that. The 1640 bytes are the maximum that the controller is able to process. Some MCUs allow to chain DMA buffers, but still that does not mean that you would always receive every packet in full. The entire purpose of TCP is to negotiate bottlenecks and make sure that streams are received as they are sent, but what is in between is up to many restrictions.

Hello Sid, at first your post made me think of jumbo frames.

I think that the Ethernet peripheral of the Zynq supports jumbo frames, and I assume that your host can also be configured to support larger segments, also for TCP. Hopefully the LAN ( routers, switches ) will also recognise and support them.

In principle, FreeRTOS+TCP should also support them, it only means that MTU will increase.

But I think that jumbo frames would only give a very small performance gain.

I think that @RAc has a typo in his message: 1640 should be 1460. The normal maximum MTU is 1500 bytes. Minus the 40 bytes for IP/TCP headers, there are 1460 bytes left for the TCP payload.

And so: your data will be split up before sending, and concatenated when receiving. There is nothing wrong with that.

You can either go two ways:

  1. You call recv() twice, and make sure the received data ends up in a single memory block.
  2. You let the data in the driver until the full 2 KB is available.

If you are interested in method 2, you could look at either ipconfigSOCKET_HAS_USER_WAKE_CALLBACK or ipconfigSOCKET_HAS_USER_SEMAPHORE.

But personally, I’d go for the simpler method 1.

you are right, thanks for pointing that out!