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 192.168.1.109; done;' from a local machine (thus 192.168.1.109 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?
Regards,
-Bastiaan