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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:33 EST