On Wed, 18 Nov 2015, Peter Stuge wrote: > Alan Stern wrote: > > if we can directly map the user-provided buffer for DMA. > > Given a memory buffer either kernel or userspace has to apply the > hardware constraints to find out what part if any is usable for DMA. > > I think it's fine to push this task to userspace - as long as > userspace has a way to take care of it. That means userspace must be > able to perform an allocation according to the constraints. I don't > think this is currently possible. Is that correct? As far as I know, it's not possible. In fact, the situation is worse than I thought at first. Memory allocated by userspace generally will not be located in physically contiguous pages. This means that using the memory as an I/O buffer will require scatter-gather. But the USB host controller drivers support scatter-gather only for bulk transfers, not isochronous. Of course, isochronous transfers already involve a weak sort of scatter-gather in the form of usbdevfs_iso_packet_desc lists. But at the driver level, the packets described by these lists must all sit in a single contiguous buffer. In theory a user program can work around this by submitting lots of small isochronous transfers instead of one big transfer. But that wastes resources in the form of excessive system calls. > The kernel could certainly do the allocation and hand the buffer to > userspace. Wiping the buffer once upon allocation is a reasonable > cost, because this allocation should be long-lived. For isochronous especially, this seems like the only way to go. > > On the other hand, adding an API that allows users to allocate low > > memory and then hiding it in the USB subsystem doesn't seem like a > > good idea. > > Unless another generic API already supports the neccessary constraints > then what other options are there? Adding a new generic API instead of hiding it in the USB subsystem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
