[中英对照]User-Space Device Drivers in Linux: A First Look

如对Linux用户态驱动程序开发有兴趣，请阅读本文，否则请飘过。

User-Space Device Drivers in Linux: A First Look | 初识Linux用户态设备驱动程序

User-Space Device Drivers in Linux: A First Look
Mats Liljegren
Senior Software Architect

Device drivers in Linux are traditionally run in kernel space, but canalso be run in user space. This paper will take a look at running drivers in user space, trying to answer the questions in what degreethe driver can run in user space and what can be gained from this?

Linux设备驱动通常运行在内核空间，但是也可以运行在用户空间。本文将介绍运行在用户空间中的设备驱动程序，试图回答以下两个问题:驱动程序在用户空间中运行的程度，以及从中获得的好处。

In the ‘90s, user-space drivers in Linux were much about how
to make graphics run faster[1] by avoiding calling the kernel.
These drivers where commonly used by the X-windows server.

User-space driver has become ever more important, as a blog
post by Tedd Hoff[2] illustrates. In his case the kernel is seen as
the problem when trying to achieve high server connection capacity.

Network interface hardware companies like Intel, Texas Instruments
and Freescale have picked up on this and are now providing
software solutions for user-space drivers supporting their hardware.

在上世纪90年代，在Linux中的用户空间驱动程序集中于如何使图形运行得更快，通过避免内核调用。这些驱动程序通常在X-windows服务器上使用。用户空间驱动程序变得越来越重要, 在Tedd Hoff发表的博客中有所论述。在他论述的例子中，内核被认为是问题之所在，当试图提供高并发连接服务器能力(注：c10k问题)的时候。诸如英特尔、德州仪器公司和飞思卡尔这样的网络接口硬件公司已经开始研究这一问题，现在他们正在为支持他们的硬件的用户空间驱动程序提供软件解决方案。

1. Problems with kernel-space drivers 内核空间驱动程序存在的问题

Device drivers normally run in kernel space, since handling
interrupts and mapping hardware resources require privileges
that only the kernel space is allowed to have. However, it is not
without drawbacks.

设备驱动程序通常在内核空间中运行，因为中断处理和硬件资源映射需要特权，对应的特权只有内核空间才允许拥有。然而，它也并非没有缺点。

1.1 System call overhead 系统调用的开销

Each call to the kernel must perform a switch from user mode
to supervisor mode, and then back again. This takes time, which can
become a performance bottleneck if the calls are frequent.
Furthermore, the overhead is very much non-predictable, which
has a negative performance impact on real-time applications.

对内核的每一个调用必须从用户模式切换到超级管理(内核)模式，然后再返回。这显然需要时间，如果调用频繁的话，就会成为性能瓶颈。此外，开销很大程度上是不可预测的，这对实时应用程序将产生负面的性能影响。

1.2 Steep learning curve 学习曲线陡峭

The kernel-space API is different. For example, malloc() needs
to be replaced by one of the several types of memory allocations
that the kernel can offer, such as kmalloc(), vmalloc(), alloc_pages()
or get_zeroed_page(). There is a lot to learn before becoming
productive.

跟用户空间API相比，内核空间API有所不同。例如，如取代malloc()的话，内核就提供了几种不同类型的内存分配API，比如kmalloc(), vmalloc(), alloc_pages()或get_zeroed_page()。想在内核编程方面卓有成效，需要学习的东西很多。

1.3 Interface stability 接口稳定性

The kernel-space API is less stable than user-space APIs, making
maintenance a challenge.

与用户空间的API比较而言, 内核空间API更不稳定，这无疑给代码维护带来了很大的挑战。

1.4 Harder to debug 调试更困难

Debugging is very different in kernel space. Some tools often
used by user-space applications can be used for the kernel.
However, they represent exceptions rather than rule, where
LTTNG[3] is an example of the exception. To compensate for
this, the kernel has a lot of debug, tracing and profiling code
that can be enabled at compile time.

在内核空间中，调试有所不同，而且非常不同于用户空间调试。在用户空间应用程序调试中经常使用的一些工具可以用于内核调试。然而，他们代表着异常而非常态, 例如LTTNG[3]就是一个例外。为了弥补这一点，内核存在着许多调试、跟踪和分析代码，这些代码可以在编译的时候被启用。

