LWIPERF_TCP_ABORTED_LOCAL, or lingering pbufs

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

LWIPERF_TCP_ABORTED_LOCAL, or lingering pbufs

Bastiaan van Kesteren-2
Hi all,

First off, thanks for the work on lwIP, I use it both for hobby and work. Much appreciated.

In the hobby-setting I'm playing around with the latest release, finally taking the time to upgrade from my old and trusted 1.4.1 setup. Since I had to redo my network interface code, I also took the time for a zero-copy rx setup; I have declared a memory-pool ('RX_POOL') which has room for 8 full size (1536 bytes) pbufs; four are in use by the network DMA, the rest is used to pass pbufs on to the stack.

Seems to work OK sofar. As a stress-test I'm using the included lwiperf app, running 'while [ true ]; do iperf -c; done;' from a local machine (thus is my lwip-board).

Eventually this will fill up my RX_POOL. When this happens I dump the received frame and give it back to the network DMA.

This sort-of breaks when lwiperf aborts with LWIPERF_TCP_ABORTED_LOCAL from lwiperf_tcp_poll(); when this happens there are pbufs left in the RX_POOL, which are no longer processed, so i keep dumping incoming frames because there are no more free pbufs in RX_POOL. Eventually (after about 30 minutes?) tcp_slowtmr cleans this up (or so i think, with "max DATA retries reached") and things start moving again.

So to get to the point; this is where my lwIP (or iperf, or TCP in general) knowledge falls short... My questions: what's happening here (why are these pbuf's not processed?), is this a bug in my network-setup or a by-design thing? Maybe a side-effect of having effectively only 4 pbufs for incoming data? Or is this a limitation of the lwiperf app?


lwip-users mailing list
[hidden email]