[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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]