1.5 Bugs more fatal 错误更加致命

A crashing or misbehaving kernel tends to have a more severe
impact on the system than a crashing or misbehaving application,
which can affect robustness as well as how easy it is to debug.

内核崩溃或行为不正确对系统的影响比应用程序崩溃或不正确对系统的影响更大，这影响到系统的健壮性以及调试的容易程度。

1.6 Restrictive language choice 编程语言选择严格受限

The kernel space is a very different programming environment
than user space. It is more restricted, for example only C language
is supported. This rules out any script based prototyping.

内核空间与用户空间的编程环境非常不一样。它受到的限制更多，例如只支持C语言。这就将任何基于脚本的原型设计排除在外了。

2. User-space drivers 用户空间驱动

If there are so many problems with having device drivers in
kernel space, is it time to have all drivers in user space instead?
As always, everything has its drawbacks, user-space drivers are
no exception.

Most of the issues with kernel-space drivers are solved by having
the driver in user space, but the issue with interface stability is
only true for very simple user-space drivers.

For more advanced user-space drivers, many of the interfaces
available for kernel-space drivers need to be re-implemented
for user-space drivers. This means that interface stability will still
be an issue.

既然在内核空间中的设备驱动程序存在着很多问题，那么是否应该将所有驱动程序都放在用户空间中呢？一如既往地，任何解决方案都有缺点，用户空间驱动程序也不例外。内核空间驱动程序存在的大部分问题都可以通过用户空间驱动程序给解决掉，但接口稳定性的问题是只适用于那些很简单的用户空间驱动程序。对于更高级的用户空间设备驱动，许多在内核空间才可用的接口需要为用户空间驱动重新实现一下，这意味着接口的稳定性仍然是一个问题。

3. Challenges with user-space drivers 用户空间设备驱动面临的挑战

There is a fear in the Linux kernel community that user-space
drivers are used as a tool to avoid the kernel‘s GPLv2 license.
This would undermine the idea with free open source software
ideas that GPLv2 has. However, this is outside the scope of
this paper.

在Linux内核社区，有这样一个恐惧，那就是用户空间驱动程序被当做一个工具来避免了内核GPLv2许可。这无疑将破坏GPLv2一贯主张的开源软件理念。然而，这一点超出了本文讨论的范围。

Apart from this there are technical challenges for user-space
drivers.

除此之外，用户空间设备驱动还存在技术上的诸多挑战。

3.1 Interrupt handling 中断处理

Without question, interrupt handling is the biggest challenge
for a user-space driver. The function handling an interrupt is
called in privileged execution mode, often called supervisor
mode. User-space drivers have no permission to execute in
privileged execution mode, making it impossible for user-space
drivers to implement an interrupt handler.

毫无疑问，中断处理是用户空间设备驱动面临的最大的挑战。中断处理函数在特权执行模式(又叫做超级管理模式)下才能被调用。用户空间驱动程序不允许在特权模式下执行，这使得在用户空间驱动里实现一个中断处理程序是不可能的。

There are two ways to deal with this problem: Either you do not
use interrupts, which means that you have to poll instead.
Or have a small kernel-space driver handling only the interrupt.
In the latter case you can inform the user-space driver of an
interrupt either by a blocking call, which unblocks when
an interrupt occurs, or using POSIX signal to preempt the
user-space driver.

解决这个问题有两种办法：要么不使用中断，要么有一个内核空间的驱动来专门处理中断。在前一种办法中，不使用中断意味着必须使用轮询。在后一种办法中，你可以通过阻塞调用来通知用户空间驱动程序，在中断发生时打开阻塞调用，或者使用POSIX信号来抢占用户空间驱动。

Polling is beneficial if interrupts are frequent, since there is
considerable overhead associated with each interrupt, due to
the switch from user mode to supervisor mode and back that
it causes. Each poll attempt on the other hand is usually only
a check for a value on a specific memory address.

如果中断频繁发生的话，那么轮询就是有益的，因为每次中断都有相当大的开销，这些开销来源于从用户模式切换到内核模式，然后再从内核模式返回到用户模式。另一方面，每一次轮询通常只是对位于特定内存地址的值进行检查而已(，所以轮询有好处，能减少系统开销)。

