On Sunday 01 August 2010 02:30:33 Greg KH wrote: > On Sat, Jul 31, 2010 at 10:52:54PM +0200, Christian Lamparter wrote: > > > > The driver uses a sophisticated 3 anchor layout: > > > > 1. rx_pool => a pool of prepared urbs, which can be > > > > submitted to the device anytime. > > > > > > Why a pool? Is allocating new ones somehow too slow? If so, why? > > > > Because the device uses some sort of streaming technology. > > That doesn't matter. Don't jump to conclusion. Let me try to explain it again. > > Basically, it aggregates multiple frames/command responses and traps > > into a single, large transfer (which can be as large as 32K) > > (Note: the _current_ limit is at 8K, but the HW supports up to 32K) > > > > So, the usual replacement buffers on-demand stuff is not an option. > > Why? At some point you need to fill up an urb and send it down. You > can always just allocate it at that point in time. > > Yes, urb pools are cool and fun and seem to work quicker, but I've yet > to see any platform that really needs them, as the USB transfer rates > dwarf any processing time to allocate the urbs dynamically as needed. > > But hey, it's your code, and your complexity to manage them :) Hmm, I see now where the problem is: communication. Maybe I should switch back to my old .de mail, so people will try harder to understand what I'm writing :-D It's all about the word "prepared" urbs. Allocating an urb is cheap that is true, but acquiring a big,continuous transfer buffer for it isn't, especially not in atomic callbacks where order-1+ etc. can regularly fail and produce noisy WARNINGs from the allocator. Incidentally, most network drivers uses the same techniques, but they're calling it "rx skb recycling" and are implementing it on top of sk_buff_head queuing mechanisms, because it's very convenient and a virtually bullet-proof API. This driver does virtually the same, but instead of sk_buff it uses urbs and bulk space from kmalloc and anchors as a replacement for sk_buff_head. This works beautiful too, so why not give it a similar name and call it "rx urb recycling"... Oh and yes, sometimes it's just nice when you can do things in a different way. It's a complex driver, but in this situation the proposed solution is actually the better choice. And because this is a USB-only chip and we don't have to sacrifice the urb engine for the more generic skb-type (which would depend on urbs as well). :-D Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
