Re: [Qemu-devel] [PATCH 12/14] usb-core: usb3 streams

[Hans de Goede]

Hi,

On 02/21/2013 03:27 PM, Gerd Hoffmann wrote:
>    Hi,
>
> > Hmm, I was expecting epqueues to become a per stream thing with streams,
>
> I'll wanna see how far I come without that.
>
> The reason to have streams in the first place is to parallelize things,
> i.e. spread requests over streams instead of building up queues.  Also
> xhci has practically unlimited transfer sizes, so there is no reason to
> split large transfers into multiple usb packets.
>
> Thus I'd expect multiple packets being queued up in a stream being
> pretty unusual, and having a per-stream queue probably isn't very
> helpful as they wouldn't queue up anything in practice.

Ok.


> > ie an error on one stream should only lead to cancelling queued packets
> > from that stream,
>
> I don't think so.  On error one can only stall endpoints, not streams.

True, I was already wondering how stalls would work in this case, I guess
that streams using usb-protos don't use stall, but instead just send a
bulk-packet with an error-status at the device-proto level.

> > and like wise submitting a packet for stream 2, should
> > not wait for a previous packet submitted for stream 1 to complete, which
> > it will with the one epqueue for all streams model (I know pipelining
> > works around this, but it still shows the concept of 1 queue for
> > all the streams us wrong IMHO).
>
> Well, that is exactly my plan:  Simply enable pipelining to actually
> parallelize stuff.  And sprinkle in some if's here and there (to allow
> out-of-order completion on stream packets for example).

Ok.

> Not done yet because stress testing this is blocked by broken stream
> handling in the linux xhci driver.

Regards,

Hans