lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] pbuf_alloc failed after sometime at driver side.


From: Sergio R. Caprile
Subject: Re: [lwip-users] pbuf_alloc failed after sometime at driver side.
Date: Tue, 14 Oct 2014 23:38:05 -0300
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

> Isn't the stack responsible for freeing PBUFs?

No Grzegorz, the stack isn't more responsible than you are.

The Ethernet driver usually allocates the pbufs when signalled by the
Ethernet controller. This code does not belong to lwIP but to the driver
developer. It is responsible for freeing non-IP frames.
Code for this is in the netif tree and is modified by the one providing
the driver and the port. It usually follows src/netif/ethernetif.c and
usually uses etharp.c, but the only one who actually knows that is you,
the user (and others running the same driver...), so if you are using
vendor code, you should check with your vendor, they do like to do
things at will.

> And now upper laye stack have resposibilty to free this packat after
> it no longer in use.

No jbhoi, the upper layer is ultimately layer-5to7 and ergo your
responsibility, unless we are talking about pings/arp..., or you are
using a known to work application, which I don't know because you don't say.

> [...] will pass it io next phase like ip_input and from that it call
> tcp_input or udp_input or other and it will free that packet.

Nope, it will just ultimately call the application callback function and
it (YOU) will free the pbuf. TCP will only free the pbuf when INSTRUCTED
TO DO SO, by returning a specific value in your callback function. UDP
will not free it.


You guys should by all means try a known to work application to rule out
any problem in your driver and/or port. I first thought of the driver
because the problem description looked like non-IP frames pbufs were not
being freed. Now, since you actually don't know you have to free pbufs,
I'm beginning to think that you actually have a non-working application.
Anyway, there are many network conditions that may cause different pbuf
allocation and that might fail in different ways. Please read the docs.

Take a time to read the wiki
http://lwip.wikia.com/wiki/Raw/native_API

Check that you are following the multithreading requirements (just one
thread and only one will talk to lwIP (pbuf functions are supposed to be
a bit more permissive but I don't run RTOSes so I can't tell you how to
do anything other than keep everything on the same context).

http://lwip.wikia.com/wiki/Raw/TCP
http://lwip.wikia.com/wiki/Raw/UDP
Then take a time to check the tcpecho_raw application for TCP or the
sntp application for UDP; in the contrib tree
Follow those guidelines in your application.

Regarding specifics for pbuf freeing; from the wiki:

UDP:
        
        "The callback function is responsible for deallocating the pbuf"

TCP:
        "If there are no errors and the callback function returns
        ERR_OK, then it is responsible for freeing the pbuf. Otherwise,
        it must not free the pbuf so that lwIP core code can store it"

Let's make a deal: If something is wrong in the wiki, I will fix it. If
something is wrong in your code, you will fix it.




reply via email to

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