Messages in this thread | | | Date | Tue, 29 Apr 2003 21:55:03 -0700 | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: [Bluetooth] HCI USB driver update. Support for SCO over HCI USB. |
| |
Max Krasnyansky wrote: > > Basically I'd like to have same kind of API that we have for SKB without > an overhead of SKBs.
I'd also like to see most of the per-request invocation costs shrink. You seem to be focussing on the queueing parts of SKB-ness, yes? The lifecycles aren't that close; and other parts of the SKB and URB models are different too.
Inside USB, "usbcore" and the HCDs are already working with queues of URBs associated with each endpoint.
The USB device drivers can't do that as easily, since core/HCD owns the urb->urb_list field after usb_submit_urb() and before the completion callback is issued. Much like the next layer owns the SKB after you hand it off...
> Here is what I've done for Bluetooth HCI USB driver. > > struct _urb_queue { > struct list_head head; > spinlock_t lock; > }; > > struct _urb { > struct list_head list; > struct _urb_queue *queue; > struct urb urb;
Those fields (reordered) are like sk_buff_head and sk_buff. How much of that is "needed here" vs. "SKBs work like that"?
Today those spinlocks are driver-specific, and urb->context (or urb->hcpriv) seems to have been enough of a queue head backpointer for most drivers. The notable omission is the lack of a list_head for device drivers to use even after an URB has been submitted -- a lifecycle state that SKBs don't have.
> int type; > void *priv; > };
How would "priv" differ from the current per-request state, urb->context (for device driver) or urb->hcpriv (for HCD)?
I've also been interested in seeing something like skb->cb[]. HCDs could use that as pre-allocated per-request memory, avoiding per-request heap allocations.
> It's now easy to do things like > _urb_queue_tail(&pending_q, _urb); > usb_urb_submit(&_urb->urb); > and > while (_urb = _urb_dequeue(&pending_q)) > usb_unlink_urb(&_urb->urb);
Those resemble the kinds of primitives I might want to see in a Linux 2.7 USB API ... focussed on the endpoint (queue), rather than making the core/HCD layers do extra work to figure out what queue is involved. And ideally general enough that device drivers would work the same way.
That first pair is pretty much what any HCD does today, except that the endpoint's queue is hidden/internal and the second step is "feed it to the hardware!".
The second is pretty much what usbcore (now) does when it shuts down an endpoint's queue. But again, that queue is hidden/internal. Caller needs to ensure the hardware is not working on the queue during that loop, and there are some other synchronization issues too.
- Dave
> etc > > Max > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |