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
performance.
cheers
luigi