[Top][All Lists]

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

Re: [Qemu-devel] Proposed patch: huge RX speedup for hw/e1000.c

From: Luigi Rizzo
Subject: Re: [Qemu-devel] Proposed patch: huge RX speedup for hw/e1000.c
Date: Thu, 31 May 2012 10:23:41 +0200

On Thu, May 31, 2012 at 9:38 AM, Paolo Bonzini <address@hidden> wrote:
Il 31/05/2012 00:53, Luigi Rizzo ha scritto:
> The image contains my fast packet generator "pkt-gen" (a stock
> traffic generator such as netperf etc. is too slow to show the
> problem). pkt-gen can send about 1Mpps in this configuration using
> -net netmap in the backend. The qemu process in this case takes 100%
> CPU. On the receive side, i cannot receive more than 50Kpps, even if i
> flood the bridge with a a huge amount of traffic. The qemu process stays
> at 5% cpu or less.
> Then i read on the docs in main-loop.h which says that one case where
> the qemu_notify_event() is needed is when using
> qemu_set_fd_handler2(), which is exactly what my backend uses
> (similar to tap.c)

The path is a bit involved, but I think Luigi is right.  The docs say
"Remember to call qemu_notify_event whenever the [return value of the
fd_read_poll callback] may change from false to true."  Now net/tap.c has
So as a conservative approximation, you need to fire qemu_notify_event
whenever you write to RDH, RDT, RDLEN and RCTL, or when check_rxov becomes
zero.  In practice, only RDT, RCTL and check_rxov matter.  Luigi, does this
patch work for you?
it almost surely works (cannot check today), as my (guest) driver modifies RDT to notify the
hardware of  read packets. I know/mentioned that the notification can be
optimized and sent only in specific case, as you describe above
(i might be missing the check_rxov).

But i think it would be more robust to make fewer assumptions on
what the guest does, and send the notify on all register writes
(those are relatively rare in a driver, and the datapath touches
exactly the registers we ought to be interested in),
and possibly on those reads that may have side effects, such as interrupt
registers, together with a big comment in the code explaining
why we need to call qemu_notify_event().

Actually, what would pay even more is devise a way to avoid the
write() syscall in qemu_notify_event if the other process (or is it a thread ?)
has data queued.
This is not so important in my netmap driver, but a standard driver is likely to
update the RDT on every single packet, which would pretty much kill

 Prof. Luigi RIZZO, address@hidden  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2211611               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)

reply via email to

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