[lwip-devel] Q. PBUF_NEEDS_COPY relevant for input pbufs?

[Douglas]

Could use some help understanding PBUF_TYPE_FLAG_DATA_VOLATILE and
PBUF_NEEDS_COPY usage for the esp-open-rtos rtos.

The guts of the ESP wifi code is a binary blob supplied from a SDK which
interfaces to hardware RX and TX queues, and provides a small pool of RX
frames and it expects these to be returned to the RX pool.

With the limited RX frame pool, it is important to return these quickly.
These include a link header, but the hardware does not seem to touch
this after a frame is received, not until it is recycled and put back in
the HW queue.

So a question is: should these RX pbufs be flagged as
PBUF_TYPE_FLAG_DATA_VOLATILE, so that they are copied if the data is to
be kept around for long?

Looking at the code it appears that PBUF_TYPE_FLAG_DATA_VOLATILE and
PBUF_NEEDS_COPY are only used in the TX paths, but might there be some
data flow paths that are relevant to RX pbufs?


On the TX side, regular pbufs are allocated and the payload is allocated
from the OS heap. When these are passed to the binary library it calls
back to pbuf_ref() before returning, and later calls pbuf_free() when
finished with the pbuf. During this period it is expected to be
modifying the data as it includes a link header with information that is
expected to change.

So another question is: does that pattern of TX pbuf use require
PBUF_TYPE_FLAG_DATA_VOLATILE or is the reference alone enough to prevent
it being re-used?

Douglas