[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Relationship between lwIP options

From: address@hidden
Subject: Re: [lwip-users] Relationship between lwIP options
Date: Tue, 04 Aug 2009 16:14:37 +0200
User-agent: Thunderbird (Macintosh/20090605)

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).

  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?

  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 ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]