Linux新的IO模型io_uring
一、Linux下的网络通信模型
在网络开发的过程中，需要处理好几个问题。首先是通信的内核支持问题；其次是通信的模型问题；最后是框架问题。这些问题在闭源的OS如Windows上，基本上不算什么大问题（因为只能用人家的API）。但在开源的OS上，典型的就是Linux上就是一个重要的问题。
在开源的系统上，如果内核原生支持一种IO通信，那么，效率一般来说会比不支持要高很多。网络通信有一个问题，它有点和算法在本质上有些相通，即选用哪种模型会导致它的通信效率差距非常大。举一个不恰当的例子，用一个只有两个槽的插座和十个槽的插座，能同时支持的用电接口个数完全不同。而在前面两个相同，而应用上，由于不同人对整个应用的理解和设计架构不同，导致其对应用支持的效率又有不同。同时，可能一种网络通信模型无法满足一些应用场景，所以框架一般会封装多种网络通信模型，这也是网络通信框架存在的意义。
但是有的时候，模型和框架往往混在一起，所以同一种技术在网络和书籍上的叫法均有不同，大家自己明白怎么回事儿即可，不要在这些细节上纠结。
看过Redis源的都清楚，在Redis中，对类linux的网络通信模型支持的有select,poll,epoll,kqueue。当然，可能不同的版本有所不同，这些细节就不再讨论。
一般来说，网络通信属于IO通信，而在IO通信中常见的几种通信模型有：
1、阻塞IO（Blocking IO）
2、非阻塞IO(NonBlocking IO)
3、IO多路复用（IO Multiplexing）
4、信号驱动（Signal Driven IO）
5、异步IO（Asynchonous IO）
这几种模型在《Unix网络编程》中都有总结。需要说明的是，这是从模型角度来抽象出来的，所以在其实现的过程中，是结合了内核支持和模型特点及应用支持几方面的来说明的。以前一般认为，在Linux中，对异步支持不如Windows好。
但开源技术有一个好处，缺啥补啥。所以在2019年的Linux内核5.1版本中，出现了一种新的IO框架，也就是io_uring。它是由block IO维护者Jens Axboe开发的一个用来支持异步IO通信的框架。
二、IO框架uring
io_uring为什么叫IO框架？因为其一开始主要是给存储搞的。网上的测评那是和SPDK可以一较高低，如果真那样，io_uring可比SPDK要强大，因为intel毕竟是一家国际大公司再加从底层直接支持。
但是，网络也属于IO啊，所以后来也就支持了网络IO。刚刚提到了，在Linux原生支持的IO通信中，大多数都是同步的，即使有一些框架实现了异步非阻塞仍然做的不是很好（AIO），在不少的情况下，仍然会出现非异步的情况。但是io_uring的出现，可以说是一种革命性的突破，它和eBPF是内核的两个重大的技术里程碑。
一个优秀的异步IO框架，一般具有以下几个特点：
1、异步非阻塞
异步和非阻塞往往是和IO通信分不开的，而异步和非阻塞又往往出现在一起。在IO通信中，非阻塞是实现异步的一个前提。而异步非阻塞往往是一种IO通信框架是否高效的基础。
2、减少或删除中间环节
容易理解的是，同步阻塞通信因为等待的原因，对中间环节通信（事件通知、数据拷贝次数、系统调用次数等）敏感性不强。但是异步非阻塞往往意味着海量的IO操作，所以中间环节增加任何一个步骤，付出的代价往往是难以忍受的。这也是AIO被诟病的地方。
3、扩展性要强
一个IO框架，不能只适应一种IO情况。比如磁盘、网络等都可以支持。
4、应用方便快捷
这是一个好的框架必备的特点。再优秀的东西，一旦变得复杂，就会慢慢失去它的优秀性。复杂就意味着高成本和后期维护的困难。
从Linux的异步框架发展来看，在io_uring之前出现过一些异步框架，但是对上述问题的解决都不是太好，所以一直无法融入内核之中，直到io_ring的出现。
而io_uring基本实现了上述几个特点。
首先，io_uring通过使用共享内存技术，大幅减少了内核层和应用层数据的交互拷贝，也减少了内核层和用户层的调用次数。其次数据隔离、交互减少就意味着内核和用户层可以自行其事，安排自己的线程工作状态时不用等待对方状态结果，这也是异步通信的一个重要前提。为了进一步实现异步，io_uring还实现了一个无锁环形队列，通过操作其实现用户态和内核态的IO非阻塞交互。
通过上述的说明基本可以了解io_uring的工程机制，做为一种框架，需要说明一下io_uring操作的流程：
1、应用程序提交IO操作请求到提交队列
2、SQ内核线程读取IO操作
3、SQ内核线程发起IO请求
4、SQ内核线程将结果写回完成队列
5、应用程序在完成队列读到IO结果
io_uring通过共享内存来减少交互，在io_uring中，主要有四种队列，即：
1、提交队列（Submission Queue, SQ）：一整块连续的内存空间存储的环形队列，存放将执行 I/O 操作的数据（指向SQE数组的索引）
2、完成队列（Completion Queue, CQ）：一整块连续的内存空间存储的环形队列，存放 I/O 操作完成后的结果
3、提交队列项数组（Submission Queue Entry，SQE） ：提交队列中的每项是SQ中的数据项
4、CQE - Completion Queue Entry：完成队列项，这是储存在CQ中的数据项
io_uring 在创建时有两个选项，对应着 io_uring 处理任务的不同方式：
1、IORING_SETUP_IOPOLL，io_uring 会使用轮询的方式执行所有的操作
2、IORING_SETUP_SQPOLL，io_uring 会创建一个内核线程专门用来处理用户提交的任务
这两个选项的设置会对之后的交互产生如下影响：
1、都不设置，即以io_uring_enter 提交任务，内核线程任务无需 syscall
2、设置IORING_SETUP_IOPOLL，以io_uring_enter 提交任务和处理任务。
3、设置IORING_SETUP_SQPOLL，直接提交处理任务（不需要syscall）。内核线程自动控制处理并在一定条件下休眠，然后可使用io_uring_enter唤醒。
当用户设置了 IORING_SETUP_SQPOLL选项（SQPOLL模式）创建 io_uring 时，内核将会创建一个名为 io_uring-sq 的内核线程（即SQ线程），SQ线程从提交队列读取IO操作，并且发起IO请求。
当IO请求完成以后，SQ线程将会把IO操作的结果写回到完成队列，这样，应用程序就可以从中得到IO操作的结果。
三、应用例程
直接使用io_uring有些复杂，开发者在io_uring的基础上又封装了一个库即liburing,这样普通开发者可以直接使用它。看一下其UDP通信的例程：
#include " ;
fprintf(stderr, "received %u bytes %d from [%s]:%d\n",
io_uring_recvmsg_payload_length(o, cqe->res, &ctx->msg),
o->namelen, name, (int)ntohs(addr->sin_port));
}
if (get_sqe(ctx, &sqe))
return -1;
ctx->send[idx].iov = (struct iovec) {
.iov_base = io_uring_recvmsg_payload(o, &ctx->msg),
.iov_len =
io_uring_recvmsg_payload_length(o, cqe->res, &ctx->msg)
};
ctx->send[idx].msg = (struct msghdr) {
.msg_namelen = o->namelen,
.msg_name = io_uring_recvmsg_name(o),
.msg_control = NULL,
.msg_controllen = 0,
.msg_iov = &ctx->send[idx].iov,
.msg_iovlen = 1
};
io_uring_prep_sendmsg(sqe, fdidx, &ctx->send[idx].msg, 0);
io_uring_sqe_set_data64(sqe, idx);
sqe->flags |= IOSQE_FIXED_FILE;
return 0;
}
static int process_cqe(struct ctx *ctx, struct io_uring_cqe *cqe, int fdidx)
{
if (cqe->user_data < BUFFERS)
return process_cqe_send(ctx, cqe);
else
return process_cqe_recv(ctx, cqe, fdidx);
}
int main(int argc, char *argv[])
{
struct ctx ctx;
int ret;
int port = -1;
int sockfd;
int opt;
struct io_uring_cqe *cqes[CQES];
unsigned int count, i;
memset(&ctx, 0, sizeof(ctx));
ctx.verbose = false;
ctx.af = AF_INET;
ctx.buf_shift = BUF_SHIFT;
while ((opt = getopt(argc, argv, "6vp:b:")) != -1) {
switch (opt) {
case '6':
ctx.af = AF_INET6;
break;
case 'p':
port = atoi(optarg);
break;
case 'b':
ctx.buf_shift = atoi(optarg);
break;
case 'v':
ctx.verbose = true;
break;
default:
fprintf(stderr, "Usage: %s [-p port] "
"[-b log2(BufferSize)] [-6] [-v]\n",
argv[0]);
exit(-1);
}
}
sockfd = setup_sock(ctx.af, port);
if (sockfd < 0)
return 1;
if (setup_context(&ctx)) {
close(sockfd);
return 1;
}
ret = io_uring_register_files(&ctx.ring, &sockfd, 1);
if (ret) {
fprintf(stderr, "register files: %s\n", strerror(-ret));
return -1;
}
ret = add_recv(&ctx, 0);
if (ret)
return 1;
while (true) {
ret = io_uring_submit_and_wait(&ctx.ring, 1);
if (ret == -EINTR)
continue;
if (ret < 0) {
fprintf(stderr, "submit and wait failed %d\n", ret);
break;
}
count = io_uring_peek_batch_cqe(&ctx.ring, &cqes[0], CQES);
for (i = 0; i < count; i++) {
ret = process_cqe(&ctx, cqes[i], 0);
if (ret)
goto cleanup;
}
io_uring_cq_advance(&ctx.ring, count);
}
cleanup:
cleanup_context(&ctx);
close(sockfd);
return ret;
}
更多的代码可以参看GITHUB中的相关代码。
四、技术说明
通过上面的分析，大家是否有所明白。包括DPDK等一些高效的框架，一些主要的特点，基本都是通过共享内存来减少内核与应用层的交互（特别是数据的拷贝），通过无锁队列来实现高效的非阻塞的通信。这意味着内核以后的工作可能会尽量减少和上层应用的直接通信。换句话说，内核要做一个高效的管理者和协调者而不是一个大而全的工作者。
这其实给开发者的一个借鉴在于：设计和开发时，要适当抽象（抽象越高，意味着引入的中间层越多），在可能的前提下尽量减少中间环节；引入新技术，如无锁编程等；异步工作是方向。
以Linux的IO技术发展为例，可以为两大部分，即内核原生支持和非原生支持（DPDK）。而原生支持里，从同步阻塞IO开始慢慢发展到异步IO的过程，又到io_uring融入内核的过程，就是给予开发者借鉴的一个经典的例子。可能大多数开发者意识不到这一点，也有可能在国内这个过程非常迅速甚至忽略某些中间过程。但实际上，整个的方向和发展的过程的经历基本是类似的。
本文对io_uring只是一个基础的介绍说明，大家有兴趣可以深入学习并引入自己的工程中去。实践出真知。
五、总结
这里没有更细节展开谈IO模型和同步异步以及阻塞非阻塞的问题，这些基础的问题，不明白的需要去查阅相关资料。这篇文章只是一个开始，以后有机会的话，会将整个网络开发进行整体的分析说明和具体应用。
技术的进步一定是向前发展的，开发者们一定睁开眼睛，瞭望世界，不要固守一隅，夜郎自大。