[转]从DPDK和eBPF感受一下Smart NIC
2021-12-07 08:00:00 Author: blog.csdn.net(查看原文) 阅读量:46 收藏

d5ac36eed5c1f73550812e8c6eea8b4d.png

原文作者:dog250

原文链接:https://blog.csdn.net/dog250/article/details/103301816

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

d5d6328cad23d63d584ca9bda935e8de.gif

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

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

bpfilter是什么,让我演示给你看:

https://blog.csdn.net/dog250/article/details/103283981

第一,引入虚拟地址的一个重要原因是在软件(操作系统)级进行页面保护,以防止进程间相互侵犯地址空间。由于这种保护是通过页表和翻译旁视缓冲器(TLB)中的保护位(protectionbit)实现的,直接使用虚拟地址来访问数据等于绕过了页面保护。一个解决办法是在缓存失效时查看TLB对应表项的保护位以确定是否可以加载缺失的数据。

那么,这个和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核心来处理数据包。

ac4bd70600a40bf46a0015ae21d2c81f.png

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

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

ece75374266b4f7b3305f8a5e1b43c7b.png

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

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

0dbd43863456737917361783dc357a5e.png

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

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

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

下面的图示展示了智能网卡的结构以及注入代码的执行逻辑,来自netronome的Open-NFP官网:

f98aad575c29e576f48a7dd3a7b48d2b.png

netronome开创了智能网卡新时代,netronome SmartNIC可以配备几十个处理器同时执行网络数据包处理的代码,从而卸载主机CPU的劳力,这就是我们常说的硬件Offload。

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

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

7d34ee1f22c803140acda49570e09548.png

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

1|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,需要这么做即可:

1|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


文章来源: https://blog.csdn.net/21cnbao/article/details/121782217
如有侵权请联系:admin#unsafe.sh