summaryrefslogtreecommitdiff
path: root/hw/usb/core.c
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2012-10-31 13:47:09 +0100
committerGerd Hoffmann <kraxel@redhat.com>2012-11-01 15:17:58 +0100
commita552a966f16b7b39c5df16fc17e12d02c4fa5954 (patch)
tree507d819855224e6983b506c4c7774d225e1eec13 /hw/usb/core.c
parent7f102ebeb5bad7b723a25557234b0feb493f6134 (diff)
downloadqemu-a552a966f16b7b39c5df16fc17e12d02c4fa5954.tar.gz
usb: Add packet combining functions
Currently we only do pipelining for output endpoints, since to properly support short-not-ok semantics we can only have one outstanding input packet. Since the ehci and uhci controllers have a limited per td packet size guests will split large input transfers to into multiple packets, and since we don't pipeline these, this comes with a serious performance penalty. This patch adds helper functions to (re-)combine packets which belong to 1 transfer at the guest device-driver level into 1 large transger. This can be used by (redirection) usb-devices to enable pipelining for input endpoints. This patch will combine packets together until a transfer terminating packet is encountered. A terminating packet is a packet which meets one or more of the following conditions: 1) The packet size is *not* a multiple of the endpoint max packet size 2) The packet does *not* have its short-not-ok flag set 3) The packet has its interrupt-on-complete flag set The short-not-ok flag of the combined packet is that of the terminating packet. Multiple combined packets may be submitted to the device, if the combined packets do not have their short-not-ok flag set, enabling true pipelining. If a combined packet does have its short-not-ok flag set the queue will wait with submitting further packets to the device until that packet has completed. Once enabled in the usb-redir and ehci code, this improves the speed (MB/s) of a Linux guest reading from a USB mass storage device by a factor of 1.2 - 1.5. And the main reason why I started working on this, when reading from a pl2303 USB<->serial converter, it combines the previous 4 packets submitted per device-driver level read into 1 big read, reducing the number of packets / sec by a factor 4, and it allows to have multiple reads outstanding. This allows for much better latency tolerance without the pl2303's internal buffer overflowing (which was happening at 115200 bps, without serial flow control). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Diffstat (limited to 'hw/usb/core.c')
-rw-r--r--hw/usb/core.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/hw/usb/core.c b/hw/usb/core.c
index 632a8efe47..ab37f6f7b8 100644
--- a/hw/usb/core.c
+++ b/hw/usb/core.c
@@ -545,6 +545,7 @@ void usb_packet_setup(USBPacket *p, int pid, USBEndpoint *ep, uint64_t id,
p->parameter = 0;
p->short_not_ok = short_not_ok;
p->int_req = int_req;
+ p->combined = NULL;
qemu_iovec_reset(&p->iov);
usb_packet_set_state(p, USB_PACKET_SETUP);
}