lwip-users
[Top][All Lists]
Advanced

[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.



reply via email to

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