qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Luigi Rizzo <rizzo@iet.unipi.it>
Cc: Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] interrupt mitigation for e1000
Date: Wed, 25 Jul 2012 12:12:55 +0200	[thread overview]
Message-ID: <500FC6A7.9090809@redhat.com> (raw)
In-Reply-To: <20120725095655.GC29334@onelab2.iet.unipi.it>

Il 25/07/2012 11:56, Luigi Rizzo ha scritto:
> On Wed, Jul 25, 2012 at 11:53:29AM +0300, Avi Kivity wrote:
>> On 07/24/2012 07:58 PM, Luigi Rizzo wrote:
>>> I noticed that the various NIC modules in qemu/kvm do not implement
>>> interrupt mitigation, which is very beneficial as it dramatically
>>> reduces exits from the hypervisor.
>>>
>>> As a proof of concept i tried to implement it for the e1000 driver
>>> (patch below), and it brings tx performance from 9 to 56Kpps on
>>> qemu-softmmu, and from ~20 to 140Kpps on qemu-kvm.
>>>
>>> I am going to measure the rx interrupt mitigation in the next couple
>>> of days.
>>>
>>> Is there any interest in having this code in ?
>>
>> Indeed.  But please drop the #ifdef MITIGATIONs.
> 
> Thanks for the comments. The #ifdef block MITIGATION was only temporary to
> point out the differences and run the performance comparisons.
> Similarly, the magic thresholds below will be replaced with
> appropriately commented #defines.
> 
> Note:
> On the real hardware interrupt mitigation is controlled by a total of four
> registers (TIDV, TADV, RIDV, RADV) which control it with a granularity
> of 1024ns , see
> 
> http://www.intel.com/content/dam/doc/manual/pci-pci-x-family-gbe-controllers-software-dev-manual.pdf
> 
> An exact emulation of the feature is hard, because the timer resolution we
> have is much coarser (in the ms range). So i am inclined to use a different
> approach, similar to the one i have implemented, namely:
> - the first few packets (whether 1 or 4 or 5 will be decided on the host)
>   report an interrupt immediately;
> - subsequent interrupts are delayed through qemu_bh_schedule_idle()

qemu_bh_schedule_idle() is really a 10ms timer.

Paolo

  parent reply	other threads:[~2012-07-25 10:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 16:58 [Qemu-devel] interrupt mitigation for e1000 Luigi Rizzo
2012-07-25  7:47 ` Stefan Hajnoczi
2012-07-25  8:53 ` Avi Kivity
2012-07-25  9:56   ` Luigi Rizzo
2012-07-25 10:00     ` Avi Kivity
2012-07-25 10:12     ` Paolo Bonzini [this message]
2012-07-25 10:54       ` Luigi Rizzo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500FC6A7.9090809@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=avi@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rizzo@iet.unipi.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).