You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since Linux 4.9, the usbfs subsystem includes a mechanism to support zero-copy transfers, by allowing userspace to mmap an open usbfs device to get a DMA-ready buffer. When such a buffer is used in a request, the kernel can arrange for the host controller to access it directly.
It would be nice if nusb could use this feature, as it may make a significant performance difference especially at SuperSpeed, but there would be some API and safety implications.
In principle, you could add a method to Device which returns a RequestBuffer allocated this way with mmap, and put some metadata in the RequestBuffer struct to indicate that drop needs to call munmap. However, it would then no longer be safe to turn that RequestBuffer into a normal Vec and back.
The text was updated successfully, but these errors were encountered:
Since Linux 4.9, the usbfs subsystem includes a mechanism to support zero-copy transfers, by allowing userspace to
mmap
an open usbfs device to get a DMA-ready buffer. When such a buffer is used in a request, the kernel can arrange for the host controller to access it directly.This feature is supported in libusb via the
libusb_dev_mem_alloc
andlibusb_dev_mem_free
functions.It would be nice if nusb could use this feature, as it may make a significant performance difference especially at SuperSpeed, but there would be some API and safety implications.
In principle, you could add a method to
Device
which returns aRequestBuffer
allocated this way withmmap
, and put some metadata in theRequestBuffer
struct to indicate thatdrop
needs to callmunmap
. However, it would then no longer be safe to turn thatRequestBuffer
into a normalVec
and back.The text was updated successfully, but these errors were encountered: