On Mon, Sep 30, 2013 at 1:26 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > 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. > to explain why Isochronous makes such a difference, the kernel driver doesn't do the memset anymore for each urb packet. However that patch addresses multiple issues * Isochronous improvement by removing memset for each packet * Pre-Allocation to prevent allocation failures during runtime. * Allow to restore the original behavior for >15k buffers (I'd recommend to make further decisions about forcing SG transfers over Bulk transfers once manufacturers deliver low-end devices which include both possibilities) here we have seen the latency issue with certain chipsets when buffers are too small I don't know the behavior/latency of SG transfers unfortunately and there's no way to test it on the particular target system - other systems do not trigger that problem. As far as I can see there's still some space for improvements. (eg. pre-allocate large buffers (15k) for USB 3.x otherwise it will end up with allocation failures during runtime on low-end systems - as seen by our customers with USB 2.0 and 15k buffers on low-end systems). With SG and USB 3.0 this problem should happen even quicker than with USB 2.0. 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
