一篇文章带你读懂 io_uring 的接口与实现
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一篇文章带你读懂 io_uring 的接口与实现相关的知识，希望对你有一定的参考价值。
参考技术Aio_uring 是 Linux 提供的一个异步 I/O 接口。io_uring 在 2019 年加入 Linux 内核，经过了两年的发展，现在已经变得非常强大。本文基于 Linux 5.12.10 介绍 io_uring 接口。
io_uring 的实现主要在 fs/io_uring.c 中。
io_uring 的实现仅仅使用了三个 syscall：io_uring_setup, io_uring_enter 和 io_uring_register。它们分别用于设置 io_uring 上下文，提交并获取完成任务，以及注册内核用户共享的缓冲区。使用前两个 syscall 已经足够使用 io_uring 接口了。
用户和内核通过提交队列和完成队列进行任务的提交和收割。后文中会出现大量的简写，在这里先做一些介绍。
用户通过调用 io_uring_setup 1 初始化一个新的 io_uring 上下文。该函数返回一个 file descriptor，并将 io_uring 支持的功能、以及各个数据结构在 fd 中的偏移量存入 params。用户根据偏移量将 fd 映射到内存 (mmap) 后即可获得一块内核用户共享的内存区域。这块内存区域中，有 io_uring 的上下文信息：提交队列信息 (SQ_RING) 和完成队列信息 (CQ_RING)；还有一块专门用来存放提交队列元素的区域 (SQEs)。SQ_RING 中只存储 SQE 在 SQEs 区域中的序号，CQ_RING 存储完整的任务完成数据。2
在 Linux 5.12 中，SQE 大小为 64B，CQE 大小为 16B。因此，相同数量的 SQE 和 CQE 所需要的空间不一样。初始化 io_uring 时，用户如果不在 params 中设置 CQ 长度，内核会分配 entries 个 SQE，以及 entries * 2 个 CQE。
io_uring_setup 设计的巧妙之处在于，内核通过一块和用户共享的内存区域进行消息的传递。在创建上下文后，任务提交、任务收割等操作都通过这块共享的内存区域进行，在 IO_SQPOLL 模式下（后文将详细介绍），可以完全绕过 Linux 的 syscall 机制完成需要内核介入的操作（比如读写文件），大大减少了 syscall 切换上下文、刷 TLB 的开销。
io_uring 可以处理多种 I/O 相关的请求。比如：
下面以 fsync 为例，介绍执行这个操作中可能用到的结构体和函数。
io_op_def io_op_defs[] 数组中定义了 io_uring 支持的操作，以及它在 io_uring 中的一些参数。3 比如 IORING_OP_FSYNC：
io_uring 中几乎每个操作都有对应的准备和执行函数。比如 fsync 操作就对应 io_fsync_prep 和 io_fsync函数。
除了 fsync 这种同步（阻塞）操作，内核中还支持一些异步（非阻塞）调用的操作，比如 Direct I/O 模式下的文件读写。对于这些操作，io_uring 中还会有一个对应的异步准备函数，以 _async 结尾。比如：
这些函数就是 io_uring 对某个 I/O 操作的包装。
用户将需要进行的操作写入 io_uring 的 SQ 中。在 CQ 中，用户可以收割任务的完成情况。这里，我们介绍 SQE 和 CQE 的编码。
include/uapi/linux/io_uring.h 4 中定义了 SQE 和 CQE。SQE 是一个 64B 大小的结构体，里面包含了所有操作可能用到的信息。
io_uring_sqe的定义
CQE 是一个 16B 大小的结构体，包含操作的执行结果。
继续以 fsync 为例。要在 io_uring 中完成 fsync 操作，用户需要将 SQE 中的 opcode 设置为 IORING_OP_FSYNC，将 fd 设置为需要同步的文件，并填充 fsync_flags。其他操作也是类似，设置 opcode 并将操作所需要的参数并写入 SQE 即可。
通常来说，使用 io_uring 的程序都需要用到 64 位的 user_data 来唯一标识一个操作 5。user_data 是 SQE 的一部分。io_uring 执行完某个操作后，会将这个操作的 user_data 和操作的返回值一起写入 CQ 中。
相关视频推荐
io_uring 新起之秀的linux io模式，是如何媲美epoll的
网络原理tcp/udp，网络编程epoll/reactor，面试中正经“八股文”
学习地址：https://ke.qq.com/course/417774?flowToken=1013300
需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享
io_uring 通过环形队列和用户交互。
我们的先以用户提交任务为例，介绍 io_uring 的内核用户交互方式。用户提交任务的过程如下：
接下来我们简要介绍内核获取任务、内核完成任务、用户收割任务的过程。
介绍完 io_uring 的用户态接口后，我们就可以详细介绍 io_uring 在内核中是如何实现的了。
io_uring 在创建时有两个选项，对应着 io_uring 处理任务的不同方式：
这些选项的设定会影响之后用户与 io_uring 交互的方式：
每个 io_uring 都由一个轻量级的 io-wq6 线程池支持，从而实现 Buffered I/O 的异步执行。对于 Buffered I/O 来说，文件的内容可能在 page cache 里，也可能需要从盘上读取。如果文件的内容已经在 page cache 中，这些内容可以直接在 io_uring_enter 的时候读取到，并在返回用户态时收割。否则，读写操作会在 workqueue 里执行。
如果没有在创建 io_uring 时指定 IORING_SETUP_IOPOLL 选项，io_uring 的操作就会放进 io-wq 中执行。
上图覆盖了关闭 IOPOLL 模式下，用户通过 io_uring 执行操作的整个调用流程。用户提交的 SQE 经过一系列处理后，会在 io_queue_sqe 中试探着执行一次。
所有的操作都被提交到内核队列后，如果用户设置了 IORING_ENTER_GETEVENTS flag，io_uring_enter 在返回用户态前会等待指定个数的操作完成。
之后，Linux 随时会调度 io-wq 的内核线程执行。此时，io_wq_submit_work 函数会不断用阻塞模式执行用户指定的操作。某个操作完整执行后，它的返回值就会被写入 CQ 中。用户通过 io_uring 上下文中的 CQ 队尾位置就能知道内核处理好了哪些操作，无需再次调用 io_uring_enter。
通过火焰图可以观察到，在关闭 IOPOLL 时，内核会花大量时间处理读取操作。
创建 io_uring 时指定 IORING_SETUP_IOPOLL 选项即可开启 I/O 轮询模式。通常来说，用 O_DIRECT 模式打开的文件支持使用轮询模式读写内容，执行 read / write 操作。
在轮询模式下，io_uring_enter 只负责把操作提交到内核的文件读写队列中。之后，用户需要多次调用 io_uring_enter 来轮询操作是否完成。
在轮询模式下，io-wq 不会被使用。提交任务时，io_read 直接调用内核的 Direct I/O 接口向设备队列提交任务。
如果用户设置了 IORING_ENTER_GETEVENTS flag，在返回用户态前，io_uring_enter 会通过 io_iopoll_check 调用内核接口轮询任务是否完成。
通过火焰图可以看到，io_uring_enter 在提交任务这一块只花了一小部分时间。大部分时间都在轮询 I/O 操作是否完成。
在实际生产环境中，我们往往会有这样的需求：往文件中写入 n 次，然后用 fsync 落盘。在使用 io_uring时，SQ 中的任务不一定会按顺序执行。给操作设定 IO_SQE_LINK 选项，就可以建立任务之间的先后关系。IO_SQE_LINK 之后的第一个任务一定在当前任务完成后执行。7
io_uring 内部使用链表来管理任务的依赖关系。每一个操作在经过 io_submit_sqe 的处理后，都会变成一个 io_kiocb 对象。这个对象有可能会被放入链表中。io_submit_sqe 8 会对含有 IO_SQE_LINK 的 SQE 作特殊处理，处理过程如下：
由此看来，SQ 中连续的 IO_SQE_LINK 记录会按先后关系依次处理。在 io_submit_sqes 结束前，所有的任务都会被提交。因此，如果任务有先后关系，它们必须在同一个 io_uring_enter syscall 中批量提交。
其他用于控制 io_uring 任务依赖的选项包括 iosQE_IO_DRAIN 和 IOSQE_IO_HARDLINK，这里不再展开。
少啰嗦！一分钟带你读懂Java的NIO和经典IO的区别
1、引言
很多初涉网络编程的程序员，在研究Java NIO（即异步IO）和经典IO（也就是常说的阻塞式IO）的API时，很快就会发现一个问题：我什么时候应该使用经典IO，什么时候应该使用NIO？
在本文中，将尝试用简明扼要的文字，阐明Java NIO和经典IO之间的差异、典型用例，以及这些差异如何影响我们的网络编程或数据传输代码的设计和实现的。
本文没有复杂理论，也没有像网上基它文章一样千篇一律的复制粘贴，有的只是接地气的通俗易懂，希望能给你带来帮助。
（本文同步发布于：http://www.52im.net/thread-2635-1-1.html）
2、相关文章
3、Java NIO和IO的主要区别
下表总结了Java NIO和IO之间的主要区别。我将在表格后面的部分中详细介绍每个区别。
3.1 Stream Oriented vs. Buffer Oriented
Java NIO和IO之间的第一个重要区别是IO是面向流的，其中NIO是面向缓冲区的。那么，这意味着什么？
面向流的Java IO意味着您可以从流中一次读取一个或多个字节。你对读取的字节做什么取决于你。它们不会缓存在任何地方。此外，您无法在流中的数据中前后移动。如果需要在从流中读取的数据中前后移动，则需要先将其缓存在缓冲区中。
Java NIO的面向缓冲区的方法略有不同。数据被读入缓冲区，稍后处理该缓冲区。你可以根据需要在缓冲区中前后移动。这使你在处理过程中具有更大的灵活性。但是，你还需要检查缓冲区是否包含完整处理所需的所有数据。并且，你需要确保在将更多数据读入缓冲区时，不要覆盖尚未处理的缓冲区中的数据。
3.2 Blocking vs. Non-blocking IO
Java IO的各种流都是blocking的。这意味着，当线程调用read（）或write（）时，该线程将被阻塞，直到有一些数据要读取，或者数据被完全写入，在此期间，该线程无法执行任何其他操作。
Java NIO的非阻塞模式允许线程请求从通道读取数据，并且只获取当前可用的内容，或者根本没有数据，如果当前没有数据可用。线程可以继续使用其他内容，而不是在数据可供读取之前保持阻塞状态。
非阻塞写入也是如此，线程可以请求将某些数据写入通道，但不要等待它完全写入。然后线程可以继续并在同一时间做其他事情。
线程在IO调用中没有阻塞时花费空闲时间，通常在此期间在其他通道上执行IO。也就是说，单个线程现在可以管理多个输入和输出通道。
4、Selectors
Java NIO的选择器允许单个线程监视多个输入通道。你可以使用选择器注册多个通道，然后使用单个线程“选择”具有可用于处理的输入的通道，或者选择准备写入的通道。这种选择器机制使单个线程可以轻松管理多个通道。
5、NIO和经典IO如何影响应用程序的设计？
选择NIO或IO作为IO工具包可能会影响应用程序设计的以下方面:
1）API调用NIO或IO类；
2）处理数据；
3）用于处理数据的线程数。
5.1 API调用
当然，使用NIO时的API调用看起来与使用IO时不同。这并不奇怪。而不是仅仅从例如InputStream读取字节的数据字节，必须首先将数据读入缓冲区，然后从那里进行处理。
5.2 数据处理
使用纯NIO设计与IO设计时，数据处理也会受到影响。
在IO设计中，您从InputStream或Reader中读取字节的数据字节。想象一下，您正在处理基于行的文本数据流。
例如：
Name: Anna
Age: 25
Email: [url=mailto:[email protected]][email protected][/url]
Phone: 1234567890
这个文本行流可以像这样处理：
InputStream input = ... ; // get the InputStream from the client socket
BufferedReader reader = newBufferedReader(newInputStreamReader(input));
String nameLine = reader.readLine();
String ageLine = reader.readLine();
String emailLine = reader.readLine();
String phoneLine = reader.readLine();
注意处理状态是如何，由程序执行的程度决定的。换句话说，一旦第一个reader.readLine（）方法返回，您就确定已经读取了整行文本。readLine（）会阻塞直到读取整行，这就是原因。您还知道此行包含名称。同样，当第二个readLine（）调用返回时，您知道此行包含年龄等。
正如您所看到的，只有当有新数据要读取时，程序才会进行，并且对于每个步骤，您都知道该数据是什么。一旦执行的线程已经超过读取代码中的某个数据片段，该线程就不会在数据中向后移动（通常不会）。
此图中还说明了此原则：
▲ Java IO：从阻塞流中读取数据
NIO的实现看起来会有所不同，这是一个简化的例子：
ByteBuffer buffer = ByteBuffer.allocate(48);
intbytesRead = inChannel.read(buffer);
注意第二行从通道读取字节到ByteBuffer。当该方法调用返回时，您不知道所需的所有数据是否都在缓冲区内。你只知道缓冲区包含一些字节，这使得处理更加困难。
想象一下，在第一次读取（缓冲）调用之后，是否所有读入缓冲区的内容都是半行。例如，“姓名：An”。你能处理这些数据吗？并不是的。在完成任何数据的处理之前，您需要等待至少一整行数据进入缓冲区。
那么你怎么知道缓冲区是否包含足够的数据来处理它？好吧，你没有。找出的唯一方法是查看缓冲区中的数据。结果是，在您知道所有数据是否存在之前，您可能需要多次检查缓冲区中的数据。这既低效又可能在程序设计方面变得混乱。
例如：
ByteBuffer buffer = ByteBuffer.allocate(48);
intbytesRead = inChannel.read(buffer);
while(! bufferFull(bytesRead) )
bytesRead = inChannel.read(buffer);
bufferFull（）方法必须跟踪读入缓冲区的数据量，并返回true或false，具体取决于缓冲区是否已满。换句话说，如果缓冲区已准备好进行处理，则认为它已满。
bufferFull（）方法扫描缓冲区，但必须使缓冲区保持与调用bufferFull（）方法之前相同的状态。如果不是，则可能无法在正确的位置读入读入缓冲区的下一个数据。这不是不可能的，但这是另一个需要注意的问题。
如果缓冲区已满，则可以对其进行处理。如果它不满，您可能能够部分处理那里的任何数据，如果这在您的特定情况下是有意义的。在许多情况下，它没有。
这个图中说明了is-data-in-buffer-ready循环：
▲ Java NIO：从通道读取数据，直到所有需要的数据都在缓冲区中
6、什么时候该用NIO？什么时候该用经典IO？
NIO允许您仅使用一个（或几个）线程来管理多个通道（网络连接或文件），但成本是解析数据可能比从阻塞流中读取数据时更复杂。
如果您需要同时管理数千个打开的连接，每个只发送一些数据，例如聊天服务器，在NIO中实现服务器可能是一个优势。同样，如果您需要与其他计算机保持大量开放连接，例如在P2P网络中，使用单个线程来管理所有出站连接可能是一个优势。
此图中说明了这一个线程，多个连接设计：
▲ Java NIO：管理多个连接的单个线程
如果您拥有较少带宽的连接，一次发送大量数据，那么可能最经典的IO服务器实现可能是最合适的。
此图说明了经典的IO服务器设计：
▲ Java IO：经典的IO服务器设计 - 由一个线程处理的一个连接
7、更简化的理解
以众所周之的数据读取过程为例，我们来一个更简化的理解。
对于数据读取，就读取速度来说：CPU > 内存 > 硬盘。
I- 就是从硬盘到内存
O- 就是从内存到硬盘
第一种方式：从硬盘读取数据，然后程序一直等，数据读完后，继续你的操作。这种方式是最简单的，叫阻塞IO（也就是经典IO）。
第二种方式：从硬盘读取数据，然后程序继续向下执行，等数据读取完后，通知当前程序读取完成（对硬件来说叫中断，对程序来说叫回调），然后此程序可以立即处理读取的数据，也可以执行完当前操作后再对读取完的数据进行操作。
8、总而言之
还是以数据读取为例，操作系统是按块Block（块）从硬盘拿数据，就如同一个大脸盆，一下子就放入了一盆水。但是，当 Java 使用的时候，旧的 IO（经典IO）确实基于 流 Stream的，也就是虽然操作系统给我了一脸盆水，但是我得用吸管慢慢喝。
由于经典IO的重重落后理念，于是，NIO 横空出世。。。
附录：更多NIO异步网络编程资料
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《开源NIO框架八卦——到底是先有MINA还是先有Netty?》
《NIO框架入门(一)：服务端基于Netty4的UDP双向通信Demo演示》
《NIO框架入门(二)：服务端基于MINA2的UDP双向通信Demo演示》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
《Netty 4.x学习（二）：Channel和Pipeline详解》
《Apache Mina框架高级篇（一）：IoFilter详解》
《Apache Mina框架高级篇（二）：IoHandler详解》
《Apache MINA2.0 开发指南（中文版）[附件下载]》
《实践总结：Netty3.x升级Netty4.x遇到的那些坑（线程篇）》
《实践总结：Netty3.x VS Netty4.x的线程模型》
《Twitter：如何使用Netty 4来减少JVM的GC开销（译文）》
《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》
《新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析》
《写给初学者：Java高性能NIO框架Netty的学习方法和进阶策略》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2635-1-1.html）
以上是关于一篇文章带你读懂 io_uring 的接口与实现的主要内容，如果未能解决你的问题，请参考以下文章