[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Picking appropriate sizes for the different mboxes
From: |
Mason |
Subject: |
Re: [lwip-users] Picking appropriate sizes for the different mboxes |
Date: |
Wed, 15 Feb 2012 13:46:00 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Firefox/10.0 SeaMonkey/2.7 |
(Weird, my client could not thread your message correctly,
because it didn't have a "References" header.)
Simon Goldschmidt wrote:
> Mason wrote:
>
>> The relevant macros are
>>
>> TCPIP_MBOX_SIZE
>
> The number of application tasks communicating with the tcpip_thread +
> the number of input packets queued for receiving.
On my platform, the Ethernet driver manages a queue of incoming
frames (there can be max RX_BUF_COUNT outstanding frames).
Typically, RX_BUF_COUNT is between 100 and 200.
Should TCPIP_MBOX_SIZE have a simple relation to RX_BUF_COUNT?
>> DEFAULT_RAW_RECVMBOX_SIZE
>> DEFAULT_UDP_RECVMBOX_SIZE
>> DEFAULT_TCP_RECVMBOX_SIZE
>
> That depends on your application: the number of RX packets (or
> segments for tcp) queued for a single raw/udp/tcp netconn/socket.
The packets queued in TCPIP_MBOX are subsequently dispatched to
the appropriate {UDP,TCP}_RECVMBOX?
If the RAW API is disabled, DEFAULT_RAW_RECVMBOX_SIZE can be 0, right?
>>> DEFAULT_ACCEPTMBOX_SIZE
>
> That depends on your application, too: the number accepted
> connections queued for a single listening netconn/socket. This
> somewhat interferes with the listen backlog and should probably be >= backlog.
Is there a wiki, or text document covering this material?
>> I have no idea how big or small each one should be. o_O
>> How to make an intelligent decision?
>>
>> I suppose this topic has already been discussed (more than once)
>> on this list? Could someone point me to a previous discussion?
>
> Maybe, but not lately, I think...
I think it would be very useful to have a little README inside doc/
(like sys_arch.txt) explaining the role of these "knobs".
The memory pools is something else that is VERY mysterious to
new users of lwip, and not quite documented. I see there's a
recent thread on this topic, and I will read it closely.
If I define
#define MEM_LIBC_MALLOC 1
#define MEMP_MEM_MALLOC 1
then internal memory pools are disabled, right?
I didn't expect to trigger this error:
src/core/init.c:152:4: error:
#error "MEMP_NUM_SYS_TIMEOUT is too low to accomodate all required timeouts"
--
Regards.