lwip-users
[Top][All Lists]
Advanced

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

RE: [lwip-users] Sizes


From: Bill Auerbach
Subject: RE: [lwip-users] Sizes
Date: Wed, 27 May 2009 16:44:40 -0400

The biggest bang for my buck was to use assembly code for the inet_checksum and 
a hybrid inline/assembly code memcpy for all memcpy's used.  If your hardware 
does DMA memory-to-memory copies definitely use it for memcpy.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of John Kennedy
>Sent: Wednesday, May 27, 2009 4:12 PM
>To: Mailing list for lwIP users
>Subject: RE: [lwip-users] Sizes
>
>Jeff,
>Thanks for the info.  As it turns out there is more info about this
>issue in the archives, but it takes a little searching to dig it out.  I
>searched on TCP_MSS and got quite a bit of stuff... still looking.  Like
>you I came up with an TCP_MSS of 1460, a MEM_SIZE of 0x10000,
>TCP_SND_BUFF of 8 * TCP_MSS. But I set my TCP_SEND_QUEUELEN to 32 and my
>TCP_WND to 16384.  I learned from the archive that TCP_WND affects the
>TCP receive throughput.
>
>The archives also seem to indicate that a certain amount of port
>specific tuning for TCP is necessary.  So it would be helpful if someone
>could suggest some standard LWIP test scenarios along with some
>guidelines of what to tweak to determine the best configuration for
>one's particular needs.  Otherwise it's a lot of trial and error.
>
>So far Lwip has worked well for me (no bugs or problems except those of
>my own making) but I'm still fooling around with the configuration to
>maximize performance, and like you my port is very young.
>
>John
>
>
>
>________________________________________
>John Kennedy
>
>
>Idaho Technology Inc.
>390 Wakara Way
>Salt Lake City, UT 84108, USA
>
>USA: 1-800-735-6544
>Bus:+1 (801)736-6354 x448
>Fax:+1 (801)588-0507
>
>http://www.idahotech.com/
>-----Original Message-----
>From: Jeff Barber [mailto:address@hidden
>Sent: Wednesday, May 27, 2009 1:39 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] Sizes
>
>On Wed, May 27, 2009 at 9:47 AM, John Kennedy
><address@hidden> wrote:
>> I'm using Lwip with sockets on MicroBlaze.  I have an MTU of 1500.  I
>want
>> to maximize the Ethernet TX/RX data rates (bits/sec) in my embedded
>system.
>> Memory is not an issue (512Mbytes avail).
>>
>> How does one determine the values for:
>>
>> *         MEM_SIZE
>>
>> *         PBUF_POOL_SIZE
>>
>> *         PBUF_POOL_BUFSIZE
>>
>> *         TCP_MSS
>>
>> *         TCP_SND_BUF
>>
>> *         TCP_SND_QUEUELEN
>>
>>  to maximize the Ethernet TX/RX data rates?
>
>I wish there were a better source of information on this as well.  I
>spent quite a while trolling through the source trying to understand
>what all the different settings are for.  Some I figured out, others
>I'm still not sure of.
>
>Like you, my environment is not memory-constrained.  Furthermore, I am
>using my own malloc implementation rather than the lwip built-in
>mem_malloc and memp_malloc (this is partially because I trust my own
>allocation functions and partially because I had a hard time
>understanding how to configure the lwIP implementation :-).  As best I
>can tell, when using one's own allocation routines, several of the
>memory-related defines are "don't care".  So MEM_SIZE and all the
>MEMP_* and PBUF_POOL_SIZE are (I think) not actually used -- beyond
>the sanity tests in lwip/src/core/init.c.
>
>Caveat: my port is very young -- my driver came up for the first time
>a couple of days ago, and it hasn't yet done much more than answer
>ping packets and ARP (no TCP yet).  FWIW, though, here's my lwipopts.h
>(for everything else, I accept the default values from <lwip/opt.h>):
>
>#define NO_SYS                      1
>#define MEM_LIBC_MALLOC             1
>#define MEMP_MEM_MALLOC             1
>#define MEM_ALIGNMENT               4
>#define MEM_SIZE                    (4 * 1024 * 1024)
>#define MEMP_NUM_PBUF               1024
>#define MEMP_NUM_UDP_PCB            20
>#define MEMP_NUM_TCP_PCB            20
>#define MEMP_NUM_TCP_PCB_LISTEN     16
>#define MEMP_NUM_TCP_SEG            128
>#define MEMP_NUM_REASSDATA          32
>#define MEMP_NUM_ARP_QUEUE          10
>#define PBUF_POOL_SIZE              512
>#define LWIP_ARP                    1
>#define IP_REASS_MAX_PBUFS          64
>#define IP_FRAG_USES_STATIC_BUF     0
>#define IP_DEFAULT_TTL              255
>#define IP_SOF_BROADCAST            1
>#define IP_SOF_BROADCAST_RECV       1
>#define LWIP_ICMP                   1
>#define LWIP_BROADCAST_PING         1
>#define LWIP_MULTICAST_PING         1
>#define LWIP_RAW                    0
>#define TCP_WND                     (4 * TCP_MSS)
>#define TCP_MSS                     1460
>#define TCP_SND_BUF                 (8 * TCP_MSS)
>#define TCP_LISTEN_BACKLOG          1
>#define LWIP_NETIF_STATUS_CALLBACK  1
>#define LWIP_NETIF_LINK_CALLBACK    1
>#define LWIP_NETIF_HWADDRHINT       1
>#define LWIP_NETCONN                0
>#define LWIP_SOCKET                 0
>#define LWIP_STATS_DISPLAY          1
>#define ETHARP_TRUST_IP_MAC         0
>
>#define mem_init()
>#define mem_free                    my_free
>#define mem_malloc                  my_malloc
>#define mem_calloc(c, n)            my_zalloc((c) * (n))
>#define mem_realloc                 my_realloc
>
>
>For the MSS value, specifically, I worked backwards from the standard
>max ethernet frame size: 1514.  Subtract 14 bytes for layer 2 header;
>subtract 20 bytes for IP header and another 20 for TCP header; that
>leaves 1460.  There are a couple of ports in contrib/ that define it
>to 1476 but I couldn't figure out how they came up with that.  I will
>have a direct ethernet connection to my peer so don't need to worry
>about any additional fragmentation.
>
>BTW, any comments on my settings would be greatly appreciated.
>
>Hope this helps.
>Jeff
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>________________________________________
>CONFIDENTIALITY NOTICE: This E-mail and any attachments are confidential
>information of the sender and are for the exclusive use of the intended
>recipient. If you are not the intended recipient, be aware that any
>disclosure, copying, distribution, or use of this E-mail or any
>attachment is prohibited. If you have received this E-mail in error,
>please notify us immediately by returning it to the sender and delete
>this copy from your system. Thank you for your cooperation.
>
>
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users





reply via email to

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