Re: [Qemu-devel] [PATCH 1/2] Usb: create the receive queue for the virtual USB NIC

[Stefan Hajnoczi]

On Fri, Aug 24, 2012 at 8:56 AM,  <address@hidden> wrote:
> From: Roy.Li <address@hidden>
>
> 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 <address@hidden>
> ---
>  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