When interrupts become scarcer, polling will instead do a lot
of work just to determine that there was no work to do. This is
bad for power saving.

当中断变得稀少时，轮询将会做大量的工作来确定没有什么工作可以做，这不利于节省能源消耗。

To get power saving when using user-space drivers with polling,
you can change the CPU clock frequency, or the number of
CPUs used, depending on work load. Both alternatives will
introduce ramp-up latency when there is a work load spike.

在用户空间驱动程序使用轮询的时候，如果要省电的话，可以根据工作负载来修改CPU的时钟频率，或者更改在用的CPU的个数。当遇到工作负载峰值的时候，这两种方法都将引入急剧的延迟。

3.2 DMA 直接内存访问

Many drivers use hardware dedicated to copying memory
areas managed by the CPU to or from memory areas managed
by hardware devices. Such dedicated hardware is called direct
memory access, or DMA. DMA relieves the CPU of such
memory copying.

许多驱动程序使用专门的硬件来做内存拷贝，从CPU管理的内存区域到硬件管理的内存区域，或相反。这种专门的硬件叫做DMA(直接内存访问)。有了DMA，CPU得以从繁重的内存拷贝工作中解放出来。

There are some restrictions on the memory area used for
DMA. These restrictions are unique for each DMA device.
Common restrictions are that only a certain physical memory
range can be used, and that the physical memory range must be
consecutive.

给DMA使用的内存区域存在着一些限制。这些限制对于每一个DMA设备来说都是独一无二的。通常的限制是只能使用一定的物理内存范围，而且物理内存范围必须是连续的。

Allocating memory that can be used for DMA transfers is
non-trivial for user-space drivers. However, since DMA
memory can be reused, you only need to allocate a pool of
memory to be used for DMA transfers at start-up. This means
that the kernel could help with providing such memory when
the user-space driver starts, but after that no further kernel
interactions would be needed.

分配可用于DMA传输的内存，对于用户空间驱动程序来说是十分重要的。然而，由于用于DMA传输的内存是可以重用的，所以只需要分配一个内存池，以便在DMA传输启动时被使用。这就意味着，当用户空间驱动程序启动时，内核空间可以提供这样一段内存，但是在那之后，不再需要进一步的内核交互。

3.3 Device interdependencies

Devices are often structured in a hierarchy. For example the
clock might be propagated in a tree-like fashion using different
dividers for different devices and offer the possibility to power
off the clock signal to save power.

XXX

There can be devices acting as a bridge, for example a PCI host
bridge. In this case you need to setup the bridge in order to
have access to any device connected on the other side of
the bridge.

XXX

In kernel space there are frameworks helping a device driver
programmer to solve these problems, but those frameworks
are not available in user space.

XXX

Since it is usually only the startup and shutdown phases that
affect other devices, the device interdependencies can be
solved by a kernel-space driver, while the user-space driver
can handle the actual operation of the device.

XXX

3.4 Kernel services

Network device drivers normally interfaces the kernel network
stack, just like block device drivers normally interfaces the kernel
file system framework.

XXX

User-space drivers have no direct access to such kernel services,
and must re-implement them.

XXX

3.5 Client interface

The kernel has mechanisms for handling multiple clients
accessing the same resource, and for blocking threads waiting
for events or data from the device. These mechanisms are
available using standard interfaces like file descriptors, sockets,
or pipes.

XXX

To avoid using the kernel, the user-space driver needs to invent
its own interface.

XXX

4. Implementing user-space drivers | 用户态设备驱动实现

The picture above shows how a user-space driver might be
designed. The application interfaces the user-space part of the
driver. The user-space part handles the hardware, but uses its
kernel-space part for startup, shutdown, and receiving interrupts.

XXX

There are several frameworks and software solutions available
to help designing a user-space driver.

XXX

4.1 UIO

There is a framework in the kernel called UIO [5][4] which facilitate
writing a kernel-space part of the user-space driver. UIO has
mechanisms for providing memory mapped I/O accessible for
the user-space part of the driver.

XXX

The allocated memory regions are presented using a device
file, typically called /dev/uioX, where X is a sequence number
for the device. The user-space part will then open the file and
perform mmap() on it. After that, the user-space part has direct
access to its device.

XXX

By reading from the same file being opened for mmap(), the
user-space part will block until an interrupt occurs. The content
read will be the number of interrupts that has occurred. You can
use select() on the opened file to wait for other events as well.

