Linux NVMe驱动中reserved_tags作用及自定义IOCTL时预留/通用标签使用机制问询

看起来你已经成功实现了通过用户态指定QID提交NVMe IO的功能，很棒！下面我来给你拆解一下reserved tags（预留标签）的作用，以及它和通用IO标签的差异，还有你当前代码逻辑背后的细节：

1. blk-mq的Tag池基础 #

blk-mq是Linux块设备的多队列框架，每个硬件队列（hctx）都会维护一个Tag池——Tag是用来唯一标识每个IO请求的编号，避免同一队列内的请求冲突。这个Tag池被分成两个独立的子池：

• 通用IO标签（General Tags）
• 预留标签（Reserved Tags）

2. 通用IO标签的作用 #

通用标签是给常规IO请求分配的，比如：

• 文件系统发起的普通读写请求
• 块设备层自动调度的IO
• 所有不需要特殊处理的“普通”IO

这类请求由blk-mq框架自动调度到合适的硬件队列，通用标签池是驱动中最常用的资源，也是占比最大的Tag池部分。当通用标签被耗尽时，新的常规IO会进入等待队列，直到有标签被释放。

3. 预留标签的核心作用 #

预留标签是专门预留给特殊IO请求的独立资源池，设计目的是保证这类请求不会因为通用标签耗尽而无法提交，常见的使用场景包括：

• 驱动内部的控制类命令（比如NVMe的Admin命令、健康状态查询命令）
• 用户态直接提交的自定义IO命令（就像你现在实现的这种）
• 紧急优先级的IO请求（不能被常规IO阻塞）

它的核心特性是与通用标签池完全隔离：即使通用标签被占满，预留标签依然可以正常分配，确保特殊请求的及时性和可靠性。

4. 结合你的配置与代码分析 #

你把tagset.nr_hw_queues设置为reserved_tags的数量，这意味着：

• 整个队列集的预留标签总数等于硬件队列的数量，blk-mq会把这些预留标签平均分配到每个硬件队列的预留子池中——也就是每个硬件队列会得到至少1个专属的预留标签。
• 这种配置刚好匹配你的需求：每个用户态指定QID的请求，都能在目标队列的预留子池中拿到Tag，不会和常规IO的通用标签冲突。

再看你的代码逻辑：

req = blk_mq_alloc_request_hctx(
    q, 
    (nvme_req_op(cmd) | rq_flags), 
    (blk_flags | BLK_MQ_REQ_NOWAIT | BLK_MQ_REQ_RESERVED), 
    qid - 1);

你添加的BLK_MQ_REQ_RESERVED标志告诉blk-mq：从目标硬件队列的预留标签子池中分配Tag；而BLK_MQ_REQ_NOWAIT则表示如果预留标签也被耗尽，直接返回错误，不会让用户态进程挂起等待——这完全符合用户态自定义命令的预期（不能阻塞用户进程）。

5. 为什么你的代码能稳定工作 #

因为你给每个硬件队列都预留了专属的Tag位，用户态指定QID的请求直接使用这个预留位，不会和常规IO的通用Tag竞争资源。即使某个队列的通用Tag被占满，用户的自定义命令依然能成功分配到预留Tag，保证了自定义IO的可靠性。

注意事项 #

预留标签的数量不宜设置过大：因为预留标签是“独占”资源，不会被常规IO使用，过多的预留标签会浪费整个Tag池的容量，导致常规IO可用的Tag减少，影响整体性能。你当前设置为nr_hw_queues是非常合理的，刚好满足每个队列处理一个用户自定义命令的需求。

内容来源于stack exchange