From: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
To: james.harper@bendigoit.com.au, xen-devel@lists.xensource.com
Subject: Re: pvusb performance
Date: Mon, 14 Sep 2009 11:36:41 +0900 [thread overview]
Message-ID: <4AADAC39.5090106@jp.fujitsu.com> (raw)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D0177D267@trantor>
James,
> I don't think that unlink by itself would solve it. The failure scenario
> I am think of is when Windows gives me a URB with 64k of data to read or
> write and an error occurs. I need to break that up to send to usbback,
> but if I have 128 x 512 bytes requests on the ring and the first one
> fails, usbback will still continue to execute the remaining 127. I'm not
> sure that that matters for a regular read error which is presumably a
> rare occurance, but what about for a device which could do a 'short
> read'?
We might have to understand the difference of linux and windows USB
driver's behaviors.
In linux, I think,
- If 128 requests on the ring and the first one fails, usbback will
still continue to the remaining 127.
Subsequent requests may succeed or fail or not response. In ether
case, USB device driver in the frontend can identify the urb failure,
and re-initialize the device or unlink urbs.
- Reporting short-reads as errors or not is defined by the USB
device driver itself.
"USB_SHORT_NOT_OK" bit of the urb->transfer_flags is that.
I doubt host controller driver needs to clean up the error.
> Maybe we could have a sequence number in the req and so once the error
> or short read occurs, usbback throws out all the remaining requests with
> that sequence number (just returns them with a status to indicate that
> they weren't used). The expected next sequence number would be kept by
> usbback in the data structure for each and usbback would discard any
> request with an unexpected sequence number...
>
> Why do you allow up to 10 4K segments to be attached to the request? The
> upper limit for usb packet size seems to be 512 bytes... or do ISOC
> requests allow more (I don't know anything about those yet).
USB packat size and urb->transfer_buffer_length are different.
The first is the actual USB transfer size that is defined in USB Spec,
the second is the data size handled by urb.
usbfront and usbback transfers urb.
Some device drivers that require over 10 * 4K segments can not be
supported by current pvusb.
Regards,
Noboru
next prev parent reply other threads:[~2009-09-14 2:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-12 3:57 pvusb performance James Harper
2009-09-14 0:55 ` Noboru Iwamatsu
2009-09-14 1:19 ` James Harper
2009-09-14 2:36 ` Noboru Iwamatsu [this message]
2009-09-14 5:19 ` James Harper
2009-09-14 5:45 ` Noboru Iwamatsu
2009-09-14 5:49 ` James Harper
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=4AADAC39.5090106@jp.fujitsu.com \
--to=n_iwamatsu@jp.fujitsu.com \
--cc=james.harper@bendigoit.com.au \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.