10G(82599EB) 网卡测试优化(ethtool)

10G(82599EB) 网卡测试优化(ethtool)

  • 10G(82599EB) 网卡测试优化(总)
  • 10G(82599EB) 网卡测试优化(jumbo frame, tcp win scaling)
  • 10G(82599EB) 网卡测试优化(ethtool)
  • 10G(82599EB) 网卡测试优化(kernel)
  • 10G(82599EB) 网卡测试优化(中断处理) 
  • 10G(82599EB) 网卡测试优化(other)

 

ethtool,主要涉及 NIC 的本身比如 ring buffer,内容还是蛮多,不少跟硬件的特性相关,分几个大方向说。

speed,duplex 这类的是非常基本的设置,不在这里说了。需要注意的是,能 auto 的尽量 auto,因此,正常情况下,Auto-negotiation 应该是 on 状态。这里说明了原因。
上面这些就是不加任何的参数获取到的基本的设置。


1. receive(RX) ring buffer size:
# ethtool -g eth2
这个 gist 列举了几个主流设备的 rx 值,包括 BCM5720, I350 在内,当然还有 82599EB。

buffer 越小 latency 也越低,与之带来的是 throughput 的下降,也就是说,buffer 小带来的是丢包而大了带来的则是 latency。丢包的问题,一个是在 nic 层面丢了,也就是 ifconfig 看到的,一个则是在 tcp 协议栈看到的丢包。前者产生丢包很有可能就是 ring buffer 设置的太小的缘故。但是,并不是越大越好,尤其对于实时的流媒体流量来说。

可以适当的增加 ring buffer:
# ethtool -G eth0 rx 1020

一般来说,在 latency 本来就比较小的情况下,适当的增大 buffer 并不会带来明显的影响,除非是一些对 latency 极度敏感的交易场所、流媒体等。因此,这又是一个 throughput 跟 latency 的 tradeoff。 对于 rx, tx 的设置,并没有一个通用的公式,还是需要在实际环境中测试。
注意: -g 看到的只是 buffers 的数量,而非 size。


2. coalescing
interrupt coalescing 主要是用来做 latency 跟 cpu overhead 之间的 trade-off。当 adapter 收到一个 frame 之后,不会立即的对系统产生中断,而是等一段时间,收集到更多的包之后再一次性的处理,这会降低 cpu 的负载,但是会产生 latency。要查看当前的 coalescing,可以:
# ethtool  -c eth2 | grep "rx-usecs:"
rx-usecs: 1

interrupt coalescence 也叫 interrupt Moderation, Interrupt Blanking, or Interrupt Throttling。这个在 ixgbe 的参数列表里面也可以看到:
parm:           InterruptThrottleRate:Maximum interrupts per second, per vector, (0,1,956-488281), default 1 (array of int)


关于 rx-frames[-irq] rx-usecs[-irq] tx-frames[-irq] tx-usecs[-irq] 的解释,可以看这里。

可以使用下面这个命令来修改当前的值:
# ethtool -C eth2 rx-usecs VALUE
rx-usecs 会同时控制 tx 以及 rx 方向的 coalescing。值越低的,interrupt coalescence 越不容易发生,latency 越小,相应的,cpu 负载也会越大。如果增加了 rx-usecs,对于 bulk traffic 会比较好,但是会对 tcp 的性能造成大的损失,可以通过调大 TSO window divisor(默认为 3) 来弥补:
net.ipv4.tcp_tso_win_divisor = 30

前提需要开启 tso:
# ethtool -K eth2 tso on


下面这组 coalescing 测试关闭了 tcp win scaling, jumbo frame。在开启了 tcp win scaling 的情况下几乎看不到什么效果,如果关闭了这个特性,可以很明显的看到效果:
# sysctl net.ipv4.tcp_window_scaling = 0
# ifconfig eth2 mtu 1500

