Re: [Qemu-discuss] [BUG or NOT] NICs in up state can not receive any packages if other one NIC is in down state

[Stefan Hajnoczi]

On Thu, Aug 16, 2012 at 01:41:30PM +0800, Rongqing Li wrote:
> HI:
> 
> When qemu has more than two NICs which are connected to Hub,
> just one NIC is in down status, other NICs can not receive
> any packages.
> 
> I see first commit 60c07d933c6 and then 52a3cb869f7 commit made
> it works as the upper description, but I think it is unreasonable
> and buggy, since sometime, we put some NICs to down, and hope the
> remainders are able to work.
> 
> Could you tell us why we design it as the description? or is it
> bug?

Vincent's commit message explains why this logic was introduced:

> commit 60c07d933c66c4b30a83b7ccbc8a0cb3df1b2d0e
> Author: Vincent Palatin <address@hidden>
> Date:   Wed Mar 2 17:25:02 2011 -0500
> 
>     net: fix qemu_can_send_packet logic
> 
>     If any of the clients is not ready to receive (ie it has a can_receive
>     callback and can_receive() returns false), we don't want to start
>     sending, else this client may miss/discard the packet.
> 
>     I got this behaviour with the following setup :
>     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.
> 
>     Signed-off-by: Vincent Palatin <address@hidden>
>     Signed-off-by: Blue Swirl <address@hidden>

The USB network interface can only consume 1 packet at a time - it
relies on the guest querying it for the next packet.  While waiting for
the guest to fetch the packet, the USB network interface cannot receive.

When you put the USB network interface onto a hub together with the dump
net client (which can always receive packets), then packets after the
first get dropped by the USB network interface until the guest has had a
chance to read a packet.

I think the solution is not to drop Vincent/Zhi Yong's code.  Instead we
should distinguish between "up" and "down".  If a net client is "up" but
cannot receive, then the hub will queue the packet.  If a net client is
"down" then the hub will ignore the client and send packets to other
clients.

I don't have patches for this but have added it to my TODO list.

Stefan