一起读经典 · Linux 内核网络(3):门牌之下——net_device 与设备子系统

本文是「一起读经典 · Linux 内核网络」系列第 3 篇。承接上一篇的"水"(sk_buff),本篇讲"管道"(net_device):内核如何把物理网卡、回环、桥、隧道、veth 一视同仁;netdev_ops 虚函数表如何在 C 语言里模拟 OOP;通知链如何把"网卡上下线"广播给协议栈每个角落;以及 6.x 内核对引用计数与命名空间所做的几次关键改造。

版本契约:本文以 Linux 6.6 LTS / 6.12 Stable 为基准。凡涉及"经典视角"(Benvenuti 一书、2.6 内核)与"现代实现"有出入处,文中显式标注,文末给出版本契约对照表。

一、一个真实问题:ip link set eth0 up 之后到底发生了什么?

你敲一行命令:

sudo ip link set eth0 up

回车后,屏幕上没有输出。但内核里发生了几十件事:

• 驱动的 ndo_open 被调用,分配 RX/TX ring、申请中断、启动 NAPI。
• __LINK_STATE_START 位被置上,IFF_UP 标志拉高,qdisc 被激活(dev_activate)。
• 通知链广播 NETDEV_UP 事件:IPv4 子系统启用这个接口的 IP 配置;IPv6 子系统开始生成 link-local 地址,发 RS 等待 RA。
• 如果 eth0 之前被加进了某个 bridge,bridge 推进它的端口状态机。
• rtnetlink 把 RTM_NEWLINK 消息多播给用户态——另一个终端里开着的 ip monitor link 会立刻打出一行。
• linkwatch 开始盯 PHY 的 carrier;等链路真的起来,再广播一次 NETDEV_CHANGE。

这一切的指挥中心,就是 struct net_device。如果你把内核网络栈想象成一座大楼,net_device 就是大楼里每个"网络接口"的统一门牌。你递快递(sk_buff)给某个部门时,只认门牌——不管门后是物理网卡、虚拟网卡、桥、还是回环。

本篇剖析这块门牌的内部结构。

二、本篇坐标:你在哪张地图上

net_device 同时横跨三张地图:

• 数据面:ndo_start_xmit(发送入口)、NAPI poll(接收驱动)、netdev_ops 全套虚函数。
• 控制面:register_netdev / unregister_netdev 生命周期、通知链广播、ip link 的 Netlink 消息落点。
• 性能面:per-CPU 引用计数(pcpu_refcnt)、多队列(real_num_rx_queues / real_num_tx_queues)、napi_list 上挂的多个 NAPI 实例、qdisc 与 TX ring 的边界。

第 02 篇说 sk_buff 是"三张地图的交汇点";net_device 则是三张地图共用的"地基"——水要流,先得有管道。

三、统一抽象:eth0、lo、br0、veth0、tun0 都是同一个东西

打开你的机器:

$ ip link show | awk -F': ' '/^[0-9]+/ {print $2}'
lo
eth0
docker0
veth1a2b@if5
br-cni
tun0
wlan0

每一行都是一个 net_device。内核眼里它们是平等的——发包时调用同一套接口、注销时走同一套路径、状态变化时进同一个通知链。

这是一个反直觉的设计:物理网卡是真实硬件,有 PCIe、MSI-X、DMA、PHY chip;回环 lo 是一段纯软件;桥 br0 是一组端口的逻辑聚合;veth 是一对软件管道;tun/tap 是连到用户态进程的管道。它们的"物理形态"差异巨大,但都实现同一个虚函数表:

struct net_device_ops {
int  (*ndo_init)(struct net_device *dev);
void (*ndo_uninit)(struct net_device *dev);
int  (*ndo_open)(struct net_device *dev);
int  (*ndo_stop)(struct net_device *dev);
netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev);
/* ... 几十个其他回调,大部分都有合理默认 ... */
};

协议栈把 skb 交给 dev_queue_xmit(skb)(出口设备就是 skb->dev)时,根本不知道这个 dev 是真硬件还是软件桥——它最终只看 dev->netdev_ops->ndo_start_xmit 这个函数指针。

类比:公司内部邮件系统。你发邮件,只看收件人和部门门牌;邮件中心不关心市场部办公室在哪一层、用什么打印机。Linux 协议栈对待 net_device,跟邮件中心对待门牌一样:只认接口,不认实体。

这就是为什么:

• lo 上 ping 通 = 协议栈本身没问题
• docker0 是个桥,你能给它配 IP、抓包、加 iptables 规则,跟物理网卡一样
• veth pair 一端在容器里、一端在宿主机,容器进程发包跟用物理网卡发包没两样

四、核心字段:第一次只看 8 个

struct net_device 在 6.6 内核上有 200+ 字段(include/linux/netdevice.h),全看会被淹死。第一次只认这 8 个:

