Re: [lwip-users] Relationship between lwIP options

[address@hidden]

JM schrieb:
> Now I'm more confused.  I found a post by "bill", which appears to be 
> regarding v1.3 who said:
>
> "What is your TCP_SND_QUEUELEN? If you tie up all of your pbufs to 
> send queued packets, you won't have any pbufs left to support 
> receiving packets."
>
> Is there any truth to this statement (except for the case you mention 
> about out of order segments)?

Even in this case, it's not true, although that depends a bit on the 
netif driver, which allocates the RX pbufs. Normally, the driver should 
allocate PBUF_POOL pbufs for RX, whereas TCP_SND_QUEUELEN gets filled up 
with PBUF_RAM, PBUF_ROM and PBUF_REF. So you might run out of RX pbuf by 
indefinitley queueing too many out-of-order segments (however, there's a 
timeout, too), but not by queueing TX pbufs!

> I wish there was a thorough description of each parameter somewhere.  
> opt.h is fairly good, but there's a few I'm lost on.  Here's the ones 
> I'm unsure about, lets try that:

That's why we started the wiki: anyone who feels the comments aren't 
enough is encouraged to find out more and tell the others about it using 
the wiki... :-)

> TCP_SND_BUF -  Buffer for outgoing segments.  Does this include ACKs?

No, only segments that have to be queued for retransmission (i.e. 
outgoing data).

> How is it divided up between segments?

Every data byte in an outgoing segment increases this by one when 
enqueued and decreases by one if it gets ACKed (removed from the 
retransmission queue).

> Why doesn't the RAM usage change when this is changed?

Because the RAM 'on this counter' either comes from PBUF_RAM pbufs (from 
the heap, size is configured through MEM_SIZE) or PBUF_REF (user memory, 
only referenced by pbufs). Of course it can happen that you run out of 
heap memory or pbuf structures before SND_BUF reaches its limit. 
TCP_SND_BUF is meant as a limiter to prevent one connection from using 
all the memory and prevent other connections from getting memory, too.

>  Where does the memory for this get allocated from?
See above.
> MEM_SIZE - Memory strictly for Tx data when it is copied.  I see that 
> RAM usage does change when this is modified, so this makes sense.

Not only for TX data, this memory is used for all PBUF_RAM allocations 
as well as in some other places, like DHCP, SNMP, etc. (used everywhere 
where you'd use malloc() in your own programs).

> MEMP_NUM_PBUF - The number of pbuf structs for Tx segments that 
> contain data NOT copied (REF or ROM).
Exactly.
>   Does this have anything to do with ACKs?
No. ACKs need memory (ETH-, IP and TCP headers) and cannot be allocated 
by the user (remember REF or ROM is for user-referenced memory), thus 
PBUF_RAM (i.e. the head) is used. Every ACK needs about 70 bytes, I 
think (minimum ethernet frame size 64 + overhead for the pbuf).


> MEMP_NUM_TCP_SEG - Total number of Tx segments in queue, including 
> RAM, ROM, or REF types.

Plus number of Rx segments that are received out-of-order and buffered 
(I think there's a limit to this, too...).

>   Does this have anything to do with ACKs?

Now you got me. I'd have to look into the code for that... (a minute 
later:) No, only a PBUF_RAM is used and directly sent. And even this 
only if there is no outgoing data packet that can be used to piggy-back 
the ACK.

> TCP_SND_QUEUELEN - Number of pbufs for Tx.  Confused by this one.  
> What is the size of the pbufs?

The data in the pbufs doesn't matter (see TCP_SND_BUF for that), this 
one is to limit the number of pbufs blocked by one connection.

>   Where does the memory for these get allocated from?  Is this for all 
> three types, RAM, ROM, REF?
Yes
>   Does this include ACKs?
And no.
> I ask about ACKs a lot because my application doesn't transmit much 
> more than ACKs since it's streaming data.  I still get too many 
> dropped packets, however I see virtually none with default lwIP 
> settings.  The defaults are less than ideal however, especially with 
> the very low MSS.
That's true. Good luck with optimizing the settings ;-)

Simon