ovs afxdp
ebpf 概念
eBPF，它的全称是”Extended Berkeley Packet Filter”。eBPF 的概念最早源自于 BSD 操作系统中的 BPF（Berkeley Packet Filter），tcpdump 工具就是利用了 BPF 的技术来抓取 Unix 操作系统节点上的网络包。
那 BPF 是怎样从内核中抓取数据包的呢？借用以下图例来说明：
第一，内核中实现了一个虚拟机，用户态程序通过系统调用，把数据包过滤代码载入到个内核态虚拟机中运行，这样就实现了内核态对数据包的过滤。
第二，BPF 模块和网络协议栈代码是相互独立的，当数据包到达一个网口时，链路层驱动会把数据包传送给上层网络协议栈，但当有 BPF 监听这个网口时，链路层驱动首先调用BPF，然后网络驱动重新获得控制权，如果目的地址不是本机将直接返回丢弃，如果目的地址是本机将按正常的将数据包传递给上层网络协议栈处理。
第三，BPF 填喂包过滤器，这些用户定义的包过滤器决定了一个包是否被接受，以及需要保存多少字节，对于每个接受这个数据包的 filter，BPF 拷贝请求大小的数据到对应 filter 关联的 buffer，把 filter 的结果返回给用户态程序（例如图中的 network monitor），这样就不会产生内核态与用户态的上下文切换（context switch）。
在 BPF 实现的基础上，Linux 在 2014 年内核 3.18 的版本上实现了 eBPF，全名是 Extended BPF，也就是 BPF 的扩展，它的应用范围自然也变广了。
xdp 基本原理
XDP 全称 eXpress Data Path，即快速数据路径，XDP 是 Linux 网络处理流程中的一个 eBPF 钩子，能够挂载 eBPF 程序，它能够提前处理网络数据包，具有非常优秀的数据面处理性能，打通了Linux网络处理的高速公路。
在 XDP 程序执行结束的时候，我们可以返回如下值，XDP会进行对应的操作：
- XDP_ABORTED，表示程序异常，会丢弃包。
- XDP_DROP，丢弃包。
- XDP_PASS，什么也不做，继续后续处理。
- XDP_TX，将包发送到 TX 队列中。
- XDP_REDIRECT，将包转发到其他网络设备。或者通过 AF_XDP 这个特殊的 socket 转发给用户空间的上层应用程序。
XDP 在有三个处理点： - offloaded 模式的 XDP：对于支持的网卡，直接在网卡上运行XDP程序，查阅资料，在网卡层面支持 xdp 的只有 Netronome 智能网卡（例如 Agilio CX 2x25GbE）。
- native 模式的 XDP：对于支持的网卡驱动，可以在包到达内核后立刻进行处理。
- generic 模式的 XDP：网卡和驱动不支持上述两种情况的 XDP 时，可以在此点进行处理。这个处理的位置相对靠后，在 tc 处理点之前。
ovs 支持 afxdp
OVS 有几个 netdev 类型，即 system、tap 或 dpdk。 AF_XDP 特性添加了一个名为“afxdp”的新网络开发类型，并实现其配置、数据包接收和传输功能。由于称为 xsk 的 AF_XDP 套接字在用户空间中运行，一旦 ovs-vswitchd 从 xsk 接收到数据包，afxdp netdev 将重新使用现有的用户空间 dpif-netdev 数据路径。结果，大部分数据包处理发生在用户空间而不是 linux 内核。
ovs 在 afxdp 模式下的配置方法
以此拓扑为例，关键配置如下：
1、设置 br0 模式
ovs-vsctl --may-exist add-br br0 – set Bridge br0 datapath_type=netdev – br-set-external-id br0 bridge-id br0 – set bridge br0 fail-mode=standalone
2、将物理网卡加入 br0
ovs-vsctl --timeout 10 add-port br0 ens2f1 – set Interface ens2f1 type=“afxdp”
3、设置 br-int 模式
ovs-vsctl --may-exist add-br br-int – set Bridge br-int datapath_type=netdev – br-set-external-id br-int bridge-id br-int – set bridge br-int fail-mode=secure
4、将虚拟网卡加入 br-int
ovs-vsctl add-port br-int tap0 – set interface tap0 type=“afxdp”
5、设置 pmd-cpu-mask
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=xxx
ovs 的 afxdp 模式与 dpdk 模式性能对比
xdp 测试拓扑
dpdk 测试拓扑
测试说明
左侧 vm 内运行 test-pmd，执行 icmp 报文的回包模式；右侧 trex 发送 icmp request 报文，可通过 ovs 转发到 vm，vm 回包后，读取收到报文的 pps；在 vm 内没有丢包的情况下，性能瓶颈就在 ovs 上面，所以两者 pps 的不同可说明两者模式的性能差异。
测试结果
dpdk 性能表现最好。
tap-xdp-generic
156小包：588.36 Kpps
1400大包：232.81 Kppstap-xdp-native-with-zerocopy
156小包：664.74 Kpps
1400大包：307.77 Kppsdpdk
156小包：3.21 Mpps
1400大包：428.4 Kpps
afxdp 主要特点
- 不用改驱动，不用改内核，eBPF 的程序完全运行在一个沙盒里，程序启动时加载进网卡就好了。
- 完整绕过了内核的协议栈，性能提升。
- 可以操作数据包的每一个 Byte 了，这个过程交由用户态程序处理。
- 高度兼容性，相比 DPDK 没有那么苛刻的硬件要求。
但是，自然也有一些弊端： - 网卡硬件卸载能力无法使用，好比 Checksum Offloading、TSO 等。这点就不如 DPDK 支持全面了。
- 网卡驱动不一定支持 ZeroCopy，你可能还是需要 Copy。
afxdp 将来可能的性能提升点
- 使用内存大页： 这个思路其实是抄 DPDK 的，因为操作系统默认情况下是通过 Page 为单位管理内存， UMEM 划分足够大时，使用大页来提高 TLB 查找的效率，其次避免操作系统把 UMEM 换出到交换空间去，UMEM 要给换到交换空间去就真的要命了。
- 支持多生产者：毕竟有时候还是会要并行发送。
- 增加 flow 流程：在 xdp 程序中增加 flow，提供卸载能力。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！