lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] LwIP RAW + Zynq - Unresponsive Tx path when Rx is active


From: Nenad Pekez
Subject: [lwip-users] LwIP RAW + Zynq - Unresponsive Tx path when Rx is active
Date: Fri, 10 Aug 2018 14:58:13 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Hello,

I hope to get some advice on how to debug a problem. I am still investigating it and my knowledge on Ethernet drivers and lwIP is still limited.

We have 2 lwIP (2.0.2) RAW servers on a Zynq based board. Each server can serve only 1 client at a time. Over port 4040 server only receives and over 4041 it only sends data. Everything works fine if we don't receive and send simultaneously. Communication over 4041 (Tx port) stalls at some point. We send and receive at data rates of around 1MB/s, but over 1Gb network.

Looking at Wireshark (121 is PC, 124 is Zynq) we see a lot of Dup ACKs before communication stalls. But once it stalls, no traffic is captured at all. For whole minute nothing is captured, until we close our PC app.

Looking at Lwip memory stats on Zynq nothing unusual is observed. What is strange though is that when communication stalls, LINK STAT xmit value is being updated (increased), however TCP STAT xmit is not being updated at all. Therefore, TCP send buffers are not being emptied and we are not able to write anything at all. We call tcp_output when tcp_sndbuf(pcb) < TCP_MSS/2, where TCP_MSS is 1460. We don't use tcp sent callback at all (is that a problem?), just periodically write to tcp sndbuf. Other side of communication is alive all the time without problems.

Any ideas on what this situation with LINK and TCP xmit stats mean? Any ideas on how to debug this problem further?

Thank you very much,
Nenad

  


reply via email to

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