错误纠正:老资料(2.6.24 之前)里,poll 函数和轮询配额是直接长在 net_device 上的(dev->poll、dev->quota、dev->poll_list)——那个年代"设备本身就是 NAPI 实体"。这个模型早已不成立:现代多队列网卡每个 RX/TX queue pair 有自己的 NAPI 实例,通常嵌入在驱动的私有结构(如 igb_q_vector 或 mlx5e_channel)里,通过 netif_napi_add() 注册到 dev->napi_list 链表。net_device 自己不持有任何 napi_struct,只持有一个链表头。

4.1 name 的小陷阱

name 不是单纯字符串,内核按 netns 维护命名表。name 重复(在同一 netns 内)会导致 register_netdev 失败。ip link set eth0 name net0 通过 Netlink RTM_SETLINK 改 name 字段并触发 NETDEV_CHANGENAME 通知。顺带一个版本细节:老内核要求接口先 down 才能改名,6.2 起允许在 up 状态下直接改。

4.2 state 是位图,而 ip link 的输出是"两套状态"

enum {
    __LINK_STATE_START,        /* 管理 up(ip link set up) */
    __LINK_STATE_PRESENT,
    __LINK_STATE_NOCARRIER,    /* 物理 down(网线没插) */
    __LINK_STATE_LINKWATCH_PENDING,
    __LINK_STATE_DORMANT,
    __LINK_STATE_TESTING,
};

ip link show 一行输出里其实有两套状态,初学者最容易混:

• 尖括号里的 flags:<NO-CARRIER,BROADCAST,MULTICAST,UP>。其中 UP 对应管理 up(IFF_UP / __LINK_STATE_START),NO-CARRIER 对应 __LINK_STATE_NOCARRIER(物理层没起)。
• state XXX:这是 RFC 2863 定义的 operstate("业务可用性"),由内核 linkwatch 根据 carrier / dormant 推算出来。管理 up + 有 carrier → state UP;管理 up + 无 carrier → 物理设备显示 state DOWN(同时 flags 里出现 NO-CARRIER);只有堆叠设备(VLAN、某些 bond/上层设备,特征是 iflink != ifindex)在下层挂掉时才显示 LOWERLAYERDOWN。

这就是为什么 ip link set eth0 up 之后你可能看到 <NO-CARRIER,BROADCAST,MULTICAST,UP> state DOWN——UP 和 DOWN 同时出现在一行里不是 bug,是两套状态各说各话:管理位已经拉高,物理 carrier 还没起。

五、netdev_ops:C 语言怎么模拟 OOP

net_device_ops 是一张函数指针表。每个驱动初始化时,填一份自己的实现:

/* drivers/net/ethernet/intel/igb/igb_main.c 的概念化裁剪 */
static const struct net_device_ops igb_netdev_ops = {
    .ndo_open               = igb_open,
    .ndo_stop               = igb_close,
    .ndo_start_xmit         = igb_xmit_frame,
    .ndo_set_rx_mode        = igb_set_rx_mode,
    .ndo_set_mac_address    = igb_set_mac,
    .ndo_change_mtu         = igb_change_mtu,
    .ndo_tx_timeout         = igb_tx_timeout,
    .ndo_validate_addr      = eth_validate_addr,
    .ndo_get_stats64        = igb_get_stats64,
/* ... */
};

然后:

netdev->netdev_ops = &igb_netdev_ops;

协议栈调用 dev->netdev_ops->ndo_start_xmit(skb, dev) 时,实际进入 igb_xmit_frame。换一张 Mellanox 卡,这条指针指向 mlx5e_xmit。同一段 dev_queue_xmit 代码,跑遍所有网卡——这就是 C 模拟 OOP。

5.1 ndo_start_xmit 的反直觉点

驱动 ndo_start_xmit返回 NETDEV_TX_OK 不等于"包已发到网线"。它只表示"驱动接收了 sk_buff,放进了 TX descriptor ring"。真正的发送完成,通过两条路径之一汇报:

1. TX 完成中断(老式)
2. NAPI poll 中的 TX 清理逻辑(现代)

这里要破一个老说法:老资料里讲驱动有个标准回调叫 tx_clean,内核 NAPI 框架会调它。没有这个标准回调。驱动通常在自己的 NAPI poll 函数里先清理 TX 完成描述符,再 RX poll——这是驱动内部的逻辑组织,不是 net_device_ops 的标准接口。

清理 TX 完成的概念化代码:

static int igb_poll(struct napi_struct *napi, int budget)
{
struct igb_q_vector *q_vector = container_of(napi, ...);
bool clean_complete = true;
int work_done = 0;

/* 先清 TX 完成描述符 */
if (q_vector->tx.ring)
        clean_complete = igb_clean_tx_irq(q_vector, budget);

/* 再做 RX 收包 */
if (q_vector->rx.ring) {
        work_done = igb_clean_rx_irq(q_vector, budget);
if (work_done >= budget)
            clean_complete = false;
    }

if (!clean_complete)
return budget;                    /* 活没干完,留在 poll 列表里 */
if (likely(napi_complete_done(napi, work_done)))
        igb_ring_irq_enable(q_vector);    /* 干完了,重新开中断 */
return work_done;
}

