Josh Myer wrote:
It's easy to understand if you focus on short network packets, maybe ones that just take two full speed USB packets: with queueing, you can exchange nine (and a half) such network packets per frame, else it's just one per frame. (Or at high speed they'd take part of one bulk packet, forty per microframe versus just one...) For bigger packets there's a smaller win, though at higher speeds (100BaseT full duplex over USB 2.0!) the difference will be significant even for big packets.Maybe (hah) i'm showing my ignorance here, but why not simply pass flags and callback to the lower level, and have it call you with its own completeed URBs, doing its own queueing? This is very nice, in that we should never block IO (although blocking IO is highly beneficial when you're running out of memory for URBs a delinquent driver isn't processing...).
There are several levels of queueing already, but only the USB level queueing corresponds to, say, the queueing done by a PCI based network driver. When you're doing something like full duplex 100BaseT (over a USB 2.0 link, naturally!) you really don't want to demand CPU attention after every packet, before sending the next one. Goals like eliminating interrupts get to be important on busy systems ... and you'd likely not even get near that 200 Mbit/sec limit without DMA level queues! A network driver that uses USB level queues won't block on I/O. See how the "usbnet" driver does it. When memory runs out, it's like any other driver: it drops the packets. When its tx queue fills, then the standard network queue throttling mechanism kicks in.
Most of the network drivers I've looked at have a configurable maximumThe reason i ask is that there's a lot of tuning to be done in a system structured like this, and tuning is annoying. Especially if there's a chance of getting the computer to do it for us.
queue depth, like "32 network packets". The idea is to make sure the
driver does NOT become a bottleneck, by having a big enough queue that
it handles good size bursts without dropping packets or demanding much
IRQ processing overhead.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
