Mark Six wrote:
For each incoming ethernet packet, one or more pbuf's are
allocated. The
number of pbuf's available is defined by the PBUF_POOL_SIZE.
If there are no more pbuf's available (e.g. all pbuf's are
allocated) the
incoming ethernet packet is dropped. The TCP/IP stack handles the
incoming
packets and will free them. If the packet is a data-packet, the
application layer is responsible for freeing the packet.
However if the packets come out of sequence, the pbuf is *NOT*
free'd, but
placed on the oos queue. If the out-of-sequence packets are equal
to the
PBUF_POOL_SIZE the lwip-stack is in a deadlock for some time
(until some
timer times out and frees the oos queue).
To limit the number of out-of-sequence packets one could adjust the
receive window size (TCP_WND), however it is possible that one
packet can
have only 1 byte of data, so the value for the receive window can
be no
more than the available pbuf's divided by the maximum number of TCP
connections.
Strictly yes, although in practice you can usually raise it a
little above
that, as statistically you don't always get the worst case!
If you usually expect smaller packets, then you should use a smaller
PBUF_POOL_BUFSIZE, and then fewer will be used, and they will be
chained if
more total space is needed for a larger packet. What's most efficient
depends on your expected traffic pattern.
But if your hypothesis is correct, then turning off TCP_QUEUE_OOSEQ
may be
a good idea. You can't expect to be able to use every nice feature
when you
have limited memory.
This is a problem, because we need a lot of memory or a very small
receive
window.
Indeed.
Any comments on the above are welcome..
It might be nice to have an lwIP option tuning guide at some point
to cover
all this.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos
experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223
245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------
Opinions==mine
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users