4. IEEE 802.1p 优先级标记：用户优先级与流量类别映射、优先级队列调度基础
好，咱们今天聊聊 IEEE 802.1p。说实话，这个标准在车载以太网里太重要了。你想想看，一辆智能汽车里，有摄像头数据、有雷达点云、有控制指令、还有娱乐系统的视频流。这些数据挤在同一条网线上，谁先走谁后走？802.1p 就是干这个的。
我个人习惯把 802.1p 理解成「给数据包贴标签」。就像快递包裹上贴的「加急」标签一样。网桥和交换机看到这个标签，就知道该优先处理谁。
4.1 用户优先级：3 个比特的学问
802.1p 其实只是 IEEE 802.1Q 标准里的一小部分。它用了 VLAN 标签里的 3 个比特，来表示优先级。3 个比特能表示 0 到 7，一共 8 个优先级。
嗯，这里要注意：优先级 7 最高，优先级 0 最低。但有个坑——优先级 0 并不是「没有优先级」，而是默认的尽力而为等级。优先级 1 反而比 0 还低。我刚开始做项目时就被这个搞晕过。
| 优先级值 | 缩写 | 流量类型 | 典型应用 |
|---|---|---|---|
| 0 | BE | 尽力而为 | 默认数据、非关键信息 |
| 1 | BK | 背景流量 | 批量传输、日志上传 |
| 2 | EE | 优秀尽力 | 普通管理数据 |
| 3 | CA | 关键应用 | 诊断、配置消息 |
| 4 | VI | 视频 | 摄像头流、信息娱乐 |
| 5 | VO | 语音 | 紧急通话、音频 |
| 6 | IC | 网间控制 | 路由协议、网络管理 |
| 7 | NC | 网络控制 | 安全关键控制指令 |
我在项目中遇到过一个问题：某供应商把所有的诊断数据都标成了优先级 7。结果正常控制指令反而被堵住了。后来我们规定，只有真正的安全关键数据才能用 7，诊断数据最多用 3。说白了，优先级不是越高越好，得合理分配。
4.2 流量类别映射：从 8 到 8 再到更多
802.1p 定义了 8 个优先级，但实际硬件里，交换机或网卡不一定有 8 个独立的队列。有些只有 4 个，有些只有 2 个。这时候就需要做映射。
映射规则其实很简单：把多个优先级合并到一个流量类别里。比如优先级 0 和 1 都放到队列 0，优先级 2 和 3 放到队列 1，以此类推。
我建议你记住一个原则：关键控制类（优先级 6、7）必须独占一个队列。为什么呢？因为如果控制指令和视频流混在一起，万一视频流突然爆发，控制指令就被延迟了。这在车里是要出事的。
典型车载映射方案：
- 队列 0（最低）：优先级 0、1 — 背景数据、日志
- 队列 1：优先级 2、3 — 管理、诊断
- 队列 2：优先级 4、5 — 视频、音频
- 队列 3（最高）：优先级 6、7 — 控制指令、安全数据
你想想看，如果只有 4 个队列，这个映射方案基本够用了。但如果你用的是高端交换机，有 8 个队列，那就可以做得更精细。比如把视频和音频分开，把诊断和管理分开。
4.3 优先级队列调度基础：谁先走？
有了优先级标签，也有了队列映射，接下来就是调度问题了。调度器决定从哪个队列里取数据发送。常见的调度算法有几种，我挑最常用的两个说说。
4.3.1 严格优先级调度
这个最简单，也最暴力。高优先级的队列不空，低优先级的队列就别想走。就像 VIP 通道，VIP 一直有人，普通客户就永远等着。
我曾经在一个项目里踩过这个坑。我们把所有摄像头数据都标成了优先级 4，控制指令是优先级 7。按理说没问题。但摄像头数据量太大了，优先级 7 的队列偶尔也会空一下。结果呢？优先级 4 的摄像头数据趁机疯狂发送，把带宽占满了。等下一个控制指令来了，还得排队。
所以严格优先级调度有个致命问题：低优先级队列可能被饿死。在车载场景里，饿死意味着什么？意味着某个 ECU 的数据永远发不出去。
4.3.2 加权轮询调度
这个就公平多了。每个队列分配一个权重，比如队列 3 权重 50%，队列 2 权重 30%，队列 1 权重 15%，队列 0 权重 5%。调度器轮着来，每个队列按比例发送。
加权轮询的好处是：即使高优先级队列一直有数据，低优先级队列也能分到一点带宽。不会出现饿死的情况。
但缺点也很明显：高优先级数据的延迟可能变长。因为调度器不能一直服务高优先级队列，得停下来去服务低优先级的。
我的建议：
在车载以太网里，我一般推荐混合使用。控制指令类（优先级 6、7）用严格优先级调度，保证最低延迟。其他数据用加权轮询，保证公平性。很多商用交换芯片都支持这种混合模式。
4.4 实际配置示例
说了这么多理论，咱们看看实际怎么配。假设你用的是某个常见的车载交换芯片，配置 802.1p 优先级映射和调度策略，大概是这样：
// 伪代码示例：配置优先级映射
switch_config.priority_map[0] = QUEUE_0; // 优先级 0 -> 队列 0
switch_config.priority_map[1] = QUEUE_0; // 优先级 1 -> 队列 0
switch_config.priority_map[2] = QUEUE_1; // 优先级 2 -> 队列 1
switch_config.priority_map[3] = QUEUE_1; // 优先级 3 -> 队列 1
switch_config.priority_map[4] = QUEUE_2; // 优先级 4 -> 队列 2
switch_config.priority_map[5] = QUEUE_2; // 优先级 5 -> 队列 2
switch_config.priority_map[6] = QUEUE_3; // 优先级 6 -> 队列 3
switch_config.priority_map[7] = QUEUE_3; // 优先级 7 -> 队列 3
// 配置调度策略：队列 3 严格优先级，其他加权轮询
switch_config.sched_mode[3] = STRICT_PRIORITY;
switch_config.sched_mode[2] = WEIGHTED_ROUND_ROBIN;
switch_config.sched_mode[1] = WEIGHTED_ROUND_ROBIN;
switch_config.sched_mode[0] = WEIGHTED_ROUND_ROBIN;
// 配置权重（仅对加权轮询有效）
switch_config.queue_weight[2] = 50; // 队列 2 占 50%
switch_config.queue_weight[1] = 30; // 队列 1 占 30%
switch_config.queue_weight[0] = 20; // 队列 0 占 20%注意：不同芯片厂商的寄存器配置方式差别很大。有的用位域，有的用表格。上面只是逻辑示意。实际开发时一定要仔细看芯片手册。我曾经因为看错了一个寄存器的位偏移，导致优先级映射全乱了，排查了两天才找到问题。
4.5 避坑指南
最后，我总结几个实际项目中容易踩的坑：
- 优先级标签丢失：有些老旧交换机或网桥不支持 802.1p，会把 VLAN 标签直接扔掉。数据经过这些设备后，优先级信息就没了。解决办法是确保整条链路都支持 802.1p。
- 优先级滥用：所有数据都标成最高优先级。结果就是没有优先级。我见过一个项目，工程师图省事，把所有数据都标成了 7。最后控制指令和娱乐视频抢带宽，画面卡得要命。
- 队列深度不足：高优先级队列的缓冲区太小。如果突发数据量很大，队列满了就会丢包。控制指令丢包可不是闹着玩的。建议根据最坏情况计算队列深度。
- 调度策略选错：全用严格优先级，低优先级数据被饿死。全用加权轮询，高优先级延迟太大。要根据业务场景混合使用。
嗯，802.1p 优先级标记这部分，说白了就是给数据分三六九等。但怎么分、怎么调度，里面门道不少。我建议你在做系统设计时，先画一张流量矩阵图，把每种数据的优先级、带宽需求、延迟要求都列出来。然后再决定映射方案和调度策略。这样不容易出问题。