JM schrieb:
I'm trying to understand all these options in opt.h/lwipopt.h so I can
assign them intelligently instead of guessing and wondering why
communication fails. So, this is what I think is correct; please
correct me if I'm wrong:
In the case of all PBUFs being the same size as defined by
PBUF_POOL_BUFSIZE:
-There is no point in making MEMP_NUM_TCP_SEG > PBUF_POOL_SIZE since
each segment must use one PBUF at minimum, and actually can cause
dropped packets since there will be no space for incoming packets
despite MEMP_NUM_TCP_SEG not hitting its limit.
These two (tcp segments and the pbuf pool) are not really related to
each other: segments are used for outgoing packets only (in conjunction
with RAM- or REF-pbufs), while the pbuf pool is only used for incoming
packets. The only exception for that rule is that segments are also used
for out-of-order segments on the RX side, but that's another issue...
-(TCP_SND_BUF / PBUF_POOL_BUFSIZE) is the effective limit on the
number of outgoing segments in the queue, so TCP_SND_QUEUELEN might as
well be set equal to this limit, at least in the case of very small
outgoing packets that fit into one PBUF.
Totally not: as I already wrote above, the pbuf pool is used for RX
packets only! For each call to tcp_write(), one or more PBUF_RAM pbufs
are enqueued (if copying data; if not copying, PBUF_REF is allocated) in
a segment. Multilpe pbufs are then enqueued for one segment until that
segment reaches the maximum segment size, at which point a new segment
is allocated and pbufs are in turn enqueued to it. Thus TCP_SND_BUF
(number of outgoing unacked bytes) can not berelated to the number of
pbufs used for these bytes.
This allocation strategy is not the optimum we can get, which is why we
started a one-pbuf-per-segment approach, which is, however, not yet
included in CVS or v1.3.1.
Simon
------------------------------------------------------------------------
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users