RE: [Xen-devel] pvusb performance

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> 
> > I think maybe it can't with your current usbback driver - there
would
> > need to be some mechanism to flush the ring of all subsequent
requests
> > in the case of an error, eg when I get a 'Read 65536 bytes' request
from
> > Windows, I do this:
> >
> > . Put read request command on ring
> > . Wait for response
> > . Put data request on ring for first 512 bytes
> > . Wait for response
> > . Put data request on ring for next 512 bytes
> > . etc
> > . etc
> >
> > If there is a buffer underrun, I can see no way for Linux to do
> > something with the subsequent data requests... it would need to do
> > something like put the ring into a error/underrun condition and
'eat'
> > all the requests until a clear error request came down the ring.
> >
> > Or maybe this is already part of the design?
> 
> Current pvusb doesn't care it.
> 
> You mean, when error occurred, HCD has to be responsible for flushing
> the subsequent requests?
> 
> Should urb transferring errors be handled with USB device drivers
> (the upper layer of HCD)?
> 
> If urb unlinking work properly, would it be solved?
> 

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'?

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).

James


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