Hans Verkuil wrote: >> Hans Verkuil wrote: >> - performance is important only for the ioctl's that directly handles >> the streaming (dbuf/dqbuf & friends); > > What performance? These calls just block waiting for a frame. How the hell > am I suppose to test performance anyway on something like that? They are called on the main loop for receiving buffers. As the userspace may be doing some video processing, by introducing latency here, you may affect the applications. By using perf subsystem, you should be able to test how much time is spent by an ioctl. > >> - videobuf has its own lock implementation; >> >> - a trivial mutex-based approach won't protect the stream to have >> some parameters modified by a VIDIOC_S_* ioctl (such protection should be >> provided by a resource locking); > > Generally once streaming starts drivers should return -EBUSY for such > calls. Nothing to do with locking in general. Yes, that's exactly what I said. This is a resource locking: you cannot change several stream properties while streaming (yet, you can change a few ones, like bright, contrast, etc). >> then, maybe the better would be to not call the hooks for those ioctls. >> It may be useful to do some perf tests and measure the real penalty before >> adding >> any extra code to exclude the buffer ioctls from the hook logic. > > Yuck. We want something easy to understand. Like: 'the hook is called for > every ioctl'. Not: 'the hook is called for every ioctl except this one and > this one and this one'. Then the driver might have to do different things > for different ioctls just because some behind-the-scene logic dictated > that the hook isn't called in some situations. > > I have said it before and I'll say it again: the problem with V4L2 drivers > has never been performance since all the heavy lifting is done with DMA, > the problem is complexity. Remember: premature optimization is the root of > all evil. If a driver really needs the last drop of performance (for what, > I wonder?) then it can choose to just not implement those hooks and do > everything itself. I tend to agree with you. All I'm saying is that it is valuable to double check the impacts before committing it. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
