从DPDK和eBPF感受一下Smart NIC

安德森先生这周从上海来过周末,小小给妈妈外婆讲了刚学到的恺撒加密算法,而我,写一篇随笔吧。


周三晚上,我演示了Linux下一代防火墙bpfilter的一个自制简易POC:

前天晚上在家加班处理问题,一顿操作后没响应了,以为系统panic了,就等待重启,远程登录的设备,就不知道是不是真panic了还是说仅仅网络断了,等待期间撸了下文里的代码,还测通了,当再想起正事儿的时候,快一个小时过去了,系统依旧没有恢复…让同事帮忙带外check,发现是在我配置vf时网卡reset了,丢了路由…这就是远程登录的坏处,搞搞业务代码还行,搞网络搞内核的还是机器在眼前,键盘在手边让人安心啊。

不过好歹我没有干等,下文分享给大家,一起玩bpfilter和智能网卡吧。必须值得一提的,iproute2和netfilter我已经用了十来年了,前者一直在与时俱进,后者却几乎没有变化,然而这并不意味着netfilter就是一无是处,在我看来5个hook点可以部署成ebpf的容器,配合以pinned map,就完美了,ebpf是瑞士军刀,它缺个刀鞘,否则容易误伤自己。

bpfilter是什么,让我演示给你看:
https://blog.csdn.net/dog250/article/details/103283981

那么,这个和DPDK有什么关系。说实话,本文不该提DPDK的,应该提的是类似netmap,PF_RING的这种东西:
https://www.ntop.org/products/packet-capture/pf_ring/
只不过,DPDK太为人所熟知了,所以就用DPDK来指代这一切,但也只是指代。

本文不说DPDK的细节,因为我也不是很懂,虽然不喜欢DPDK但也不贬它,DPDK在本文中只是一个引子。

不管怎样,先说结论,DPDK和eBPF都是在吐槽嫌弃现代操作系统内核实现的网络协议栈。

实话实说,我也觉得网络协议栈不应该在操作系统内核实现,它只是一个应用,而不是系统的范畴。但是30多年来,网络协议栈一直都在各大操作系统内核中实现。

之所以这样,是因为操作系统原初并没有将数据处理和逻辑控制相分离,通信行业的数据面,控制面,管理面分离的理念并没有在新生的计算机业内发展起来,人们一团糟地将一切和具体业务无关的东西都塞进了操作系统内核,当然,这也是造成宏内核的根本原因。

随着计算机网络技术的发展,通信技术和计算机网络技术逐渐融合。

把网络协议栈从操作系统剥离出来的最好方式就是 实现一个数据平面

DPDK似乎找到了一种正确的方法,即直接将数据包拉到用户态来处理,绕过操作系统内核(Tilera Core以及通用的netmap当然也是这种方式)。虽然它们的实现各自不同,但整体看来,这些机制又大又重。

由于网卡功能有限,它没有逻辑计算单元,仅负责收发数据包的IO操作以及极少量的数据包缓存,大部分的协议流程都必须由主机CPU来完成,即便绕过了操作系统内核,CPU也还是必须的,因此DPDK一般而言都是专门分配一个或者几个CPU核心来处理数据包。

在这里插入图片描述

既然数据包来自网卡,何不让网卡自己去处理?给网卡赋予逻辑处理能力就可以了。

因此,ASIC以及FPGA承担了高性能网络处理的职责,专门的电路可以及时就地处理数据包,无需主机CPU参与,解放了CPU。

在这里插入图片描述

但同样是大而重的,你必须采用专用的软件对专门的硬件进行编程,类似DPDK有一套需要学习后才能上手的SDK一样,FPGA甚至需要专门的语言。

何不在网卡上装一个足够通用的CPU配备一块足够通用的内存呢,如此网卡就是一个五脏俱全的小型计算机了,既然是个计算机,那就可以执行通用代码咯。

在这里插入图片描述

和DPDK把数据包拉到用户态的方向相反,与其把数据上拉被CPU处理,把处理数据包的代码向下注入网卡是殊途同归的,为了让网卡可以执行注下去的代码,给网卡内置几个CPU即可,这就是智能网卡的思路。

DPDK从上面经由用户态bypass内核协议栈,智能网卡从下面在硬件里offload协议栈的逻辑。

