Messages in this thread | | | Date | Thu, 6 Jan 2005 14:48:03 -0800 | From | Greg KH <> | Subject | Re: [linux-usb-devel] Re: [PATCH] macros to detect existance of unlocked_ioctl and ioctl_compat |
| |
On Thu, Jan 06, 2005 at 01:59:25PM -0800, David Brownell wrote: > On Thursday 06 January 2005 1:24 pm, Greg KH wrote: > > > P.S.: ?When designing new API, please do not make it unnecessary complicated. > > > USB video needs rather large bandwidth and low latency, so please no ASCII > > > strings, and scatter-gather aware API helps a bit... > > > > In measurements published on linux-usb-devel, pure userspace calls using > > the current usbfs code generated almost full bandwidth usage (within the > > hardware limits). ?So adding the scatter-gather api interface to usbfs > > wouldn't really provide that much benefit. > > Actually, the measurements I recall were using that > nasty usbfs-specific async API ... or using huge > buffers with the synchronous/blocking calls, so > the hiccups added by scheduling latencies didn't > kick in very often.
Ah, yeah, that's true.
> > And, we can always use help in designing such an API, if you could find > > someone at your company to help us out in doing so... :) > > Or just doing something like gadgetfs, where the standard > Linux "libaio" calls work just fine. I was certainly able > to stream 24 Mbyte/sec isochronous transfers (that's the > top speed possible with one high speed ISO endpoint). > > The key point is that one userspace IOCB should map directly > to one URB in the kernel; and one userspace file (descriptor) > should map to one USB endpoint. For a host side API, it turns > out that isochronous URBs already have limited scatter/gather > style support -- each one maps to several packets. > > I think it'd be best to use the existing AIO support rather > than have usbfs2 create yet another USB-specific thing.
I completely agree.
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |