I'm writing a NIC driver for the Kinetis K64 to be used in your stack.

I'm being picky here as I'm finding misleading/confusing information.

On the web page: http://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusTCP/EmbeddedEthernetPorting.html#creatingazerocopynetworkportlayer

in the section: Functions Provided by the TCP/IP Stack For Use By The Port Layer

the following is stated:

pucGetNetworkBuffer() - Obtains just a network buffer, without a network buffer descriptor. This function is normally only used in zero copy interfaces to allocate buffers to DMA descriptors.

I don't believe that is a true statement as the function pucGetNetworkBuffer() is defined in BufferAllocation2.c not "1.c" which is associated with zero copy AND the function call malloc to allocate a buffer ... which again is not zero-copy related.

I suggest rewording the paragraph and state:

Obtains just a network buffer, without a network buffer descriptor. This function is NOT used in zero copy interfaces to allocate buffers to DMA descriptors.

I think the BufferAllocation1.c and BufferAllocation2.c have just evolved at different times. Why can BufferAllocation_2.c not be used in a zero copy driver? Perhaps it would be better to ensure both allocation schemes provide the same interface to the stack and the same functionality as each other - in which case we probably need to add some code in.

I've gone over the port page multiple times.

I suspect zero-copy/BufferAllocation1.c came after BufferAllocation2.c.

Calls by the same function take different type arguments and your implementation example has several bugs which I suspect is do to zero-copy maturing over time but the implementation example forgotten.

I propose a much cleaner zero-copy transmit process than what your describe (switching ethernet buffers pointers, etc -- as the ethernet buffer is directly tied to its network buffer with the network buffer address embeded at the start of the ethernet buffer.

The example says to return the buffer with the buffer's pointer to the ethernet buffer being nulled out and then returning the ethernet buffer after the transmit is completed. I've looked at the stack functions that are suggested to be called and none of them do any conditional work if the ethernet buffer is null or not.

I suggest NOT performing any action on the buffer until after the transmit is completed. In the interupt, obtain the DMA address and acquie the pointer to the Network buffer position at the front of the ethernet buffer. Then just return buffer and descriptor in ISR ... no swapping and all the other mess explained in your example goes away.

Just my opinion.

Hi Joe - thanks for your feedback. I think the differences between the the _1.c and _2.c implementations comes mainly from the fact that focus goes from one to the other over time, so they are not necessarily in step with each other. Your posts have raised some good points so I will try and clean this up, and update the documentation accordingly.