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

[Jan Kiszka]

On 2012-05-30 23:55, Luigi Rizzo wrote:
> you can take the freebsd image from the netmap page in my link and run it
> in qemu, and then run the pkt-gen program in the image in either
> send or receive mode. But this is overkill, as you have described the
> problem exactly in your post: when the guest reads the packets from
> the emulated device (e1000 in my case, but most of them have the
> problem) it fails to wake up the thread blocked in main_loop_wait().

OK, so there are no QEMU code changes involved? Then, what is your
command line and what is the QEMU version?

> 
> I am unclear on the terminology (what is frontend and what is backend ?)

Frontend is the emulated NIC here, backend the host-side interface, i.e.
slirp ("user"), tap, socket.

> but  it is the guest side that has to wake up the qemu process: the file
> descriptor talking to the host side (tap, socket, bpf ...) has already
> fired its events and the only thing it could do is cause a busy wait
> if it keeps passing a readable file descriptor to select.

Can't follow. How did you analyze your delays?

> 
> I thought your slirp.c patch was also on the same "side" as e1000.c

It was only in the backend, not any frontend driver. It's generally no
business of the frontend driver to kick (virtio has some exceptional path).

BTW, your patch is rather untargeted as it kicks on every MMIO write of
the e1000. Hard to asses what actually makes the difference for you.

Jan

signature.asc
Description: OpenPGP digital signature