From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/6] Kill off the virtio_net tx mitigation timer Date: Sun, 09 Nov 2008 13:29:11 +0200 Message-ID: <4916C987.4030802@redhat.com> References: <> <1225389113-28332-1-git-send-email-markmc@redhat.com> <490D7754.4070807@redhat.com> <1225715009.5904.39.camel@blaa> <490EF141.8040005@redhat.com> <1225993515.10879.48.camel@blaa> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Mark McLoughlin Return-path: Received: from mx2.redhat.com ([66.187.237.31]:58488 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753087AbYKIL3O (ORCPT ); Sun, 9 Nov 2008 06:29:14 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mA9BTEDR005555 for ; Sun, 9 Nov 2008 06:29:14 -0500 In-Reply-To: <1225993515.10879.48.camel@blaa> Sender: kvm-owner@vger.kernel.org List-ID: Mark McLoughlin wrote: > The way I see this (continuing with your example figures) playing out > is: > > - If we have a packet rate of <2.5K packets/sec, we essentially have > zero added latency - each packet causes a vmexit and the packet is > dispatched immediately > > - As soon as we go above 2.5k we add, on average, an additional > ~400us delay to each packet > > - This is almost identical to our current scheme with an 800us timer, > except that flushes are typically triggered by a vmexit instead of > the timer expiring > > I don't think this is the effect you're looking for? Am I missing > something? > No. While it's what my description implies, it's not what I want. Let's step back for a bit. What do we want? Let's assume the virtio queue is connected to a real queue. The guest->host scenario is easier, and less important. So: 1. we never want to have a situation where the host queue is empty, but the guest queue has unkicked entries. That will drop us below line rate and add latencies. 2. we want to avoid situations where the host queue is non-empty, and we kick the guest queue. The won't improve latency, and will increase cpu utilization - if the host queue is close to depletion, then we _do_ want the kick, to avoid violating the first requirement (which is more important) Does this seem sane as high-level goals? If so we can think about how to implement it. -- error compiling committee.c: too many arguments to function