lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #46289] tcp_write fails with ERR_MEM if TCP_SND_QUEUEL


From: Ambroz Bizjak
Subject: [lwip-devel] [bug #46289] tcp_write fails with ERR_MEM if TCP_SND_QUEUELEN is reached
Date: Sat, 05 Mar 2016 13:56:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Follow-up Comment #11, bug #46289 (project lwip):

Hey,

I was being very careful with the buffer management. From what I can tell,
PBUF_POOL is meant to be used for RX packets (not TX). But I reversed it,
using it for TX in the various places that previously used PBUF_RAM, and for
RX, I use "temporary" pbufs (PBUF_REF) [1]. I am 100% sure this is safe
because they are never queued by the stack (in my the current configuration).
This allows me to pass packets from the RX ring buffer of the MAC driver
directly into the stack.

> The problem is, if your TX and RX path share the same pool, you can reach a
condition where all your buffers are used, most commonly with unACKed TCP data
but you are not able anymore to receive TCP ACK anymore to be able to free
some buffers.

I am fully aware of that. A solution is to configure/correct stuff so that
this can never happen. In my case, PBUF_POOL pbufs will only be used for
"temporaty" pbufs that are created before being send out for transmission. The
netif driver will free them immediately, so all I need is sufficient space in
the pool for the longest possible pbuf. In more complex cases one could rely
on limits such as the max number of pbufs queued for transmission by the
driver, the max number of received pbufs waiting for reassembly...

Note, another change I've done is implemented a new PBUF_TCP type of pbufs
that are used specifically for sending TCP headers. It uses a pool of pbufs
that are specifically sized for this. Of course, I've taken great care to
configure the limits (e.g. TCP_SND_QUEUELEN) so that we never run out of pbufs
in this pool

Generally I really strive for predictability and assurances in the buffer
allocations. It should be possible to configure the stack such that you never
run out of space for anything, and specifically such that one connection
cannot starve other connections of memory.

[1]
https://github.com/ambrop72/aprinter/blob/web-interface/aprinter/net/LwipNetwork.h#L1241

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?46289>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

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