On Fri, Aug 24, 2012 at 8:56 AM, <rongqing...@windriver.com> wrote: > From: Roy.Li <rongqing...@windriver.com> > > The virtual USB NIC originally used a fixed buffer to receive packets which > only store 1 packet at a time, which is easy to overrun with packets if the > guest does not consume it quickly, and always lost packets at the below case: > > The emulated machine is using an USB-ethernet adapter, > it is connected to the network using SLIRP and I'm > dumping the traffic in a .pcap file. As per the following > command line : > -net nic,model=usb,vlan=1 -net user,vlan=1 -net > dump,vlan=1,file=/tmp/pkt.pcap > Every time that two packets are coming in a row from > the host, the usb-net code will receive the first one, > then returns 0 to can_receive call since it has a > 1 packet long queue. But as the dump code is always > ready to receive, qemu_can_send_packet will return > true and the next packet will discard the previous > one in the usb-net code. > > Commit 60c07d933c(net: fix qemu_can_send_packet logic) is trying to fix, > but the logic is wrong and introduce other bug. Now replace the fixed buffer > with a receive queue which can accept a variable number of packets to fix > this bug. > > Signed-off-by: Roy.Li <rongqing...@windriver.com> > --- > hw/usb/dev-network.c | 87 > ++++++++++++++++++++++++++++++++++++-------------- > 1 files changed, 63 insertions(+), 24 deletions(-)
This doesn't really solve the problem, it just makes it less likely we'll hit the bug. What happens if 46 packets are ready? MAX_RCV_QUEUE is 45 so we'll drop packets again. The net subsystem already has queues to hold packets when a peer cannot handle them. We need to use the existing net/queue.c mechanism instead of introducing more queues. I will send out patches later today to fix this. Stefan