> On Wed, May 30, 2012 at 10:23:11PM +0200, Luigi Rizzo wrote: ... > > The problem was fixed by the following one-line addition to > > hw/e1000.c :: e1000_mmio_write() , to wakeup the qemu mainloop and > > check that some buffers might be available. > > > > --- hw/e1000.c.orig 2012-02-17 20:45:39.000000000 +0100 > > +++ hw/e1000.c 2012-05-30 20:01:52.000000000 +0200 > > @@ -919,6 +926,7 @@ > > DBGOUT(UNKNOWN, "MMIO unknown write > > addr=0x%08x,val=0x%08"PRIx64"\n", > > index<<2, val); > > } > > + qemu_notify_event(); > > } > > > > static uint64_t > > > > With this fix, the read throughput reaches 1 Mpps matching the write > > speed. Now the system becomes CPU-bound, but this opens the way to > > more optimizations in the emulator. > > > > The same problem seems to exist on other network drivers, e.g. > > hw/rtl8139.c and others. The only one that seems to get it > > right is virtio-net.c > > > > I think it would be good if this change could make it into > > the tree. > > > > [Note 1] Netmap ( http://info.iet.unipi.it/~luigi/netmap ) > > is an efficient mechanism for packet I/O that bypasses > > the network stack and provides protected access to the > > network adapter from userspace. > > It works especially well on top of qemu because the > > kernel needs only to trap a single register access > > for each batch of packets. > > > > [Note 2] the custom backend is a virtual local ethernet > > called VALE, implemented as a kernel module on the host, > > that extends netmap to implement communication > > between virtual machines. > > VALE is extremely efficient, currently delivering about > > 10~Mpps with 60-byte frames, and 5~Mpps with 1500-byte frames. > > The 1 Mpps rates i mentioned are obtained between qemu instances > > running in userspace on FreeBSD (no kernel acceleration whatsoever) > > and using VALE as a communication mechanism. > > "Custom backend" == you patched QEMU? Or what backend are you using? > > This sounds a lot like [1] and suggests that you are either a) using > slirp in a version that doesn't contain that fix yet (before 1.1-rcX) or > b) wrote a backend that suffers from a similar bug. > > Jan > > [1] http://thread.gmane.org/gmane.comp.emulators.qemu/144433
my custom backend is the one in [Note 2] above. It replaces the -net pcap/user/tap/socket option which defines how qemu communicate with the host network device. The problem is not in my module, but rather in the emulation device exposed to the guest, and i presume this is the same thing you fixed in the "slirp" patch. I checked the git version http://git.qemu.org/qemu.git and most guest-side devices have the same problem, only virtio-net does the notification. cheers luigi
