[Top][All Lists]

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

Re: [Qemu-discuss] [BUG or NOT] NICs in up state can not receive any pac

From: Jakob Bohm
Subject: Re: [Qemu-discuss] [BUG or NOT] NICs in up state can not receive any packages if other one NIC is in down state
Date: Thu, 16 Aug 2012 16:21:00 +0200
User-agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 8/16/2012 2:57 PM, Stefan Hajnoczi wrote:
On Thu, Aug 16, 2012 at 01:41:30PM +0800, Rongqing Li wrote:

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
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
     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

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


More fundamentally, you should try to match what real "switching hubs"
a.k.a. switches do:

Maintain a separate queue for delivery to each (virtual) NIC and discard
packets for that NIC when its queue becomes full.

Vincent's code "solves" a bug in one of the virtual NIC implementations
(the USB NIC emulator) by forcing all other NICs to fail too, which is a
truly insane way to code.


Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

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