[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] How to lock-up your tap-based VM network
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] How to lock-up your tap-based VM network |
Date: |
Tue, 13 Apr 2010 14:22:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Jamie Lokier wrote:
> Paul Brook wrote:
>>> A major reason for this deadlock could likely be removed by shutting
>>> down the tap (if peered) or dropping packets in user space (in case of
>>> vlan) when a NIC is stopped or otherwise shut down. Currently most (if
>>> not all) NIC models seem to signal both "queue full" and "RX disabled"
>>> via !can_receive().
>> No. A disabled device should return true from can_recieve, then discard the
>> packets in its receive callback. Failure to do so is a bug in the device. It
>> looks like the virtio-net device may be buggy.
>
> I agree - or alternatively signal that there's no point sending it
> packets and they should be dropped without bothering to construct them.
>
> But anyway, this flow control mechanism is buggy - what if instead of
> an interface down, you just have a *slow* guest? That should not push
> back so much that it makes other guests networking with each other
> slow down.
Indeed. So, instead of the current scheme that tries to stop the sender
when some receiver overflows, we must turn it up side down so that this
stop can _never_ happen. We may keep a sufficiently long queue to reduce
the risk of packet drops, but we can't prevent this for all cases anyway.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] How to lock-up your tap-based VM network, Blue Swirl, 2010/04/13