Re: [lwip-users] How to avoid lwIP v2.1.2 udp send stuck when data is coming in faster than it is going out

[Sergey A. Borshch]

Sorry for format mess in my previous message.

On 9/16/22 14:04, Lan Yang wrote:

Hi Сергей Борщ,

Your answer helped me!

There are still some points that are still unclear. 

First point, when to pause the case for some time to let LwIP send out some data,
and when to continue the case after the pause succeeds?

I think it should be done here:

  } else {
    rt_kprintf("udp_client_send p == NULL\r\n");

    os_pause(100 ms);  // I don't know your OS syntax

  }

This piece of code wrapped by mutex, so second thread will be paused too

Second point, I just send UDP data by calling the function udp_send(), 

and I thought the LwIP would drop the extra data inside itself.

No, udp_send() call does not happens in this case. pbuf_alloc() failed because LwIP does not have free buffer to keep your new data.

But the test result is when data coming in to the LwIP is faster than LwIP send them out,
LwIP will be stuck. It just seems that the LwIP won't drop the extra data.

I missed "stuck" in your first letter, just saw "p != NULL", sorry. Is it possible that stuck happens inside rt_kprintf() due some inter-process deadlock? Try lid some LED instead of rt_printf() here to be sure it not the case.

Another possibility is that LwIP thread has lower priority than udp_client_send() thread and just didn't get any cpu time to send data away in this (p == NULL) case. i don't know your software details so it's just a guess.

So I need to drop the extra data on the application layer, but the question is how can I know which data is the extra data?

I think the simplest way is just remove

  } else {
    rt_kprintf("udp_client_send p == NULL\r\n");

You have no ability to send data that time because of no free pbuf ready, so you didn't fill pbuf and didn't call udp_send() at all but just falling through and releasing mutex. I think so but I can be wrong.

--

С уважением,
 Сергей Борщ
  SB ELDI SIA