On Mon, Sep 30, 2013 at 5:51 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Markus, > >>>>>>> Do you have a userspace test program that we can use to verify that this >>>>>>> does work, and that others can use to run on some different platforms to >>>>>>> verify that this is actually faster? >>>>>>> >>>>>> >>>>>> You will need one of our devices for testing I guess. Some scanners >>>>>> (which use USBFS) or other low speed devices won't really utilize >>>>>> usbfs too much. I think I could provide some grabber device for >>>>>> testing if you want to. >>>>> >>>>> So no test userspace program you can knock up for us? I really hate >>>>> adding new core functionality to the kernel that I have no way of >>>>> testing at all, that's a recipe for it quickly breaking... >>>>> >>>> >>>> Well do you have any device which has a userspace driver? Without a >>>> device you can barely test it. >>>> There's a settopbox company which added the backported patch to Linux >>>> 3.2 they use USB cardreaders and even tested the devices with and >>>> without mmap support. >>>> I doubt that the SG support has any good testing on low end systems, >>>> I'm worried that it will introduce those latency issues again which we >>>> saw with 15k buffers. >>> >>> There are lots of userspace drivers based on libusb or libusbx. If you >>> post an enhancement for libusbx to make use of your buffer mappings, >> >> those are free to adapt their libraries to use that feature (see first >> post how to use the ioctls). >> You need to find a reasonable application for those patches, I do not >> know anyone else using such a heavy bulk or isochronous application on >> low end systems not even on high end systems (otherwise you'd very >> likely be able to find more such kernel allocation messages on the >> internet and not only from us, obviously they all link to our forum or >> devices). >> VMWare, Qemu or Xen might be a good target for testing (when passing >> through windows requests and using a camera in windows). > > I think the same can be done with any standard Bluetooth controller and using SCO audio data for a headset connection. These also use ISOC transfers and as of today, do not work inside KVM. > > So if anybody wants to see if these changes actually make a difference, then a Qemu/KVM using them might be a good test case. > you might need some other optimizations for that regarding bluetooth. here are some videos from the Intel N270 which deal about USB (Our USB capture device connected to a DVD Player, transferring raw video 720x576 - 20mb/sec): http://sundtek.de/support/devio_legacy_n270.mts (legacy mode, just not using the allocation ioctl and mmap function) ~25% CPU http://sundtek.de/support/devio_mmap_n270.mts (new mmap'ed mode) ~18% CPU 5% of the driver is used by SIMD instructions to do some video filtering, the rest for the USB transfer (Video, Audio, VBI) and parsing the data. Markus -- 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