# for j in $(cat remote); do ssh [email protected] ethtool -C eth2 rx-usecs $j; sleep 20; time for i in $(cat rx-usecs); do ethtool -C eth2 rx-usecs $i; sleep 60; netperf  -H 192.168.10.2  -t TCP_STREAM -c -C -l 10 >> $j ;  done; done
横行代表 server rx-usecs 的值,从 1 到 99 变化,竖行代表 client 的值,这里仅列出几列的 server 的值,完整的可以看这里:
c\s      1      5       10     15     20        25      30      35   
1  2041.01 4077.18 4075.96 4077.64 4078.49 4078.23 4077.77 4077.55
5  4076.88 8840.97 8806.59 8570.26 6482.82 6517.91 5526.49 5658.80
10 4065.66 4953.04 8212.56 7655.45 6282.05 6270.99 5515.62 4999.63
15 4073.37 4933.31 7706.01 7030.65 6336.81 6136.97 5518.46 5028.43
20 4074.41 6919.17 6797.47 6601.73 6026.18 5814.38 5529.56 5025.87
25 3979.94 4850.50 6356.66 5837.68 5938.91 5455.21 5445.15 5145.08
30 4074.61 4782.81 5620.04 5523.55 5691.91 5536.58 5438.79 4973.76
35 4074.41 4735.46 6397.14 5435.40 5749.65 5370.08 4969.28 4878.18
40 4074.48 4145.26 5970.30 5824.36 5831.48 5558.44 4649.09 4897.97
45 3627.53 3788.03 5380.55 5589.18 5643.71 5611.31 5374.13 5079.22
50 3676.16 4778.47 4978.26 4992.63 4982.98 4974.82 4968.44 4961.27
55 4060.51 4608.55 4608.00 4678.30 4812.71 4610.97 4606.00 4606.49
60 4068.55 4145.90 4146.48 4666.78 4621.57 4154.13 4148.21 4148.93
65 3196.90 3887.22 3890.80 4271.96 4624.30 3911.47 3891.01 3898.07
70 2878.17 3565.00 3716.94 4315.24 4666.79 4541.56 3655.19 3556.43
75 2749.26 3362.23 3753.65 4650.59 5003.18 4475.72 3899.56 3377.73
80 2812.24 3127.96 3990.63 5196.36 5130.97 4713.21 4208.55 3751.47
85 2664.55 3049.08 4190.36 4871.45 5059.99 4746.92 4125.30 4029.49
90 2722.91 3130.98 4371.66 5446.47 5345.96 4901.87 4504.94 3866.35
95 2667.74 3551.08 5040.66 5195.68 5220.28 4991.77 4624.82 4356.83
99 2588.83 3736.98 4776.17 5061.36 5064.94 4829.90 4880.19 4471.49

默认情况下,rh6.2 的大部分机器的值为 20,少部分的为 3,这个差距可以先放一边,上面的测试可以看到:
* 在没有开启 tcp win scaling, jumbo frame(hd support) 的情况下,效果提升的比较明显,最大的能打到接近 9G(c=5, s=5);当 s 的 rx-usecs 的值达到 100 之后(到 20 就比较明显了),不管 c 调成什么样的值,效果都很差,吞吐基本是在 1G 以下
* 如果同时开启了上面两项,再修改 cs 的值,几乎没有变化,维持在 9.9G 左右,测试没有贴在这里


3. offload
也就是原先由 CPU 完成事被 NIC offload 了。一般用来做 offload 的包括 segmentation 和 checksum。
这篇文档非常详细的说明了 GRO 开启关闭的情况下 TCP/IP 包的结构问题。
假设需要发送一个 7300Bytes 的包,如果在没有开启 GRO,MTU 为 1500 的情况下,减掉 20 Byte 的  IP header 以及 20 Byte TCP header,TCP segment(MSS) 还剩 1460 Byte。因此,7300 的话需要分为 5 个包,并且这 5 个包是从 application layer 到 TCP layer 的过程中就开始切割分装,依次加上 TCP header,IP header 直到最后的 Ethernet frames 发送出去,因此对于 tcpdump 来说是可以抓取到这 5 个包的;但是如果采用了 GRO,由于 7300 被当成一个整数据,依次向下加上 header,而这两个 header 其实一个  template headers,当 driver 生成完这个单一的 Ethernet frame 之后就会发给 NIC,而 tcpdump 最多也只能到 Ethernet frame 这一层,因此接下去由 NIC 负责分割成 5 个包,根据那个 template 为 5 个包分别加上 header 最后发出去。

至于 GRO, TSO 等并不是开启就好,需要根据不同的产品型号结合上面的 app 来判定,比如 Chelsio 的网卡在开启 TSO, TOE 的情况下,WAN 的性能会急剧下降,而在 LAN 里面则不存在此类情况。包括之前 RH6.2 的机器运行 LVS,在开启 GRO 的情况下,同样会出现比较严重的问题。

至于,rx/tx 的 checksum,目前主流的系统都是开启,只有好处没有坏处。


4. nic statics
主要用来做诊断之用,如果网络情况不是很好,可以通过 -S 看看目前的 Diagnostics 包括丢包的情况等等:
# ethtool -S eth2

根据之前的经验总结,一般情况下,如果看到了不少 rx_no_buffer_count,则表明需要增加 ring buffer;而如果看到 tx_deferred_ok 表示传输被延迟,不算 errors; rx_missed_errors, rx_fw_discards 这个表示包满了,多出的全被 drop 掉了。

最后,注意,ethtool 只能针对物理端口有效,至于 bond0, tun0 等接口则是无效的。

你可能感兴趣的:(网络,Wireshark,网卡驱动及测试相关)