Posts

Writing An Interpreter In Rust (1): 开个头 最近在读 Writing An Interpreter In Go。 书本身挺有意思的，它带着你一步一步写一个叫 Monkey 的小语言。 我边看边想：既然我现在正在学 Rust，那干脆用 Rust 来实现一遍吧，当作练习。 于是就有了这个项目： 👉 GitHub: rand0m42195/monkey-rs 为什么做这个事 刚好最近在学rust，像用rust找点事情干； 解释器一直是我感兴趣的话题，但之前只是零散看过点原理； 用一个小项目把 Rust 和解释器放在一起，会有意思。 关于 Monkey 语言 Monkey 是书里的示例语言。它很小，但该有的都有： let 绑定 表达式运算 条件分支 函数（而且是一等公民，可以闭包） 后面还有数组、哈希，甚至宏 举个简单例子： let add = fn(a, b) { a + b; }; add(2, 3); // => 5 我打算做什么 我的目标就是：用 Rust 写出一个能跑的 Monkey 解释器，最后能在 REPL 里玩一玩： >> let a = 10; >> let b = 20; >> a + b; 30 解释器的基本流程大概是这样： ...

XDP挂载模式对比 了解XDP的读者应该知道：XDP是基于eBPF的一个高性能网络路径技术，它的原理就是在数据包处理的早期阶段（在内核网络协议栈之前）挂载eBPF程序对数据包进行处理，从而实现高效的网络数据包处理。如果你写过XDP程序，那么一定知道挂载XDP的时候有多种模式可选，不同模式之间的效率不同。这篇文章我们就来深入剖析一下XDP的集中模式之间到底有哪些区别。 首先看看XDP挂载模式有哪几种？不同的挂载模式有和区别？ XDP挂载模式可以以三种方式挂在到网卡上： Generic Native Offloaded 兼容性 兼容所有网络设备 需要网卡驱动显示支持XDP 特定的可编程网卡 执行阶段 在网络核心代码中执行（此时已经分配了SKB） 在网卡驱动中执行（还未分配SKB） 网卡执行，CPU零开销 性能 较低 高 最高 XDP 挂载原理 XDP程序是挂载在网络数据包的处理路径上的，所以我们有必要先对网络数据包的处理路径有一个整体的掌握（这里插播一条小广告，我之前写过一篇分析数据包从网卡到内核协议栈的博客）。 数据包从网卡到内核网络协议栈的流程可以分为以下几个步骤： 数据包到达网卡 网卡硬件接收以太帧，做基本校验（如 CRC）。 DMA 写入内存 网卡通过 DMA 将数据包写入驱动预先分配好的接收缓冲区（Descriptor Ring）。 中断通知 CPU 网卡通过 IRQ 告诉 CPU：“我收到了新数据包”。 驱动中断处理函数（ISR） 驱动快速处理中断，通常只是调用 __napi_schedule()，把 NAPI poll 加入调度队列。 软中断调度 NAPI poll CPU 执行 do_softirq() → net_rx_action() → 调用 网卡的的 poll 函数。 poll 函数提取数据包并构造 skb 驱动在 poll 中读取 DMA ring 的描述符，把数据包封装进 sk_buff 结构，交给网络核心层。 网络核心层处理 网络核心层根据数据包格式选择对应的协议栈，然后交给协议栈处理。 XDP就是挂载在上面的某个阶段，从而实现高效网络数据包处理的。具体来说Native模式的XDP是在网卡的驱动程序中执行的（对应步骤6），而Generic模式的XDP是在网络核心层中执行的（对应步骤7）。这也说明了Native模式的性能比Generic模式高。 ...

Linux 下多语言网络编程对比 还记得Linux网络编程姿势吗？如果不记得了，这里有一个用C语言写的tcp_echo服务，用这段代码能帮我们回忆Linux的网络编程套路： 调用socket创建一个网络套接字socket； 调用bind给socket绑定地址； listen设置 调用accept接收网络请求； #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> int main(void) { int sd = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = htons(12345), .sin_addr.s_addr = INADDR_ANY, }; bind(sd, (struct sockaddr*)&addr, sizeof(addr)); listen(sd, 5); while (1) { int client = accept(sd, NULL, NULL); char buf[1024]; ssize_t n; while ((n = recv(client, buf, sizeof(buf), 0)) > 0) { send(client, buf, n, 0); // 把读到的内容发送回去 } close(client); } close(sd); return 0; } 如果你用的是Go、Python、Rust等高级编程语言，可能会对这段代码嗤之以鼻，这么简单一个功能，要创建一个可以通信的TCP连接完全不必这么复杂。 这是用Go写的，如果不考虑错误处理，只需要调用Listen和Accept。 ...

引言 网络数据包从网卡到应用程序，需要经历一段复杂的旅程。作为开发者，我们平时调用 socket()、recv() 就能轻松拿到数据，却很少思考内核背后究竟发生了什么。 本系列文章尝试结合 理论流程 + 内核源码分析，逐步剖析 Linux 内核中网络数据包的接收过程。这里选择 Linux 4.4 内核作为例子（代码相对稳定，资料丰富，逻辑上没有过多新特性干扰），并结合 Intel e1000 驱动来具体展示数据包是如何从网卡到达内核网络协议栈的。 网络数据包接收的总体流程 先给出一个全局视角：数据包从网卡到达内存，再到协议栈的路径，大致如下： 数据包到达网卡 网卡硬件接收以太帧，做基本校验（如 CRC）。 DMA 写入内存 网卡通过 DMA 将数据包写入驱动预先分配好的接收缓冲区（Descriptor Ring）。 中断通知 CPU 网卡通过 IRQ 告诉 CPU：“我收到了新数据包”。 驱动中断处理函数（ISR） 驱动快速处理中断，通常只是调用 __napi_schedule()，把 NAPI poll 加入调度队列。 软中断调度 NAPI poll CPU 执行 do_softirq() → net_rx_action() → 调用 e1000 的 poll 函数。 poll 函数提取数据包并构造 skb 驱动在 poll 中读取 DMA ring 的描述符，把数据包封装进 sk_buff 结构，交给内核网络子系统。 网络核心层处理 skb 被送到网络核心层，核心层通过数据包的协议类型选择对应的网络协议栈，如IP协议栈，至此网络数据包从网卡到达了Linux内核的网络协议栈。 在开始具体分析之前，先说以下相关源码的位置。和网卡相关的代码在驱动目录下（/drivers/net/ethernet），由于我们分析的是Intel的e1000网卡，所以具体位置就是/drivers/net/ethernet/intel/e1000，内核网络协议栈位于网络子系统目录下/net，主要是/net/core/目录，我们主要分析IPv4，所以还会涉及/net/ipv4/中的少量代码。 接下来就以Intel e1000网卡为例，来一起探究网卡收包过程吧😀 ...

测试 这是第一篇博客！