Skip to content
Jérémie Magnette edited this page Dec 21, 2015 · 1 revision

The drivers are responsible of creating new frames when new data is received. The easiest way to do this requires a copy of the data from the driver to the stack, and this is done via the pico_stack_recv function. This simplified mechanism allows the driver to use its own buffers autonomously, because it creates a new pico_frame and copies the content of the buffer into it, so that when the function returns, the original buffer can be reused, modified or discarded.

A different approach can be achieved by delivering the buffer to the stack, by voluntarily yielding the ownership of the buffer to the stack, which in turn will free the buffer after it processes it. This is achieved by using pico_stack_recv_zerocopy, and the only requirement is that the buffer created in the driver needs to be allocated using PICO_ZALLOC, because it will be automatically linked as the buffer of a new frame descriptor, that will be eventually discarded by the stack.

A third option allows that the zero-copy operation can instead be performed on an external buffer, e.g. a buffer statically allocated, or allocated in a different memory pool, such as the driver DMA buffers. In this case it might be convenient to perform the zero-copy operation by calling pico_stack_recv_zerocopy_ext_buffer_notify.

In this last case, the function passed as the notify argument will be called instead of PICO_FREE when the last reference frame is discarded, in order for the driver to be able to free or reuse the memory that was originally delivered. The alternative mechanisms for zero-copy driver operations are intended to be used as optimization, to reduce memory usage and the number of buffer copy operations in the stack.

Clone this wiki locally