qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining
Date: Mon, 08 Oct 2012 14:50:12 +0200	[thread overview]
Message-ID: <5072CC04.4010300@redhat.com> (raw)
In-Reply-To: <1349682696-3046-5-git-send-email-hdegoede@redhat.com>

On 10/08/12 09:51, Hans de Goede wrote:
> Currently we effectively only do pipelining for output endpoints, since
> controllers will stop filling the queue for a packet with stop the queue
> on a short read semantics enabled.

> This causes large input transfers to get split into multiple packets, which
> comes with a serious performance penalty.
> 
> This patch makes it possible to do pipelining for input endpoints, by
> re-combining packets which belong to 1 transfer at the guest device-driver
> level into 1 large packet before sending them to the device, this is mostly
> useful as a significant performance improvement for redirection of real USB
> devices.

This splitting and recombining is too much magic in the core layer for
my taste.

I think the core work flow should stay as-is.  Instead we should add
more meta data to USBPacket (stop-queue-on-short-read bit, maybe
interrupt-on-complete too).  Continue queuing packets even with
stop-queue-on-short-read set.  Maybe add a callback to notify USBDevice
when the host controller is done filling the queue, so USBDevices can
process all queued packets in one go (bottom half would work too
though).  Then expect USBDevices to get things right based on the
USBPacket flags passed on (i.e. have host-linux use
USBFS_URB_BULK_CONTINUATION as needed).

This way usb-host and usbredir will see what is really going on instead
of having the usb core magically fixing up stuff for them.  I think this
will serve us better long-term.  Maybe you are seeing this "data *and*
stall" issue (patch 1) exactly because of all this combining & splitting
logic?

cheers,
  Gerd

  reply	other threads:[~2012-10-08 12:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08  7:51 [Qemu-devel] [PATCH 00/12] RFC: usb: input pipelining support and other speedups Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 01/12] usb-redir: When a packet contains data on a stall, ignore the stall Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 02/12] usb-redir: Add support for 32 bits bulk packet length Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 03/12] usb-host-linux: Only enabling pipeling for output endpoints Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 04/12] usb: Add support for input pipelining Hans de Goede
2012-10-08 12:50   ` Gerd Hoffmann [this message]
2012-10-08 14:50     ` Hans de Goede
2012-10-09  9:21       ` Gerd Hoffmann
2012-10-09 10:40         ` Hans de Goede
2012-10-09 13:31           ` Gerd Hoffmann
2012-10-09 14:19             ` Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 05/12] uhci: Properly unmap packets on cancel / invalid pid Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 06/12] uhci: Move checks to continue queuing to uhci_fill_queue() Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 07/12] uhci: Add support for input queuing Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 08/12] ehci: Get rid of packet tbytes field Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 09/12] ehci: Set int flag on a short input packet Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 10/12] ehci: Add support for input queuing Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 11/12] ehci: Improve latency of interrupt delivery and async schedule scanning Hans de Goede
2012-10-08  7:51 ` [Qemu-devel] [PATCH 12/12] ehci: Speed up the timer of raising int from the async schedule Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5072CC04.4010300@redhat.com \
    --to=kraxel@redhat.com \
    --cc=hdegoede@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).