[Top][All Lists]

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

Re: [lwip-users] PBUF starvation

From: address@hidden
Subject: Re: [lwip-users] PBUF starvation
Date: Tue, 28 Jul 2009 22:02:00 +0200
User-agent: Thunderbird (Macintosh/20090605)

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.


Alexandre Malo wrote:
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->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;

lwip-users mailing list

reply via email to

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