From: Peter Stuge [mailto:pe...@stuge.se]
> > Userspace doesn't care since everything gets copied into aligned
> > kernel fragments - otherwise the other usb controllers wouldn't work.
>
> OK, but not so great if someone wants to squeeze the most performance
> possible out of USB also from userspace.
>
> I'm going off on a tangent now but would it make sense to allow
> userspace to do alignment if it wants to, and have a way to tell
> the kernel when urb buffers are pre-aligned?
I can only see that mattering if either:
1) The userspace buffers are (say) 4n+1 aligned and the kernel
decides to align the copy_from_user().
2) The code is doing buffer-loaning.
Personally I'm not at all sure how often buffer-loaning helps
(given the cost of the TLB shootdowns that it often implies).
I guess it might be ok if the memory doesn't have to be given
a KVA and the user program avoids any COW.
In any case and such code could be limited to page-aligned transfers.
And/or the user code would have to know at least some of the constraints.
The other usb controllers only support 'message' aligned transfers
(512 bytes for USB2). All the code I've found achieves this by using
page aligned (maybe 4k aligned) fragments. xhci trivially supports this
(it has since the 'ring expansion' code was added).
xhci can also easily support:
1) Arbitrary fragmentation for a limited number of fragments
(by constraining the fragments to a single ring segment).
2) Arbitrary fragmentation provided all the fragments (except the
last) exceed some minimal length (by splitting the current or
previous fragment at the appropriate boundary).
The code for the second is probably worth adding just in case
a 4k fragment crosses a 64k boundary.
Since arbitrarily fragmented packets can't be sent to other controllers
it does seem sensible for the code generating the urb so say that
it is (or might be) fragmented like that.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
