Porting TCP/IP web page misleading

joehinkle wrote on Tuesday, June 21, 2016:

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/FreeRTOS_Plus_TCP/Embedded_Ethernet_Porting.html#creating_a_zero_copy_network_port_layer

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 BufferAllocation_2.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.

rtel wrote on Tuesday, June 21, 2016:

I think the BufferAllocation_1.c and BufferAllocation_2.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.

joehinkle wrote on Tuesday, June 21, 2016:

I’ve gone over the port page multiple times.

I suspect zero-copy/BufferAllocation_1.c came after BufferAllocation_2.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.

rtel wrote on Wednesday, June 22, 2016:

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.