From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL86L-0001Kw-PJ for qemu-devel@nongnu.org; Mon, 08 Oct 2012 03:50:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TL86K-000618-QV for qemu-devel@nongnu.org; Mon, 08 Oct 2012 03:50:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL86K-0005yg-Ai for qemu-devel@nongnu.org; Mon, 08 Oct 2012 03:50:08 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q987o6WF000737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Oct 2012 03:50:06 -0400 From: Hans de Goede Date: Mon, 8 Oct 2012 09:51:24 +0200 Message-Id: <1349682696-3046-1-git-send-email-hdegoede@redhat.com> Subject: [Qemu-devel] [PATCH 00/12] RFC: usb: input pipelining support and other speedups List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org This patchset started out as adding support for pipelining of input bulk transfers, although input pipelining is a bit tricky to do, there are 2 good reasons to do it: 1) Performance, I expect this to ie significantly speed-up reading from USB mass storage devices. 2) Currently reading from a USB<->serial converter, ie a pl2303 based one is unreliable when the serial transport is not using flowcontrol. The problem is that 115200 bps takes aprox 200 64 bytes packets / sec, which means we must not exceed a roundtip time average of 5 ms over a period of 20 ms. If within any 20 ms period we exceed that round trip time average the internal buffer of the pl2303 will likely overflow. Input pipelining greatly improve things here as: 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. I had working on this on my mind for a while because of 1), and 2) has made me spend the necessary time to get this working now. Even though 2 was my main reason to start working on this now, most of my testing sofar has focussed on 1, resulting in some more speedup patches and a total improvement of the read speed from a cheap USB thumb drive from 4.4 MB/s to 10.8 MB/s or a factor of 2.4 ! The reason this patch-set is currently still RFC is because I need to run more tests wrt 2). Despite the RFC status reviews are very much welcome now! Regards, Hans