mirror of https://github.com/xqemu/xqemu.git
831e882253
tl;dr: This patch introduces an alternate way of handling the receive buffers of the spapr-vlan device, resulting in much better receive performance for the guest. Full story: One of our testers recently discovered that the performance of the spapr-vlan device is very poor compared to other NICs, and that a simple "ping -i 0.2 -s 65507 someip" in the guest can result in more than 50% lost ping packets (especially with older guest kernels < 3.17). After doing some analysis, it was clear that there is a problem with the way we handle the receive buffers in spapr_llan.c: The ibmveth driver of the guest Linux kernel tries to add a lot of buffers into several buffer pools (with 512, 2048 and 65536 byte sizes by default, but it can be changed via the entries in the /sys/devices/vio/1000/pool* directories of the guest). However, the spapr-vlan device of QEMU only tries to squeeze all receive buffer descriptors into one single page which has been supplied by the guest during the H_REGISTER_LOGICAL_LAN call, without taking care of different buffer sizes. This has two bad effects: First, only a very limited number of buffer descriptors is accepted at all. Second, we also hand 64k buffers to the guest even if the 2k buffers would fit better - and this results in dropped packets in the IP layer of the guest since too much skbuf memory is used. Though it seems at a first glance like PAPR says that we should store the receive buffer descriptors in the page that is supplied during the H_REGISTER_LOGICAL_LAN call, chapter 16.4.1.2 in the LoPAPR spec declares that "the contents of these descriptors are architecturally opaque, none of these descriptors are manipulated by code above the architected interfaces". That means we don't have to store the RX buffer descriptors in this page, but can also manage the receive buffers at the hypervisor level only. This is now what we are doing here: Introducing proper RX buffer pools which are also sorted by size of the buffers, so we can hand out a buffer with the best fitting size when a packet has been received. To avoid problems with migration from/to older version of QEMU, the old behavior is also retained and enabled by default. The new buffer management has to be enabled via a new "use-rx-buffer-pools" property. Now with the new buffer pool management enabled, the problem with "ping -s 65507" is fixed for me, and the throughput of a simple test with wget increases from creeping 3MB/s up to 20MB/s! Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> |
||
|---|---|---|
| .. | ||
| 9pfs | ||
| acpi | ||
| alpha | ||
| arm | ||
| audio | ||
| block | ||
| bt | ||
| char | ||
| core | ||
| cpu | ||
| cris | ||
| display | ||
| dma | ||
| gpio | ||
| i2c | ||
| i386 | ||
| ide | ||
| input | ||
| intc | ||
| ipack | ||
| ipmi | ||
| isa | ||
| lm32 | ||
| m68k | ||
| mem | ||
| microblaze | ||
| mips | ||
| misc | ||
| moxie | ||
| net | ||
| nvram | ||
| openrisc | ||
| pci | ||
| pci-bridge | ||
| pci-host | ||
| pcmcia | ||
| ppc | ||
| s390x | ||
| scsi | ||
| sd | ||
| sh4 | ||
| smbios | ||
| sparc | ||
| sparc64 | ||
| ssi | ||
| timer | ||
| tpm | ||
| tricore | ||
| unicore32 | ||
| usb | ||
| vfio | ||
| virtio | ||
| watchdog | ||
| xen | ||
| xenpv | ||
| xtensa | ||
| Makefile.objs | ||