Mason wrote:
> > 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?
I could imagine setting TCPIP
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_thre
(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 pac
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.
> > DEFAULT_RAW_RECVMBOX_SIZE
> > DEFAULT_UDP_RECVMBOX_SIZE
> > DEFAULT_TCP_RECVMBOX_SIZE
That depends on yo
Mason wrote:
> The documentation for sys_mbox_new states
>
>> Creates an empty mailbox for maximum "size" elements. Elements stored
>> in mailboxes are pointers. You have to define macros "_MBOX_SIZE"
>> in your lwipopts.h, or ignore this parameter in your implementation
>> and use a default size
Hello,
The documentation for sys_mbox_new states
> Creates an empty mailbox for maximum "size" elements. Elements stored
> in mailboxes are pointers. You have to define macros "_MBOX_SIZE"
> in your lwipopts.h, or ignore this parameter in your implementation
> and use a default size.
The relevan