清理 TX 时,驱动对每个已完成的描述符调用 napi_consume_skb()(NAPI 上下文的批量释放版本)释放 sk_buff——到这一步,02 篇讲的 users / dataref 两层引用计数才真正开始递减(TCP 重传队列里的 clone 还握着数据区,所以释放的可能只是"驱动这一份")。"sk_buff 什么时候真的可以释放",最终答案不在协议栈,而在驱动的 TX 清理里。

六、qdisc:发送侧的"队列入口"

协议栈发包路径里:

dev_queue_xmit(skb)                            // 出口设备 = skb->dev
   → __dev_queue_xmit
       → txq = netdev_core_pick_tx(dev, skb, ...)  // 先选 TX 队列(XPS/hash,08 篇)
       → q = rcu_dereference_bh(txq->qdisc)        // 取这个队列的 qdisc
       → __dev_xmit_skb:q->enqueue() 入队
                         __qdisc_run() 出队 → ndo_start_xmit

注意一个容易翻车的细节:真正入队、出队的是每个 TX 队列自己的 txq->qdisc,不是 dev->qdisc。dev->qdisc 字段存的是给 tc 展示的 root(多队列设备上就是 mq),而 mq 本身不排一个包——它只是把每个硬件队列下面的子 qdisc 组织起来。

6.1 默认 qdisc 的现代真相

很多老教材会写"Linux 默认队列规则是 pfifo_fast"。这在 4.12 之后已不准确,但要说准,得先回答 01 篇那个条件反射式的问题:是哪一种默认?

• 内核默认:4.12 起,Kconfig(CONFIG_DEFAULT_NET_SCH)的默认值从 pfifo_fast 换成 fq_codel(理由:对抗 bufferbloat)。
• 发行版默认:不少发行版在内核切换之前就已通过 systemd 的 sysctl 把 net.core.default_qdisc 设成了 fq_codel。
• 设备类型:多队列设备(real_num_tx_queues > 1)的根 qdisc 是 mq,mq 底下每个硬件 TX 队列各挂一个 fq_codel;而 lo、veth、bridge 这些虚拟设备默认是 noqueue——不排队,出队逻辑直接同步调用 dev_hard_start_xmit。

所以你在容器里 tc qdisc show dev eth0 看到 fq_codel,tc qdisc show dev lo 看到 noqueue——不是配置错了,是设计如此。现代调度器(fq、fq_codel、cake)还与 BQL(Byte Queue Limits)、TSQ(TCP Small Queues)协同工作,这些留到发送路径专题再展开。

观察当前 qdisc:

tc qdisc show dev eth0
# 多队列网卡上常见:
# qdisc mq 0: root
# qdisc fq_codel 0: parent :1 limit 10240p flows 1024 ...
# qdisc fq_codel 0: parent :2 ...

6.2 qdisc 与 TX ring 的边界

很多人把 qdisc 与 hardware TX ring 混为一谈。它们是两层:

• qdisc 是内核的软件队列(可被 tc 配置),负责调度/限速/分类。ip link 里的 qlen 是 tx_queue_len,它是 pfifo_fast、pfifo 这类 qdisc 取队列深度的默认值;fq_codel 有自己的 limit(上面输出里的 10240p),并不吃 tx_queue_len。
• TX ring 是网卡硬件的 DMA 描述符环,由驱动管理,深度用 ethtool -g eth0 查看/设置。

包从 qdisc 出队后,通过 ndo_start_xmit 才进入 TX ring。两层各有"满"法:qdisc 满了按自己的策略丢(尾丢或主动队列管理);TX ring 满了则让 qdisc 暂停出队(netif_tx_stop_queue),等驱动 NAPI poll 清出空位后(netif_tx_wake_queue)继续——丢包和背压,发生在不同的层。

七、通知链:松耦合的"网卡广播"

网卡上下线、地址变更、MTU 变更,需要让 IPv4、IPv6、bridge、bonding、路由、NAT 全部知道。Linux 用通知链实现这种广播,避免每个子系统都把自己的逻辑 hook 进 register_netdev 函数体。

7.1 注册一个监听者

static struct notifier_block my_notifier = {
    .notifier_call = my_event_handler,
};

register_netdevice_notifier(&my_notifier);

my_event_handler 会收到所有 NETDEV_* 事件:

/* include/linux/netdevice.h(6.x,节选) */
enum netdev_cmd {
    NETDEV_UP = 1,        /* 设备已 up */
    NETDEV_DOWN,
    NETDEV_REBOOT,
    NETDEV_CHANGE,        /* 状态变化,如 carrier on/off */
    NETDEV_REGISTER,
    NETDEV_UNREGISTER,
    NETDEV_CHANGEMTU,
    NETDEV_CHANGEADDR,
    NETDEV_PRE_CHANGEADDR,
    NETDEV_GOING_DOWN,
    NETDEV_CHANGENAME,
/* ... */
    NETDEV_PRE_UP,
/* ... */
};