rtel wrote on Friday, November 21, 2014:
FreeRTOS+TCP is designed from the ground up to have a standard and familiar interface - Berkeley sockets - and be thread safe. This is intended to make it as easy to use as possible. There are actually other interfaces which are faster than the Berkeley sockets interface (what we refer to as ‘expert’ interfaces), but these are not documented yet because we don’t want to confuse people or overwhelm them with information. They will be documented in time, and we have a few add-on components (also not released yet) which use the expert interfaces which will serve as a reference.
With regards to zero copy:
-
UDP packets can be zero copy end to end if the MAC driver itself supports zero copy. That is you can fill a buffer in the application, send that buffer to the TCP/IP stack using the sockets interface (there is a special socket option on the sendto() function to say its a zero copy), have the buffer passed through the stack, and sent to the driver. The driver can then make one of its DMA descriptors point to the buffer for transmission - nothing is copied anywhere.
-
With TCP it is not so easy because TCP packets form streams. You could send three small TCP packets to a socket, and internally the TCP stack would add the three packets into a single Ethernet frame to minimise calls to the driver and minimise packets on the network. There is a way of zero copying TCP packets too, but likewise this is not documented yet as it is more complex than the UDP case because you end up with pointers to data that is within a stream - which means the user and the writer of the driver need to take great care.
FreeRTOS+TCP keeps buffer management in the portable layer, so you choose the implementation you want:
-
The simplest but least deterministic implementation is not to allocate any memory at all, and the stack will allocate and free memory from the FreeRTOS heap when it needs it. This is of course also the slower and least deterministic implementation, but great for simplicity and resource constrained systems. If you want to send a packet but there is not enough heap then the socket will block (assuming it is a blocking socket) until it can obtain the memory (or timeout as the case may be). To use this method you need to be using heap_4.c or heap_5.c as those two implementations guard against memory fragmentation.
-
The fastest implementation allocates the buffers up front. Fast and deterministic, but potentially consumes more memory, especially when only a subset of the buffers are in use at any one time.
Which chip do you want to port it to? It might be we have something you could start with.
Regards.