On Wed, 6 Jun 2007 11:16:51 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> So what exactly is the problem? Is the documentation wrong? In the vast majority of cases, streaming transfer is more appropriate, which is what you receive if you let HCD to establish and tear down mappings. The consistent allocation was intended to things like mailboxes, where it is more advantageous to load a couple of words from uncached memory than to call an API which invalidates or flushes the caches. In case of USB, QHs and TDs are a good example, which is why the pool allocation is layered on top of consistent allocations. It we all were using SPARC or MIPS, we'd learn this pretty quickly. However, on x86 and s390, which are I/O coherent, there is really not much difference. The consistent mapping is cached. So this decision is comes down pretty much to giving a damn about ARM or SPARC. There is also a question of tying up IOMMU resources for a long time. If you set up DMA mappings in advance with usb_buffer_alloc, you keep a part of your IOMMU unavailable to things like mass storage, which may actually benefit from it. I don't know if this effect is all that important anymore. On 32-bit sparc it was a nightmare, because its IOMMU area was miniscule, but that architecture is dead. I happen to know that our customers with Opterons sometimes are limited by the IOMMU sizes. However, IOMMU is pretty big there. If you wasted a few pages for USB, it's not going to hurt your database performance all that much. So, I think we do not have enough data to use this as an argument. Personally, I'm inclined towards using kmalloc by default for a new interface like a refcounted buffer. If someone finds a case where usb_buffer_alloc is better, they are free to use it with old API like they do now. The skbuffs are set up this way and it seems to work. -- Pete ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
