Re: [lwip-users] Relationship between lwIP options

[address@hidden]

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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users