[[344628]]

本文轉(zhuǎn)載自微信公眾號「云巔論劍」，作者費曼 。轉(zhuǎn)載本文請聯(lián)系云巔論劍公眾號。  

 1. 概述

傳統(tǒng)高性能網(wǎng)絡(luò)編程通常是基于select, epoll, kequeue等機制實現(xiàn)，網(wǎng)絡(luò)上有非常多的資料介紹基于這幾種接口的編程模型，尤其是epoll，nginx, redis等都基于其構(gòu)建，穩(wěn)定高效，但隨著linux kernel主線在v5.1版本引入io_uring新異步編程框架，在高并發(fā)網(wǎng)絡(luò)編程方面我們多了一個利器。

io_uring在進行初始設(shè)計時就充分考慮其框架自身的高性能和通用性，不僅僅面向傳統(tǒng)基于塊設(shè)備的fs/io領(lǐng)域，對網(wǎng)絡(luò)異步編程也提供支持，其最終目的是實現(xiàn)linux下一切基于文件概念的異步編程。

2. echo_server場景下的性能對比

我們先看下io_uring和epoll在echo_server模型下的性能對比，測試環(huán)境為：

1. server端cpu Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz, client端cpu Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz

2. 兩臺物理機器，一臺做server, 一臺做client。

Note: 如下性能數(shù)據(jù)都是在meltdown和spectre漏洞修復(fù)場景下測試。

上圖是io_uring和epoll在echo_server場景下qps數(shù)據(jù)對比，可以看出在筆者的測試環(huán)境中，連接數(shù)1000及以上時，io_uring的性能優(yōu)勢開始體現(xiàn)，io_uring的極限性能單core在24萬qps左右，而epoll單core只能達到20萬qps左右，收益在20%左右。

上圖統(tǒng)計的是io_uring和epoll在echo_server場景下系統(tǒng)調(diào)用上下文切換數(shù)量的對比，可以看出io_uring可以極大的減少用戶態(tài)到內(nèi)核態(tài)的切換次數(shù)，在連接數(shù)超過300時，io_uring用戶態(tài)到內(nèi)核態(tài)的切換次數(shù)基本可以忽略不計。

3. epoll 網(wǎng)絡(luò)編程模型

下面展開介紹epoll和io_uring兩種編程模型基本用法對比，首先介紹下傳統(tǒng)的epoll網(wǎng)絡(luò)編程模型， 通常采用如下模式：

struct epoll_event ev; 
 
/* for accept(2) */ 
ev.events = EPOLLIN; 
ev.data.fd = sock_listen_fd; 
epoll_ctl(epollfd, EPOLL_CTL_ADD, sock_listen_fd, &ev); 
 
/* for recv(2) */ 
ev.events = EPOLLIN | EPOLLET; 
ev.data.fd = sock_conn_fd; 
epoll_ctl(epollfd, EPOLL_CTL_ADD, sock_conn_fd, &ev); 
 
然后在一個主循環(huán)中： 
new_events = epoll_wait(epollfd, events, MAX_EVENTS, -1); 
for (i = 0; i < new_events; ++i) { 
    /* process every events */ 
    ... 
} 

本質(zhì)上是實現(xiàn)類似如下事件驅(qū)動結(jié)構(gòu)：

struct event { 
    int fd; 
    handler_t handler; 
}； 

將fd通過epoll_ctl進行注冊，當(dāng)該fd上有事件ready, 在epoll_wait返回時可以獲知完成的事件，然后依次調(diào)用每個事件的handler, 每個handler里調(diào)用recv(2), send(2)等進行消息收發(fā)。

4. io_uring 網(wǎng)絡(luò)編程模型

io_uring的網(wǎng)絡(luò)編程模型不同于epoll, 以recv(2)為例，它不需要通過epoll_ctl進行文件句柄的注冊，io_uring首先在用戶態(tài)用sqe結(jié)構(gòu)描述一個io 請求，比如此處的recv(2)系統(tǒng)調(diào)用，然后就可以通過io_uring_enter(2)系統(tǒng)調(diào)用提交該recv(2)請求，用戶程序通過調(diào)用io_uring_submit_and_wait(3)，類似于epoll_wait(2)，獲得完成的io請求，cqe結(jié)構(gòu)用于描述完成的ioq請求。

/* 用sqe對一次recv操作進行描述 */ 
struct io_uring_sqe *sqe = io_uring_get_sqe(ring); 
io_uring_prep_recv(sqe, fd, bufs[fd], size, 0); 
 
/* 提交該sqe, 也就是提交recv操作 */ 
io_uring_submit(&ring); 
 
/* 等待完成的事件 */ 
io_uring_submit_and_wait(&ring, 1); 
cqe_count = io_uring_peek_batch_cqe(&ring, cqes, sizeof(cqes) / sizeof(cqes[0]));    
for (i = 0; i < cqe_count; ++i) { 
    struct io_uring_cqe *cqe = cqes[i]; 
    /* 依次處理reap每一個io請求，然后可以調(diào)用請求對應(yīng)的handler */ 
    ... 
} 

總結(jié)下：為什么io_uring相比epoll模型能極大的減少用戶態(tài)到內(nèi)核態(tài)的上下文切換?舉個簡單例子，epoll_wait返回1000個事件，則用戶態(tài)程序需要發(fā)起1000個系統(tǒng)調(diào)用，則就是1000個用戶態(tài)和內(nèi)核態(tài)切換，而io_uring可以初始化1000個io請求的sqes, 然后調(diào)用一次io_uring_enter(2)系統(tǒng)調(diào)用就可以下發(fā)這1000個請求。

在meltdown和spectre漏洞沒有修復(fù)的場景下，io_uring相比于epoll的提升幾乎無，甚至略有下降，why? 我們不是減少了大量的用戶態(tài)到內(nèi)核態(tài)的上下文切換?

原因是在meldown和spectre漏洞沒有修復(fù)的場景下，用戶態(tài)到內(nèi)核態(tài)的切換開銷很小，所帶來的的收益不足以抵消io_uring框架自身的開銷，這也說明io_uirng框架本身需要進一步的優(yōu)化。

詳細的epoll和io_uring基于echo_server模型的對比程序在 ：https://github.com/OpenAnolis/io_uring-echo-server(詳見原文鏈接)。

5. 接下來的工作

1.目前從分析來看，io_uring框架本身存在的overhead不容小覷，需要進一步優(yōu)化，我們已經(jīng)在io_uring社區(qū)進行io_uring框架開銷不斷增大的討論，并已經(jīng)開展了一系列的優(yōu)化嘗試。

2.echo_server代表著一類編程模型，不是真實的應(yīng)用，但redis, nginx等應(yīng)用其實都是基于echo_server模型，將其用io_uirng來改造，理論上在cpu 漏洞修復(fù)場景下都會帶來明顯性能提升，我們已經(jīng)在開展nginx, redis的io_uring適配工作，后續(xù)會有進一步的介紹。