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

[Douglas]

Looking at the TX side further, there is one common pattern in which the
caller issues linkoutput() then pbuf_free(). It appears that with the
esp8266 sdk only this pattern will work correctly.

Other code appears to assume that after linkoutput() returns that the
caller continues to own the pbuf. For example lowpan6_frag() appears to
allocate a pbuf and reuse the payload buffer after calling linkoutput().
For the esp8266 sdk it would appear necessary to copy the pbuf in this case.

Being new to this code, the semantics of linkoutput() are not easy to
understand.

* Does the caller continue to own the pbuf after the call to linkoutput()?

* Can linkoutput() modify the payload, and perhaps separately define if
it can modify the link layer header area?

* Was the PBUF_TYPE_FLAG_DATA_VOLATILE flag intended to help optimise
any of these patterns on the TX side?

* If in general the caller does continue to own the pbuf, and
linkoutput() is not to modify the payload, then might it worth exploring
another linkoutput() variant that hands the pbuf to the link layer to
optimize that common pattern?

Douglas


On 07/28/2017 01:29 PM, Douglas wrote:
> 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
> 
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel
>