>>That'd certainly be a better approach for supporting sglist in the
>>usb-storage code than the alternatives I've heard so far.
>
> Could you elaborate ? This sounds interesting.
It's been discussed on linux-usb-devel more than once.
It's really a secondary or tertiary consideration. The top
performance issue for usb-storage in USB 2.0 is that it doesn't
yet use bulk queueing for its requests ... which means that it
wastes at least half the bandwidth available to it (staying in
the low tens of MByte/sec vs twenties or even higher). [*]
The sglist issue is a "how to create fewer DMA mappings" issue.
There are specific sglist DMA mapping calls, but they can't
be used without adding to the usbcore API ... either sglist,
usable only by usb-storage AFAICT, or something more general
like dma_addr_t.
In any case it's an optimization issue that doesn't seem like it
should be at the front of anyone's list for some time.
- Dave
[*] Yes, patches have been available to fix it. Not updated
after the block I/O changes in 2.5, but not hard to do so.
Worth updating and integrating after the HCD stuff settles
down so we can make sure that all three major HCDs do the
bulk queuing correctly in both success and failure paths.
-
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 : Sat Jun 15 2002 - 22:00:27 EST