Re: [lwip-users] pbuf pool size / mss size in low memory environment and routing to slow link

[Mike Kleshov]

> - Why can't the pool pbuf size less then the MSS, if the documentation says
> the pbuf can be chained together?

Here is a part of my lwipopts.h:

#define PBUF_POOL_SIZE          48
#define PBUF_POOL_BUFSIZE       96
...
#define TCP_MSS                 512

And it works.

> - Will i be still able to send / receive a (i.e.) 1000 bytes UDP datagram
> with my 256bytes pbufs?

There is UDP in my setup. It works too. I definitely have packets
spanning multiple pbufs.

> - What will be the ideal pbuf size according to MSS size. Shall it be the
> same, or must the pbuf be the MSS+40 bytes (to hold the segment and the
> header)?

It's a trade-off between memory efficiency and performance. With small
pbufs, you don't waste much memory on small packets, but you loose
some speed due to packet splitting. But the performance loss would
depend heavily on the application and optimizations used. There is
also the memory overhead of the pbuf header.
You probably want your pbufs to be at least large enough to hold an
ARP packet. There should be plenty of those in a LAN.

> When my webserver i.e. sends a 4kbyte-page over the radio link, where will
> all the TCP segments be stored until they have been acknowledged? As these
> are dynamically generated data (sent with "COPY" option), this should be
> happen in the pool pbufs, right?

In lwip, memory is allocated either from a pbuf pool or from heap. If
I remember correctly, in a standards setup memory for incoming packets
is allocated by the network interface driver from a pbuf pool. All
other allocations are done from heap. It is possible to configure lwip
to use pbuf pools everywhere and not use heap at all.

> And at least, will be a memory size (heap size) for LWIP of 8192 bytes be OK
> in that case? I really have not to waste memory and get the best compromise
> for memory usage and performance.

8 Kbytes would probably be OK for fast links. But with a slow link,
you'll want more unacked data to be 'in-flight' for reasonable
performance. Besides, you shouldn't think that heap size is the most
important tuning parameter. Yes, performance will suffer if there is
not enough heap. But heap can be wasted in the wrong places, so it is
important to tune other parameters to match your workload.