qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: "David S. Ahern" <daahern@cisco.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: ehci update
Date: Wed, 14 Apr 2010 01:35:36 +0200	[thread overview]
Message-ID: <4BC4FFC8.3060702@web.de> (raw)
In-Reply-To: <4BC3F3FC.6050809@cisco.com>

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

David S. Ahern wrote:
> After a month of code refactoring and clean ups, etc, I thought I would
> send along an update. The attached patch is relative to your ehci
> branch; I also attached the full usb-ehci.c file for easier reading.

Thanks for your work! I applied it and once again merged git head at
this chance.

Just one request for the future: Please keep a queue of incremental
changes. This EHCI beast is sufficiently tricky, and at some point
someone (you included) may want to go back in history to find
out where some change came from, and why it was applied.

E.g.: We apparently regressed further /wrt my favorite test case (as
it's self-contained): "-usbdevice net". qemu is now entering an infinite
loop when you start dhcpcd in the guest on that interface.

> 
> At this point I can get a Windows XP guest to format a 4GB key and read
> from and write to it. I can get an FC-12 guest to format a 4GB key and
> an 8GB key as well as read from and write to both. Write rates are on
> the order of 8 MB/sec for dd:
> 
> # dd if=/dev/zero of=test bs=1M count=100 oflag=dsync
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB) copied, 12.1205 s, 8.7 MB/s
> 
> rsync of text files (e.g., /var/log) is on the order of 2MB/sec.
> 
> 4GB keys are definitely more stable; the 8GB is not recognized by
> Windows XP.
> 
> It still needs a lot of love, but definitely an improvement from the
> last version. The biggest difference for the performance boost and
> stability is discovering that the usbfs in linux limits transactions to
> 16k versus the EHCI spec which allows 20k per qTD. I added a hack to
> submit which detects 20k requests from a guest and breaks it up into 2
> requests through the host (a 16k and then a 4k).

Did someone already bring this up on LKML or wherever usbfs is
discussed? Should be fixable, I naively guess.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  reply	other threads:[~2010-04-13 23:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13  4:33 [Qemu-devel] ehci update David S. Ahern
2010-04-13 23:35 ` Jan Kiszka [this message]
2010-04-13 23:50   ` [Qemu-devel] " David S. Ahern
2010-04-14  1:20     ` Alexander Graf
2010-04-14  3:35       ` David S. Ahern
2010-04-14 19:38         ` Jan Kiszka
2010-04-14 19:48     ` Jan Kiszka

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=4BC4FFC8.3060702@web.de \
    --to=jan.kiszka@web.de \
    --cc=daahern@cisco.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).