On 08/20/2010 04:01 AM, Karthik Vadambacheri Manian wrote:
Hi All, I am running a light weight kernel named kitten in QEMU-KVM which uses LWIP (Light Weight TCP/IP) stack for networking. I am trying to fine tune this LWIP but I am now facing an issue regarding delayed packet reception. Basically I wrote a small pingpong program where master sends a data to a slave and slave returns it back. But I see some retransmissions due to missing acknowledgement. When I debugged further I came to know the following: 1) Master sends some data to Slave 2) Slave receives it and sends an acknowledgement to Master. Slave then returns the same data to Master 3) Master receives both acknowledgement and the data The problem occurs in the 3 step. The master receives a single interrupt for both the acknowledgement packet and data packet. So the driver tries to read and reads the acknowledgement packet first and then checks again whether there is more data in the buffer and it reads the data packet. But sometimes the data packet is available in the buffer after 90-100 microseconds after acknowledgement packet, hence the driver thinks there is no more packet to receive. So the receive is failed. This causes the slave to resend the packet which leads to great performance loss. And from the debug messages it is sure that there is no delay from the slave side in sending the data packet. When I run the same program in QEMU everything is running perfectly. I think it is because the emulation itself causes a long delay within which the packet arrives at the buffer and hence the scenario is not reproduced. Hence I would like to know whether KVM has issues with the RTL8139 card? and how to proceed further.
There may be a missing wakeup in the networking path. You can try adding printf()s in RTL8139's receive function, and in kvm_set_irq_level() to see if there's a problem in interrupt flow.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
