solarflare高性能网卡

1、kernel bypass 框架
    solarflare 软硬件方案
    DPDK

2、solarflare 高性能网卡
        价格：> 4000元
        配套的 kernel bypass 软件解决方案：Onload, ef_vi和Tcpdirect

3、性能测试
    两台直连的服务器进行 pingpong 测试 RTT（往返时延）。
    官方文档测试结果：10G网络可以低至800多ns。
        测试的局限性：
        1）每次发送的数据都是完全一样的（payload全0），在ef_vi udp的测试代码中有一些优化：初始化阶段就准备好了要发送的frame数据(包括ethernet头，ip头，udp头和payload），只要程序一收到数据就发送这个相同的frame出去。
        2）pingpong 测试是不间断的收发，一秒钟会处理几十万个包，实际场景一般不会出现这么高频的情况。

    优化后的测试：编写 client 和 server 程序，client 每次发送不同的数据，server 收到后原样回复 client。server 接收数据使用 udp multicast（模仿接收行情），发送数据使用 tcp （模仿发送订单），因此 server 会先 tcp 连接到 client 。client 控制发送频率：每秒1000个包，5秒结束。

    最佳延迟是960ns +/- 90ns。使用 X2 系列网卡（支持ctpio，比非ctpio快200ns)，ef_vi接收udp，tcpdirect发送tcp，屏蔽中断。使用16字节 payload 的小包进行测试，对于更长的包可以用 1 byte = 1.5ns 来近似。

4、kernel bypass 软件方案
onload
    兼容 socket 网络编程接口，无需修改应用代码，只需 preload libonload.so 。
    性能： 比使用 kernel 快 6000多ns，比ef_vi/tcpdirect慢300多ns。
    配置： EF_TCP_FASTSTART_INIT=0 EF_TCP_FASTSTART_IDLE=0，其他默认。

ef_vi
    ef_vi 是一个 level 2 的底层 API，可以收发原始的 ethernet frame，但没有提供上层协议的支持（不过能支持基于IP,proto,port的接收端filter)。除此之外ef_vi最大的特点是zero-copy：它要求用户预先分配一些recv buffer提供给ef_vi使用，网卡收到包后会直接写入这些buffer，用户通过 eventq poll 接口获得已填充数据的 buffer id 即可开始处理接收数据，处理完后再把 buffer 交还 ef_vi 循环使用。相比而言，onload 无法做到这样的zero-copy，因为socket API只在用户开始接收数据时才提供buffer。

    ef_vi API使用起来比较复杂，且缺乏上层协议支持，但能提供最好的性能，是专业用户的选择。建议只使用 ef_vi 做 udp 的接收端，因为经 filter 后用户对包头的解析工作不多，这还有一个好处是，可以在用户程序中抓包（比如用于记录行情，后面会提到通用的本地抓包方法并不合适）：通过一个ring buffer和一个写pcap文件的非关键线程，可以做到处理网络数据和抓包同时进行，而且抓包对处理数据的关键线程几乎零影响，这充分利用了 ef_vi 底层和 zero-copy 的特性。

tcpdirect
    tcpdirect 是基于 ef_vi 并实现了上层协议的 stack，提供了类似 socket 的 API：zocket，能让用户读写 tcp/udp的payload数据，同时也继承了ef_vi zero-copy的特性。另外，tcpdirct要求使用 huge pages。

    建议是，对于udp的发送端和整个tcp使用tcpdirect。


5、测量网卡到网卡的延迟
    1）让交换机把 server 的收发链路数据镜像到另一个抓包设备。这种方法比较依赖交换机性能，精确度不高，比如抓包结果会出现乱序的现象。

    2）通过tap或分光设备把 server 的网口数据分发到另一个抓包设备。
    3）在 server 本地抓包。比较依赖抓包工具，目前已有的工具都有其局限性。
    4）在程序中使用 onload/ef_vi/tcpdirect  提供的API获得包收发的硬件时间戳（网卡时间戳），这是主要使用的方法，同时也参考了从 client 获得的 RTT，用于 double check 前者的结果，另外可以测量各种抓包工具或者获取硬件时间戳造成的额外延迟。


6、本地记录网络包时间戳

tcpdump
    通过kernel抓包，但对kernel bypass的方案无效，记录的是软件时间（系统时间戳），不等同网卡时间。tcpdump带来的额外延迟约为2000ns。

onload_tcpdump
    可以对使用 onload 方案的网络数据进行抓包，但对其他无效，也无法获得硬件时间戳。onload_tcpdump带来的额外延迟约为1500ns。

solar_capture
    solarflare自己软件抓包工具，需要额外购买license，不便宜，和网卡本身的价格差不多了，而且license绑定网卡。官方宣传solar_capture性能很高，可以记录收发包的网卡时间戳。
        1）不支持 solarflare 最先进的X2系列网卡，只支持较老的7000/8000系列。
        2）不支持"ultra-low-latency"的网卡模式。"ultra-low-latency"比其他模式快100ns左右，默认会使用的模式。
        3）对于一个网口的收和发的数据是通过两个任务来记录的，pcap文件中可能出现乱序现象（但时间戳是准确的），需要分析结果的用户自己处理。
solar_capture带来的额外延迟约为50ns。

通过ef_vi/tcpdirect API获取网卡时间戳
    ef_vi 和 tcpdirect 提供了获取接收和发送时间戳的 API（获取发送时间戳是OpenOnload 201811新增加的功能），这样就可以在用户程序中直接测量网卡到网卡的延时。获取两个硬件时间戳带来的额外延迟约为50ns，看上去和获取系统时间戳的开销差不多。

sfptpd
    同步网卡时间源。和本地系统时间同步，可以测量网卡到用户程序，和用户程序到网卡的分段延迟。这个服务必须一直运行才能保证同步的比较准确。



    原则：所有的时间测量方式都会造成额外延迟，尽量避免在生产环境中过多使用。