XXX

For user-space network drivers there are specialized solutions
specific for certain hardware.

4.2 DPDK

Data Plane Development Kit, DPDK[6], is a solution from Intel
for user-space network drivers using Intel (x86) hardware. DPDK
defines an execution environment which contains user-space
network drivers. This execution environment defines a thread
for each CPU, called lcore in DPDK. For maximum throughput
you should not have any other thread running on that CPU.

XXX

While this package of libraries focuses on forwarding applications,
you can implement server applications as well. For server DPDK
applications you need to implement your own network stack
and accept a DPDK specific interface for accessing the network.

XXX

Much effort has been put in memory handling, since this is often
critical for reaching the best possible performance. There are
special allocation and deallocation functions that try to minimize
TLB[10] misses, use the most local memory for NUMA[11]
systems and ensure even spread on multi-channel memory
architectures [12]. 

XXX

4.3 USDPAA

User-space Data Plane Acceleration Architecture, USDPAA[7] , is
a solution from Freescale for the same use case as DPDK but
designed for their QorIQ architecture (PowerPC and ARM.
The big difference is that QorIQ uses hardware for allocating,
de-allocating and queuing network packet buffers. This makes
memory management easier for the application.

XXX

4.4 TransportNetLib

TransportNetLib[8] is a solution from Texas Instruments. It
is similar to USDPAA but for the Keystone architecture (ARM).

XXX

4.5 Open DataPlane

Open DataPlane, ODP[9], is a solution initiated by Linaro to do
the same as DPDK, USDPAA and TransportNetLib, but with
vendor generic interfaces.

4.6 Trying out DPDK

To get the feeling for the potential performance gain from having
a user mode network device driver, a DPDK benchmark application
was designed and executed.

XXX

The design of the application can be seen in the picture above.
It executes as four instances each running on its own CPU, or
lcore, as DPDK calls them.

XXX

Each instance is dedicated to its own Ethernet device sending
and receiving network packets. The packets sent has a magic
word used for validating the packets and a timestamp used for
measuring transport latency.

XXX

The instances are then paired using loopback cables. To be able
to compare user-space driver with kernel-space driver, one
pair accesses the hardware directly using the driver available in
DPDK, and the other pair uses the pcap[13] interface. All four
Ethernet devices are on the same PCI network card.

XXXX

There is a fifth lcore (not shown in the picture above) which
periodically collects statistics and displays it to the screen.

XXX

The hardware used was as follows:
  o Supermicro A1SAi-2750F mother board using Intel Atom
    C2750 CPU.  This CPU has 8 cores with no hyperthreading.
  o 16GB of memory.
  o Intel Ethernet server adapter i350-T4, 1000 Mbps.

XXX

The table below shows the throughput and latency for user-space
driver compared to kernel-space driver.

XXX

A graph showing the throughput:

XXX

A graph showing the latency:

XXX

The theoretical throughput maximum is the sum of the send
and receives speed for the network interface. In this case this
is 1000 Mbps in each direction, giving a theoretical maximum
of 2000 Mbps. The throughput includes packet headers and
padding.

XXX

User-space driver achieved a throughput boost of about four
times over kernel-space driver.

XXX

Latency was calculated by comparing the timestamp value found
in the network packet with the current clock when packet was
received. The latency for user-space driver was slightly less than
for kernel-space driver.

XXX

Four threads, each continuously running netperf TCP streaming
test against loop-back interface, were used as a stress while
running the DPDK benchmark application. This had no noticeable
impact on the measurements.

XXX

5. Conclusion | 总结陈词

Implementing a user-space driver requires some work
and knowledge. The major challenges are interrupts versus
polling, power management and designing interface towards
driver clients.

XXX

Support for user-space network drivers is a lot more developed
than for other kinds of user-space drivers, especially for doing
data plane forwarding type of applications.

XXXX

A user-space driver can do everything a kernel-space driver
can, except for implementing an interrupt handler.

XXX

Comparing a user-space network driver with a kernel-space
network driver showed about four times better throughput
for the user space driver. Latency did not show a significant
difference.

XXX

The real-time characteristics should be good for user-space
drivers since they do not invoke the kernel. This was not verified
in this paper, though.

XXX