Re: Questions on submitting multiple URBs in an IrDA dongle driver

On Thu, 16 Aug 2007, Alex Villací­s Lasso wrote:

> I was reviewing chapter 13 of Linux Device Drivers, the one about USB. 
> If I read it correctly, it states that any endpoint of an USB device 
> supports a queue of URBs, so that a driver can submit several of them 
> before the first one is finished. I was pondering on this since the IrDA 
> drivers I have (kingsun-sir in mainline, and ks959-sir/ksdazzle-sir 
> being reviewed for 2.6.24) follow a simple pattern of submitting at most 
> one URB for each endpoint of interest (one for reading, one for 
> writing), or in the case of ks959-sir, one URB per required direction. 
> Now that kingsun-sir and ks959-sir seem to work without problems, I was 
> thinking whether I could expect to improve the throughtput for these 
> dongles by submitting several queued URBs for reading and writing. I 
> must note that all of these devices are low-speed, and that 
> kingsun-sir/ksdazzle-sir use interrupt transfers, while ks959-sir uses 
> control URBs.
> 
> 1) This might seem to be a stupid question, but is there a hard 
> guarantee that (in the absence of USB errors) callbacks for queued URBs 
> (within a single endpoint) will be called in the exact same order on 
> which the URBs were queued? The chapter on USB in the Linux Device 
> Drivers book is silent on this.

It's not a stupid question.  Although this isn't documented anywhere 
that I know of (and it should be!), the answer is Yes.

> 2) In the case of transmission, all of my drivers issue 
> netif_stop_queue() when it is time to send a packet 
> (kingsun_hard_xmit()), leave it stopped after submitting the URB, and 
> only issue netif_wake_queue() in the callback routine for the Tx URB 
> used to transmit the wrapped packet. Can I expect any increase of speed 
> if the driver allocates URBs to be queued at the endpoint, and calls 
> netif_wake_queue() right after submitting the URB? If so, what steps 
> should I take to avoid filling up the queue with URBs waiting to be sent?
> 3) In the case of reception, should I expect any increase of speed if I 
> submit multiple URBs to poll for available data in the dongle?

Speed depends on a number of factors.  The most important is the 
location of the primary bottleneck.  How fast do your IrDA transfers 
run?  The overhead caused by failure to queue multiple URBs tends to be 
fairly small, except at high speed (480 Mb/s).  At low speed I doubt 
you will notice any difference at all; the USB bus is the bottleneck --
not the rate of URB submissions.

As for how to avoid filling up the queue with URBs waiting to be sent, 
why would you want to avoid it?  What's the use of having a queue if 
you can't fill it up?  If you want to know how to prevent the queue 
from growing indefinitely long, the answer is simple: Stop allocating 
URBs once you're reached your limit, and reuse the existing ones as 
they become available.

> I ask this because examination of SnoopyPro logs (even if not completely 
> reliable) suggests that the Windows drivers do submit more than one URB 
> for reading and for writing, and I was wondering whether this could be 
> implemented in the Linux drivers, and whether any speedups are to be 
> expected.

It certainly can be implemented, and some drivers do it already.  The 
speedup to be expected depends on how fast the other elements of the 
communications chain are.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel