[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Freeing just part of a pbuf chain?
From: |
Kieran Mansley |
Subject: |
Re: [lwip-users] Freeing just part of a pbuf chain? |
Date: |
Mon, 21 Nov 2011 19:44:29 +0000 |
On 21 Nov 2011, at 15:45, Brian McFarland wrote:
> So say my tcp_recv() callback gives me three pbufs chained: A->B->C. If I
> need to save some of the data for later, what’s the intended mechanism for
> freeing A but not B->C? Seems like could be accomplished either by
> pbuf_ref(B) and then pbuf_free(A) --OR-- pbuf_dechain(A) followed by
> pbuf_free(A). Is that correct? Is either method *more* correct (i.e. always
> better), do both methods have their own advantages?
I'd have to look at the source to be sure, but I would probably go for the
dechain method.
> On a related note, if I don’t want to tcp_recv() any more data until
> processing the data in B->C, can I just postpone calling tcp_recved()?
No. That will eventually result in no more data being passed to your callback
as it will prevent the sender from transmitting more, but not on a timescale
that you are hoping for. tcp_recved() allows lwIP to re-advertise the memory
to the sender so it can transmit more packets, but if there were others already
in flight or internal to the stack they will carry on being delivered. There
isn't an easy way with the raw API to stop the stack like that. It is this
sort of feature that the higher layer APIs provide (together with the
associated overhead).
Kieran