[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: |
Thu, 16 Feb 2012 13:51:32 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20120208 Firefox/10.0.1 SeaMonkey/2.7.1 |
Mason wrote:
> (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"
For this error, one can
#define MEMP_NUM_SYS_TIMEOUT 5
in lwipopts.h
Perhaps the default value should be raised?
Or is this the desired outcome?
What about the other questions?
--
Regards.