WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] pvusb performance

To: "Noboru Iwamatsu" <n_iwamatsu@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] pvusb performance
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Mon, 14 Sep 2009 15:19:14 +1000
Cc:
Delivery-date: Sun, 13 Sep 2009 22:19:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AADAC39.5090106@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D0177D241@trantor> <4AAD9470.9060701@xxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0177D267@trantor> <4AADAC39.5090106@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco05D7HY41KmUTKSHO4wlvshPxxUAAFRJpQ
Thread-topic: [Xen-devel] pvusb performance
> 
> > 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.
> 

Okay maybe I'm a bit confused then.

When Windows gave me a URB with 65536 bytes of data, I set buffer_length
to 65536 and filled up the SG registers accordingly, but usbback gave me
an error. When I break it into 512 byte (packet size) chunks it works
okay. I just assumed that you have to give usbback requests with less
that 'max packet size' of data.

Maybe the cause of my error was somewhere else? I'll try it again.

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>