Re: UIO - interrupt performance
Ben Nizette wrote: On Mon, 2008-10-20 at 03:06 -0800, Nicholas Mc Guire wrote: On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote: We are contemplating porting a large number of device drivers to Linux. The pragmatic solution is to keep them in user mode (using the UIO framework) where possible ... they are written in C++ for a start. The obvious disadvantages of user mode device drivers are security / isolation. The main benefit is ease of development. Do you know what the *technical* disadvantages of this approach might be? I am most concerned about possible impact on interrupt handling. For example, I assume the context switching overhead is higher, and that interrupt latency is more difficult to predict? Userspace drivers certainly aren't first class citizens; uio and kernel mode drivers generally aren't really interchangeable. The technical disadvantages of userspace drivers are that you don't have access to kernel subsystems, you can't run any userspace content in irq context so everything needs to be scheduled before it can be dealt with. A UIO driver still needs a kernel component to do acknowledge the interrupt. As such when you say interrupt latency you need to define the end point. A UIO driver will have it's in-kernel handler called just as quickly as any other driver but the userspace app will need to be scheduled before it receives notification that the IRQ has fired. The technical advantage of a UIO driver is that devices which only need to shift data don't have to double-handle it. e.g. an ADC card doesn't need to move ADC results from hardware to kernel, kernel to userspace, it's just one fluid movement. What kind of device drivers are you talking about? They have to be of a fairly specific flavour to fit in to a UIO model. Linux isn't a microkernel, userspace drivers are quite restricted in their power. are these claims based on benchmarks of a specific driver ? I only know of a singe UIO driver for a Hilscher CIF card and one for a SMX Cryptengine (I guess thats yours any way) but none for a AD/DIO card - if you know of such a driver I would be interested in seeing its performance. When UIO was being discussed for inclusion, the example case being thrown around was for such an ADC card. They claimed to have seen significant improvements in speed by avoiding the double-handling of data. Come to think of it, I can't see that this specific driver has shown up... But what kind of benchmarks do you want? When I say restricted in their power I mean more in a feature-set kind of way than a raw speed way. Userspace drivers can't plug in to kernel subsystems so can't, for example, be SPI hosts or terminal devices or network hardware or anything else which sits in the middle of a standard stack. All they can do is be notified of an interrupt and have direct access to a lump of memory. As I asked before, what's your use-case? It tends to be fairly obvious whether the hardware is suitable for a UIO-based driver or whether it's going to have to live in kernel. Also if you know of any simple UIO sample drivers that would also help. As in examples of the userspace half? Unfortunately uio-smx isn't ready to fly thanks to some significant production delays but the userspace half of the Hilscher CIF driver can be found at http://www.osadl.org/projects/downloads/UIO/user/ As I see it, mainly the license conditions attract people to use UIO. Performance is not that important. Wolfgang. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
On Tue, 2008-10-21 at 08:57 +0200, Wolfgang Grandegger wrote: Ben Nizette wrote: As in examples of the userspace half? Unfortunately uio-smx isn't ready to fly thanks to some significant production delays but the userspace half of the Hilscher CIF driver can be found at http://www.osadl.org/projects/downloads/UIO/user/ As I see it, mainly the license conditions attract people to use UIO. Performance is not that important. Ohw god I hope not. If people want to keep their stuff proprietary they can supply binary-only modules a la nvidia. Thankfully such nonsense is fairly uncommon these days. UIO is not a set of hooks for general userspace drivers, it can't replace 99% of kernel drivers. It exists to allow easy and high-performance interfacing to a particular family of devices - those which simply need to shift data around and have an interrupt telling you when they're done. --Ben. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? --Ben. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
Ben Nizette wrote: On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. I known, fortunately it's not that simple or even feasible. Image a network driver with I/O multiplexing used by various processes. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to That's *not* an option, please read the GPL license conditions. At least it's legal gray area. Note that it's not my intention to start a discussion on that. a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? There will be plenty sooner than later. What you can do currently with UIO is very limited. Wolfgang. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
No I don't think you can decide kernel or user space, indeed you can read my previous posts, I quite agree with you, I meant the same to Bill Gatliff. Ben Nizette ha scritto: On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? --Ben. -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
Wolfgang Grandegger wrote: Ben Nizette wrote: On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. I known, fortunately it's not that simple or even feasible. Image a network driver with I/O multiplexing used by various processes. Actually, UIO is pretty useful for that when combined with tun/tap. That's *not* an option, please read the GPL license conditions. At least it's legal gray area. Note that it's not my intention to start a discussion on that. Then I will only contradict you, and not cite my supporting evidence. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
UIO - interrupt performance
We are contemplating porting a large number of device drivers to Linux. The pragmatic solution is to keep them in user mode (using the UIO framework) where possible ... they are written in C++ for a start. The obvious disadvantages of user mode device drivers are security / isolation. The main benefit is ease of development. Do you know what the *technical* disadvantages of this approach might be? I am most concerned about possible impact on interrupt handling. For example, I assume the context switching overhead is higher, and that interrupt latency is more difficult to predict? --jim douglas Avaya UK, Registered in England and Wales under Registered Number 3049861, Registered Address: Avaya House, Cathedral Hill, Guildford, Surrey, GU2 7YL. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
I quite agree with Ben and Christian. I think UIO drivers are usable for simple devices, I think they aren't mature (will it ever be?) to use it with complicated devices or with strict requirement. Regards, Douglas, Jim (Jim) ha scritto: We are contemplating porting a large number of device drivers to Linux. The pragmatic solution is to keep them in user mode (using the UIO framework) where possible ... they are written in C++ for a start. The obvious disadvantages of user mode device drivers are security / isolation. The main benefit is ease of development. Do you know what the *technical* disadvantages of this approach might be? I am most concerned about possible impact on interrupt handling. For example, I assume the context switching overhead is higher, and that interrupt latency is more difficult to predict? --jim douglas Avaya UK, Registered in England and Wales under Registered Number 3049861, Registered Address: Avaya House, Cathedral Hill, Guildford, Surrey, GU2 7YL. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
Thomas Petazzoni wrote: There was a presentation on UIO in embedded systems at the latest Embedded Linux Conference in April. The presentation includes a small analysis of UIO's overhead with regard to interrupt latency. See http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf Bummer, on p. 20 it doesn't describe how the latency was measured. It also doesn't compare in-kernel measurements with equivalent UIO measurements. I don't particularly care what the interrupt latency is, if what is being measured is the time between when the interrupt is signaled to the CPU and the point at which the request_irq()-registered handler runs. Rather, most of the time I care more about how long it takes the kernel to wake up the process that's blocked in a wait_for_completion(), because I do most of my work outside of interrupt handlers (a characteristic of the devices and workloads I deal with, ymmv). In that case, the difference between in-kernel and UIO gets pretty small because the kernel activities at each interrupt are very similar, perhaps differing only by some cache activity. Glad they mention SCHED_[FIFO|RR], though. Without those, you're in for a pretty unpleasant UIO experience. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