在这个意义上,DPDK其实就是把x86 CPU+Ringbuffer和Intel网卡一起,当成了一块 “智能网卡”

下面的图示展示了智能网卡的结构以及注入代码的执行逻辑,来自netronome的Open-NFP官网:
在这里插入图片描述
netronome开创了智能网卡新时代,netronome SmartNIC可以配备几十个处理器同时执行网络数据包处理的代码,从而卸载主机CPU的劳力,这就是我们常说的硬件Offload。

那么如何把代码注入到智能网卡呢?

你可以使用专用的模式,阅读智能网卡厂商的指令集,然后确保最终的机器码对应该指令集即可,但幸运的是,我们有通用的eBPF的JIT编译,可以将eBPF中间字节码编译成智能网卡的机器码。整个过程从编程到部署,非常通用:
在这里插入图片描述

目前netronome SmartNIC已经实现了该JIT编译器,参见Linux内核目录树:

linux-source-5.xx/drivers/net/ethernet/netronome

其中,eBPF字节码的JIT编译器在 “nfp/bpf” 子目录。


具体到Offload如何部署,也是很简单。一般而言,我们要先用C语言写一个eBPF程序,比如test.c,然后用clang指定目标体系结构为bpf,将其编译成二进制字节码test.o,这个时候,就差一个加载器了。

以我非常喜欢的iproute2套件为例,比方说要把test.o加载到一块netronome网卡eth0,需要这么做即可:

ip link set dev eth0 xdpoffload obj test.o

如此一来,test.c里面的逻辑就可以在智能网卡中被执行了,完全卸载了主机CPU的劳力。

整个操作过程,基本上也就这般。

和大而重的DPDK相比,智能网卡的eBPF小而巧,如果我们把DPDK看成是一门红衣大炮,那么eBPF就是瑞士军刀,虽然处理完整的TCP协议还不够,但是做个数据包拦截,解析是绰绰有余。

eBPF和智能网卡是我们这种手艺人的福音!

编程手艺人指的就是不懂大型软件工程流程,没参与过大型软件开发,不会高级编程语言,没写过多少代码,不会使用发布工具,不经常用git,但也不是一点都不会编程,还是稍微懂一点编程的。不过手艺人精通计算机原理,精通操作系统的实现,精通网络协议,所以手艺人一般可以轻松完成BUG的定位和fix工作,由于不会大段大段写代码,所以手艺人往往精于精准定位,一两行代码就能fix,比如加一个mb。所以,手艺人往往在职场工作量上吃亏,手艺人善于自己玩。

几年前我没事就想折腾折腾协议栈,比如优化下nf_conntrack啦,把socket指针藏进nf_conntrack啦,把路由项藏进nf_conntrack啦,在网卡层短路协议栈啦,实现一个无状态NAT啦,在内核实现一个加密通道啦…然而最终也只是玩玩,如今,有了eBPF和XDP,并且eBPF支持了pinned map之后,以上这些都可以重玩了。有时间重新撸一遍,嗯,就这么定了!


介绍些资料:
https://lwn.net/Articles/760041/ 【netronome网卡进化路径上的绝佳一笔,可以在单片ASIC上共享eBPF程序和map了!】
https://lwn.net/Articles/675826/ 【多端口switch模型,Linux反客为主,打破网络设备厂商的垄断】

通用的switchdev驱动模型之前,Linux需要厂商的专门工具套件操作交换机,控制权在厂商,switchdev之后,通用接口被实现,交换机正式纳入Linux网络设备体系,Linux至此可以用标准接口实现交换机的控制面和管理面了,至此以后,各大互联网厂商的自研交换机才开始遍地开花!!

http://wiki.netfilter.org/pablo/netdev0.1/papers/Rocker-switchdev-prototyping-vehicle.pdf 【多端口switch设备的实例】
下面是我自己写的一些关于eBPF的文章:
https://blog.csdn.net/dog250/article/details/103283981
https://blog.csdn.net/dog250/article/details/103245748
https://blog.csdn.net/dog250/article/details/102982948
https://blog.csdn.net/dog250/article/details/103094759
https://blog.csdn.net/dog250/article/details/103014526
https://blog.csdn.net/dog250/article/details/102884567


浙江温州皮鞋👞湿,下雨☔️进水不会胖!

发布了1561 篇原创文章 · 获赞 4917 · 访问量 1094万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览