lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] TCPIP thread stack size


From: Simon Goldschmidt
Subject: Re: [lwip-users] TCPIP thread stack size
Date: Sat, 30 Mar 2024 18:05:42 +0100
User-agent: Mozilla Thunderbird



On 28.03.2024 02:55, James Aguilar wrote:
Friends,

I have been playing with lwip, trying to get some various things working
on my Raspberry Pi Pico W. First off, thanks very much for putting this
library together.

One of the interesting things I noticed when I was getting my project to
announce itself on mdns was that the stack usage of the TCPIP thread
seems pretty high! According to FreeRTOS, the stack high water mark of
the TCP/IP thread is around 3500 words -- 14kB. I have questions:

- Is this a typical amount of TCP/IP thread stack usage? Do I have to
worry about it going much higher? This is in debug compilation mode.

I guess this is typical for mdns. However, this is at least partly a
known issue in the mdns code, which allocates too much on the stack
(where it should rather do static-, pool- or heap-allocations).

- Are there good defaults for this (and other) settings within the
lwipopts.h file?

No, such defaults greatly depend on your platform and your usage of the
stack, it doesn't make much sense for us to provide generic default options.

- Is there a good list anywhere of other "dangerous" (i.e. silently
corrupt your memory if set wrong) options?

Non that I know of, but there should be no silent memory corruption
other than stack overflow - and I strongly suggest to implement a
runtime check against stack overflow: things can always go wrong!


Any other tips for a newb? One thing I also can't seem to find much good
information on is the pros and cons of using the raw APIs, netconn, or
socket. I noticed that the apps seem to use netconn so that's what I'm
starting with.

No, most apps should be using the raw API. Apps using netconn are not
seen too often. The raw API is the smallest and has best performance, at
the cost of requiring the user to think of programs much like a state
machine (in contrast to multithreading used for netconn or sockets).

Regards,
Simon



reply via email to

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