系统与数据库2018net.in.tum.de
用 Rust 编写网络驱动
Writing Network Drivers in Rust
专业 · 约 120 分钟读完前置知识：操作系统基础、网络驱动与 DMA、Rust 基础
导读
这篇论文（2018 年 TUM 学位论文，属于 ixy-languages 项目）研究能否用 Rust 编写用户态网络驱动：作者为绕过内核的用户态驱动框架 ixy 实现了 Rust 版本，用 mlock 加 2 MiB 大页把 DMA 内存固定在物理内存中，并从安全性、可维护性和性能等方面与 C 版本对比，结论是 Rust 很适合写网络驱动。
HN 关注点：Rust 能否胜任驱动这类底层系统编程，讨论焦点包括 Google Fuchsia 的采用、用户态 DMA 内存固定方式的隐患，以及 Rust+XDP/eBPF 的实战性能。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
支持Google 在 Fuchsia 中用 Rust 做网络开发，佐证 Rust 适合高性能系统编程。
根据 Joshua Liebow-Feeser 在 Rust Belt Rust 2018 大会上的演讲，Google 在其新的 Fuchsia 操作系统中大量使用 Rust 做网络开发。以下是他演讲中一段话的大致引用：“Rust 的不同之处不在于你能用它写出高性能的裸机代码——人们一直用 C 和 C++ 做这件事。Rust 的不同之处在于，当你写这样的代码时，它是安全、整洁、易用的，而且你对它的正确性有信心。”如果连 Google 都在用 Rust 做性能关键的开发，那在我看来相当有前景。
dswalter查看英文原文
Per a talk from Joshua Liebow-Feeser at the Rust Belt Rust 2018 conference, Google is heavily using Rust for networking in their new Fuchsia operating system. This is a rough approximation of a quote he gave during the talk: "What makes Rust different is not that you can write high-performance, bare-metal code. People use C and C++ to do that all the time. What makes Rust different is that when you write that code, it is safe, clean, and easy to use, and you are confident in its correctness." If even Google is using Rust for performance-critical development, that seems pretty promising to me.
质疑用户态固定 DMA 内存的做法依赖“大页不可迁移”这一内核实现细节，存在隐患。
我以前写过设备驱动，所以首先想知道他如何在用户空间分配一块固定的物理内存……论文里说：“在内核空间有分配 DMA 内存的 API，用户空间用不了，只能用别的机制。为了禁止换页，可以用 mlock(2)。……然而 mlock(2) 只保证页面留在内存中，内核仍可能把页面移到不同的物理地址。为规避这个问题，我们使用 2 MiB 的大页。Linux 内核目前还无法迁移这类页面，因此它们会常驻物理内存。”他并没有真正解决这个问题，而是依赖一个未来可能改变的内核实现细节（同时还依赖大页背后的物理内存落在网卡 DMA 能访问到的区域——在 x86 上只要没启用内存加密，这通常成立）。
cesarb查看英文原文
Having written device drivers before, the first thing I wondered was how he allocated a fixed region of physical memory in user space... "In kernel space there is an API to allocate DMA memory, in user space we have to use other mechanisms since this API is not available here. To disable swapping, we can use mlock(2). [...] However, mlock(2) only ensures that the page is kept in memory. The kernel is still able to move pages to different physical addresses. To circumvent this problem, we use huge pages with a size of 2 MiB. These pages cannot be migrated yet by the Linux kernel, thus stay resident in physical memory." He didn't, he's depending on an implementation quirk which might change in the future (and also depending on the physical memory backing huge pages being in a region which can be reached by the network device through DMA, though that's probably always true on x86 when memory encryption is not in use).
亲历亲历：Rust 配合 XDP/eBPF 做网络驱动性能优于 DPDK，Rust 很适合底层开发。
这非常酷。我一直在用 Rust 管理一个基于 XDP 的网络驱动，它比 C 的 socket API 快得多得多，也比 DPDK 略快。这里其实没有传统意义上的驱动，Rust 充当控制面和 eBPF 注入器，XDP 程序通过 eBPF map 与 Rust 通信。我极度看好 Rust，能用可维护的现代代码做底层任务是种清新的体验。我转 Rust 之前做了近十年 C/C++ 开发者，Rust 确实兑现了它的承诺。另外 Rust 使用 LLVM，对写 eBPF 程序是巨大的优势。
ilovecaching查看英文原文
This is very cool. I’ve been working on using Rust to manage an XDP based network driver that is much, much, much faster than the socket API in C, and slightly faster than DPDK. There’s no driver in the traditional sense, Rust works as a control plane and eBPF injector, while the XDP programs communicate back to Rust through eBPF maps. I’m extremely bullish on Rust, it’s such a breath of fresh air to be able to write maintainable, modern code to do low level tasks. I was a C/C++ dev for a little under a decade before switching to Rust and it really delivers on its promises. Also Rust using llvm is a huge boon to writing eBPF programs.
补充引用论文结论并补充了可运行的代码仓库链接。
原文（论文）写道：“根据我们的发现可以得出结论，Rust 非常适合编写网络驱动。它不仅是快速且安全的系统编程语言，还连续在 2016、2017、2018 年被评为最受喜爱的编程语言。用 Rust 写更多驱动无疑会带来更安全、更可靠的计算机系统。”他们代码的可用链接：https://github.com/ixy-languages/ixy.rs
delta1查看英文原文
FTA "Based on our findings we can conclude that Rust is a very well-suited programming language for writing network drivers. It is not only a fast and safe systems programming language but was also voted most beloved programming language in 2016, 2017 and 2018 [15, 16, 17]. Writing more drivers in Rust would certainly lead to safer and more reliable computer systems." Working link to their code: https://github.com/ixy-languages/ixy.rs
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2018Hacker News 讨论帖364 分 · 123 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选