From: Avi Kivity <avi@redhat.com>
To: Luigi Rizzo <rizzo@iet.unipi.it>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] interrupt mitigation for e1000
Date: Wed, 25 Jul 2012 11:53:29 +0300 [thread overview]
Message-ID: <500FB409.7010207@redhat.com> (raw)
In-Reply-To: <20120724165835.GB21023@onelab2.iet.unipi.it>
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.
> +
> +#ifdef MITIGATION
> + QEMUBH *int_bh; // interrupt mitigation handler
> + int tx_ics_count; // pending tx int requests
> + int rx_ics_count; // pending rx int requests
> + int int_cause; // int cause
Use uint32_t for int_cause, also a correctly sized type for the packet
counts.
>
> +#ifdef MITIGATION
> + /* we transmit the first few packets, or we do if we are
> + * approaching a full ring. in the latter case, also
> + * send an ics.
> + *
> + */
> +{
> + int len, pending;
> + len = s->mac_reg[TDLEN] / sizeof(desc) ;
> + pending = s->mac_reg[TDT] - s->mac_reg[TDH];
> + if (pending < 0)
> + pending += len;
> + /* ignore requests after the first few ones, as long as
> + * we are not approaching a full ring.
> + * Otherwise, deliver packets to the backend.
> + */
> + if (s->tx_ics_count > 4 && s->tx_ics_count + pending < len - 5)
> + return;
Where do the 4 and 5 come from? Shouldn't they be controlled by the
guest using a device register?
> }
> +#ifdef MITIGATION
> + s->int_cause |= cause; // remember the interrupt cause.
> + s->tx_ics_count += pending;
> + if (s->tx_ics_count >= len - 5) {
> + // if the ring is about to become full, generate an interrupt
Another magic number.
> + set_ics(s, 0, s->int_cause);
> + s->tx_ics_count = 0;
> + s->int_cause = 0;
> + } else { // otherwise just schedule it for later.
> + qemu_bh_schedule_idle(s->int_bh);
> + }
> +}
> +#else /* !MITIGATION */
> set_ics(s, 0, cause);
> +#endif
> }
>
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-07-25 8:53 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 [this message]
2012-07-25 9:56 ` Luigi Rizzo
2012-07-25 10:00 ` Avi Kivity
2012-07-25 10:12 ` Paolo Bonzini
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=500FB409.7010207@redhat.com \
--to=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).