Re: [lwip-users] PBUF starvation

[address@hidden]

I don't really get which function you are talking about, but if the 
input mbox is full (thus a received pbuf cannot be passed from the 
driver to lwIP), of course it has to be freed by someone. Normally, the 
function passing the pbuf to the mbox would return an error that would 
allow the driver freeing the pbuf.

This situation (receive-mbox too full) is perfectly normal for systems 
that cannot handle packets at wire-speed.

Simon



Alexandre Malo wrote:
> Hi,
>  
>   I am having PBUF starvation. After a time, some PBUF isnt freed and 
> will never be. I believe, after debuging and adding trace to the pbuf 
> file that it is cause by the TCP_INPUT function. I'm using TCPIP thread.
>  
> Im keeping a list of allocated pbuf pointer with a time of allocation.
>  
> With this list I found that many PBUF were not freed and remain 
> allocated. All the threads are running correctly.
>  
> I think the problem is located in TCP_INPUT. When the mbox of TCP 
> thread is full, the pbuf isn't freed.  Should the PBUF be freed there 
> or should it be my FEC port that free the pbuf?
>  
>  
>   struct tcpip_msg *msg;
>  
>   if (mbox != SYS_MBOX_NULL) {
>     msg = memp_malloc(MEMP_TCPIP_MSG_API);
>     if (msg == NULL) {
>       return ERR_MEM;
>     }
>  
>     msg->type = TCPIP_MSG_CALLBACK;
>     msg->msg.cb.f = f;
>     msg->msg.cb.ctx = ctx;
>     if (block) {
>       sys_mbox_post(mbox, msg);
>     } else {
>       if (sys_mbox_trypost(mbox, msg) != ERR_OK) {
>         // FREE THE PBUF HERE??? //
>         memp_free(MEMP_TCPIP_MSG_API, msg);
>         return ERR_MEM;
>       }
>     }
>     return ERR_OK;
>   }
>   return ERR_VAL;
>  
>  
> Thanks!
> ------------------------------------------------------------------------
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users