基于RoCE的应用程序的MTU注意事项

探测网络中的MTU设置

概要

原文

MTU测试结果

DOC:

CentOS安装tshark抓包工具

基于RoCE的应用程序的MTU注意事项
原文：https://support.mellanox.com/s/article/MLNX2-117-1682kn

InfiniBand协议最大传输单元（MTU）定义了几个固定大小的MTU：256、512、1024、2048或4096字节。

使用在以太网上运行的RDMA的基于RoCE的应用程序应考虑到RoCE MTU小于以太网MTU（Ethernet MTU）。（通常默认值为1500）。

驱动程序从上面的列表中选择比Ethernet MTU 小的最大的那个值作为最大的“active” MTU。（并考虑了RoCE传输头和CRC字段）。

例如：

对于默认的 Ethernet MTU （1500字节），RoCE将使用1024（作为active_mtu）

而对于Ethernet MTU = 4200，RoCE将使用4096作为“active MTU”。

可以使用“ ibv_devinfo”检查“ active_mtu”值。

通信两端之间用RoCE协议交换“ active_mtu”并进行协商。将使用最小的MTU。

（RoCE protocol exchanges "active_mtu" values and negotiates it between both ends. The minimum MTU will be used.）

检查端口MTU：

[root@rdma59 ~]# ifconfig ens2f0

ens2f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 172.17.31.59 netmask 255.255.255.0 broadcast 172.17.31.255

inet6 fe80::b696:91ff:fea5:9a70 prefixlen 64 scopeid 0x20<link>

ether b4:96:91:a5:9a:70 txqueuelen 1000 (Ethernet)

RX packets 6508 bytes 954004 (931.6 KiB)

RX errors 0 dropped 477 overruns 0 frame 0

TX packets 4736 bytes 361557 (353.0 KiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

检查InfiniBand MTU：

ibv_devinfo 显示所有RDMA网口的简略信息

ibv_devinfo -v显示所有RDMA网口的所有信息

ibv_devinfo -d mlx5_0显示所有mlx5_0的简略信息

ibv_devinfo -v -d mlx5_0显示所有mlx5_0的所有信息

更多：ibv_devinfo –h

[root@rdma63 ~]# ibv_devinfo -d mlx5_0

hca_id: mlx5_0

transport: InfiniBand (0)

fw_ver: 16.29.1016

node_guid: 9803:9b03:009a:2b3a

sys_image_guid: 9803:9b03:009a:2b3a

vendor_id: 0x02c9

vendor_part_id: 4119

hw_ver: 0x0

board_id: MT_0000000010

phys_port_cnt: 1

Device ports:

port: 1

state: PORT_ACTIVE (4)

max_mtu: 4096 (5)

active_mtu: 1024 (3)

sm_lid: 0

port_lid: 0

port_lmc: 0x00

link_layer: Ethernet

对于使用大IO的应用程序，建议扩大MTU。

注意：如果您更改端口MTU，则所有链路上的网络元素（交换机和路由器）中的MTU也应该一同修改。

一旦你修改了端口（port）的MTU后，InfiniBand的 active MTU将自动调整为适合该MTU的最大尺寸。

例如，一旦将端口MTU设置为4200，active_mtu将更改为4096。

但是，最好不要将端口MTU配置为9000，因为这会浪费内存。

建议的MTU值如下：

想让active MTU为4096-将端口MTU配置为4200

想让active MTU为2048-将端口MTU配置为2200

# ifconfig eth2 mtu 4200
# ibv_devinfo -d mlx4_0
hca_id: mlx4_0
transport: InfiniBand (0)
fw_ver: 2.31.5050
node_guid: f452:1403:0017:1b80
sys_image_guid: f452:1403:0017:1b83
vendor_id: 0x02c9
vendor_part_id: 4103
hw_ver: 0x0
board_id: MT_1090111019
phys_port_cnt: 2
port: 1
state: PORT_ACTIVE (4)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: Ethernet

port: 2
state: PORT_DOWN (1)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: InfiniBand

其他文章：

IP over Infiband MTU size in non homogeneous environments - IBM InfiniBand

https://www.ibm.com/support/pages/ip-over-infiband-mtu-size-non-homogeneous-environments-ibm-infiniband

Maximum Transmit Unit (MTU) Configuration

https://www.supermicro.org.cn/wdl/driver/InfiniBand/VMWare/ESX_Server_5.X/Mellanox_IB_OFED_Driver_for_VMware_vSphere_User_Manual_Rev_1_8_0.pdf

探测网络中的MTU设置
概要
1、MTU(Maximum Transmission Unit) 大小指的是一个以太帧(Ethernet Frame)能携带的最大数据部分(payload)的大小, 当MTU值设置为9000 Bytes的时候也叫做巨型帧(Jumbo Frame)

2、一般情况下网卡的MTU大小是1500(最大可配置到9000)，（增加）数据的传输效率，可以通过增加MTU只来实现，MTU的增加即每帧(Frame)传输的数据量就会更大。

3、网络中的所有节点必须同时增大MTU，网络中小MTU的节点遇到上家发来的大于MTU的Frame（且没有切分标记），则直接丢弃。

PMTUD方法：

tracepath -n 192.169.31.54

https://networkengineering.stackexchange.com/questions/13417/exactly-when-is-pmtud-performed-path-mtu-discovery

原文
原文：https://www.jianshu.com/p/ee9c32b18005

MTU(Maximum Transmission Unit) 大小指的是一个以太帧(Ethernet Frame)能携带的最大数据部分(payload)的大小, 当MTU值设置为9000 Bytes的时候也叫做巨型帧(Jumbo Frame):

以太帧(Ethernet Frame)
802.3 Ethernet MTU

一般情况下网卡的MTU大小是1500(最大可配置到9000)，然后为了在高性能的网络环境下（增加）数据的传输效率，可以通过增加MTU只来实现，换句话说通过MTU的增加，每帧(Frame)传输的数据量就会更大。这就好比用面包车运输对比用大货车运输的区别。

然而要实现大MTU需要网络里的每个设备都必须支持巨型帧大MTU，包括发送主机，目标主机以及网络中的路由器等。

本文主要是记录如何探测网络中的MTU设置以及错误配置MTU带来的影响。

为了探测两个不同实验室的机器之间的网络是否支持Jumbo Frame, 我从实验室A的Centos主机(client) 发送ping命令到实验室B的服务器(server)。

首先检查client的MTU配置:

[root@centos ~]# ifconfig eno16777736
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

可以看到默认的MTU值为1500，此时我们发送一个大小为100B的ICMP数据包到目标server.

[root@centos ~]# ping -s 100 -c 1 10.245.194.61
PING 10.245.194.61 (10.245.194.61) 100(128) bytes of data.
108 bytes from 10.245.194.61: icmp_seq=1 ttl=50 time=23.0 ms
可以看到小于MTU的数据包(128 = 100 + 20(ip header) + 8(icmp header))成功地发出并得到服务器回应，接着我们增大包的大小到2000，超过了1500的MTU值, 同样数据ping成功ping发送并得到回应:

[root@centos ~]# ping -s 2000 -c 1 10.245.194.61
PING 10.245.194.61 (10.245.194.61) 2000(2028) bytes of data.
2008 bytes from 10.245.194.61: icmp_seq=1 ttl=50 time=24.2 ms

wireshark抓包

或许这里会有疑问，不是说最大只能发送1500字节的包吗？为何2000字节也能成功发出？为了解答这个问题，我们通过wireshark抓个包来看看怎么回事

[root@centos ~]# tcpdump -i eno16777736 -s 50 -w mtu_1500.pcap
[root@centos ~]# tshark -t ud -P -O icmp,ip -Y "ip.addr==10.245.194.61" -r mtu_1500.pcap000>>mtu_1500.txt
(参数解释：

https://www.cnblogs.com/liun1994/p/6142505.html
-t: -t a|ad|d|dd|e|r|u|ud 设置解码结果的时间格式。“ad”表示带日期的绝对时间，“a”表示不带日期的绝对时间，“r”表示从第一个包到现在的相对时间，“d”表示两个相邻包之间的增量时间（delta）。　　-u: s|hms 格式化输出秒；
-P: 即使将解码结果写入文件中，也打印包的概要信息；
-O: -O <protocols>,只显示此选项指定的协议的详细信息。
-Y: -Y <display filter>,使用读取过滤器的语法，在单次分析中可以代替-R选项;
-r: -r <infile> 设置读取本地文件
)

打开mtu_1500.txt，找到ICMP包:

icmp 帧

可以看到，即使我们指定的数据包大小是2000字节，但是IP层会根据当前MTU的设置对超过的ICMP数据进行分片(Fragmentation)，以满足发送方的MTU设置要求。那么接收方是如何判定当前IP包是否被分片过？可以通过More Fragments 标志位(上图93行)和Flags字段(上图第90行)的值来判断，, 当接收方的IP层收到最后一个切片后(More Fragments: Not set)，就会组装收到的所有切片包然后交给上层协议, 这里我们停下来想一想，IP层如何保证切片重组的顺序？其实很简单，IP包里有个Fragment offset属性，接收方可根据此属性的顺序重组切片，此列中，理论上应当只有两个切片(1500 + 500 =2000), 所以接下来的一个Frame就是最后一个IP 切片:

第二个Fragment

上图第二个切片也是最后一个，其IP包的大小为548字节，也就是着总的数据传输量为2048(1500+548)字节，其中1个icmp头(8B), 2个ip头(20B+20B)和icmp的数据部分(2000). 所以可以看到，即便发送数据量超过了MTU的值，在IP层也会进行切片来适配所设置的MTU大小。

那么将发送发的MTU设置为9000字节启用巨型帧的话，会出现什么结果呢？

[root@centos ~]# ifconfig eno16777736 mtu 9000 up
[root@centos ~]# ifconfig eno16777736
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
设置好巨型帧以后，再来ping一个大数据包看看这次结果有什么不一样。

[root@centos ~]# ping -s 2000 -c 1 10.245.194.61
PING 10.245.194.61 (10.245.194.61) 2000(2028) bytes of data.

--- 10.245.194.61 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
额。。。增大了MTU之后，反而ping不成功！这是怎么回事？？？在看看网络包:

ping with jumbo frame

嗯，没问题，MTU设置应该是成功的，这次IP层没有分片，发送的数据也是2000字节，但是为什么服务器没有回应呢？

其实，这恰恰说明了此网络是不支持巨型帧的，只要网络里有一个转发节点的MTU值不是9000B并且发送方要求不分片(第170行, DF: Set)的情况下，转发节点会丢弃该报文。这也就是为什么会返回超时丢包的错误了。

简单来说，当一个转发点收到一个IP报文以后，先检查该报文的大小是否超过自己的MTU值，如果超过，再检查是否设置了DF标志(Don't Fragment), 如果设置，此报文将会被直接丢弃，如果没有设置DF，那么该节点会对报文进行切片后再转发到下一个路由节点。

作者：hynoor
链接：https://www.jianshu.com/p/ee9c32b18005

MTU测试结果
谷歌搜索 MTU Test / Great Jumbo Frames /图片搜索

《The Great Jumbo Frames Debate》https://longwhiteclouds.com/2013/09/10/the-great-jumbo-frames-debate/

《Jumbo Frames on vSphere 5》https://longwhiteclouds.com/2012/02/20/jumbo-frames-on-vsphere-5/

《Hardware Offloads - Test results》https://docs.openstack.org/performance-docs/latest/test_results/hardware_features/hardware_offloads/test_results.html

《Large MTUs and Internet Performance》http://irep.ntu.ac.uk/id/eprint/13183/1/221075_PubSub2797_Lee_K.pdf

《AWS Performance Test Results》https://docs.aviatrix.com/HowTos/insane_mode_perf.html

《Jumbo Frames for RAC Interconnect》https://blogs.oracle.com/exadata/jumbo-frames-for-rac-interconnect-v2

谷歌搜索 “mtu latency”，图片

DOC:
基于RoCE的应用程序的MTU注意事项

InfiniBand自动选择的MTU与端口MTU有关

InfiniBand协议最大传输单元（MTU）定义了几个固定大小的MTU：256、512、1024、2048或4096字节。

基于RoCE的应用程序应考虑到RoCE MTU小于以太网MTU（Ethernet MTU）。（通常默认值为1500）。

驱动程序从上面的列表中选择比Ethernet MTU 小的最大的那个值作为active_mtu（即实际使用的MTU）。（并考虑了RoCE传输头和CRC字段）。

例如：

对于默认的 Ethernet MTU （1500字节），RoCE将使用1024（作为active_mtu）

而对于Ethernet MTU = 4200，RoCE将使用4096作为active_mtu。

通信两端之间用RoCE协议交换“ active_mtu”并进行协商，将使用最小的MTU。

（Mellanox ：RoCE protocol exchanges "active_mtu" values and negotiates it between both ends. The minimum MTU will be used.）

（IBM:When an SMC-R link is initially established between two peer hosts, the MTU size is exchanged and negotiated to the lowest value for both hosts. The negotiated MTU size must account for transport headers and cyclic redundancy check (CRC) information that is used by the underlying RoCE protocols.）

查看端口MTU和InfiniBand MTU
检查端口MTU：

检查端口MTU：

netstat -i

也可以：

基于RoCE的应用程序的MTU注意事项

InfiniBand自动选择的MTU与端口MTU有关

InfiniBand协议最大传输单元（MTU）定义了几个固定大小的MTU：256、512、1024、2048或4096字节。

基于RoCE的应用程序应考虑到RoCE MTU小于以太网MTU（Ethernet MTU）。（通常默认值为1500）。

驱动程序从上面的列表中选择比Ethernet MTU 小的最大的那个值作为active_mtu（即实际使用的MTU）。（并考虑了RoCE传输头和CRC字段）。

例如：

对于默认的 Ethernet MTU （1500字节），RoCE将使用1024（作为active_mtu）

而对于Ethernet MTU = 4200，RoCE将使用4096作为active_mtu。

通信两端之间用RoCE协议交换“ active_mtu”并进行协商，将使用最小的MTU。

（Mellanox ：RoCE protocol exchanges "active_mtu" values and negotiates it between both ends. The minimum MTU will be used.）

查看端口MTU和InfiniBand MTU
检查端口MTU：

检查端口MTU：

netstat -i

也可以：

[root@rdma59 ~]# ifconfig ens2f0

ens2f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 172.17.31.59 netmask 255.255.255.0 broadcast 172.17.31.255

inet6 fe80::b696:91ff:fea5:9a70 prefixlen 64 scopeid 0x20<link>

ether b4:96:91:a5:9a:70 txqueuelen 1000 (Ethernet)

RX packets 6508 bytes 954004 (931.6 KiB)

RX errors 0 dropped 477 overruns 0 frame 0

TX packets 4736 bytes 361557 (353.0 KiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

检查InfiniBand MTU
可以使用“ ibv_devinfo”检查“ active_mtu”值。

ibv_devinfo 显示所有RDMA网口的简略信息

ibv_devinfo -v显示所有RDMA网口的所有信息

ibv_devinfo -d mlx5_0显示网口mlx5_0的简略信息

ibv_devinfo -v -d mlx5_0显示网口mlx5_0的所有信息

更多：ibv_devinfo –h

[root@rdma63 ~]# ibv_devinfo -d mlx5_0

hca_id: mlx5_0

transport: InfiniBand (0)

fw_ver: 16.29.1016

node_guid: 9803:9b03:009a:2b3a

sys_image_guid: 9803:9b03:009a:2b3a

vendor_id: 0x02c9

vendor_part_id: 4119

hw_ver: 0x0

board_id: MT_0000000010

phys_port_cnt: 1

Device ports:

port: 1

state: PORT_ACTIVE (4)

max_mtu: 4096 (5)

active_mtu: 1024 (3)

sm_lid: 0

port_lid: 0

port_lmc: 0x00

link_layer: Ethernet

max_mtu: infiniband网口支持的最大MTU

active_mtu: infiniband网口实际使用的MTU

MTU设置建议和注意事项
MTU设置建议
对于使用大IO的应用程序，建议扩大MTU。

注意事项
注意：如果您更改端口MTU，则所有链路上的网络元素（交换机和路由器）中的MTU也应该一同修改，否则大MTU端口发出的大帧遇到小MTU端口会发生数据丢弃，且没有反馈，问题难以排查。

（MTU：最大传输单元，最大接收单元MRU，即MTU >MRU时，接收方就丢弃数据）

一旦你修改了端口（port）的MTU后，InfiniBand的 active MTU将自动调整为适合该MTU的最大尺寸。

例如，一旦将端口MTU设置为4200，active_mtu将更改为4096。

但是，最好不要将端口MTU配置为9000，因为这会浪费内存。

建议的MTU值如下：

想让active MTU为4096-将端口MTU配置为4200

想让active MTU为2048-将端口MTU配置为2200

port: 2
state: PORT_DOWN (1)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: InfiniBand

确定路径的MTU
原理
用来确定到达目的地的路径的最大传输单元(MTU)的大小的策略/技术叫PMTUD（路径MTU发现）

[路径MTU发现] （PMTUD）通过在IP报头中设置不分片DF(Don't Fragment)标志来探测路径中的MTU值。一旦DF位置1，将不允许中间设备对该报文进行分片，那么在遇到IP报文长度超过中间设备转发接口的MTU值时，该IP报文将会被中间设备丢弃。在丢弃之后，中间设备会向发送方发送ICMP差错报文。

（注意:如果通信路径中间有防火墙阻止了ICMP错误消息，那么会阻止PMTUD正常执行。）

http://www.vants.org/?post=109

检测

（ping的参数解释，可以执行 man ping 查看）

在Windows主机上，还可以使用“-f” ping参数将“不分段（DF）”位设置为1。

C:\ Users \ ScottHogg> ping 192.168.10.1 -l 1500 -f

在Linux上，命令为：

RedHat# ping -s 1500 -M do 192.168.10.1

通过改变ping包的大小，来回逼近的方法确定MTU

环境测试实践结果
intel集群的172.17.31.55、172.17.31.59

在intel集群的172.17.31.55、172.17.31.59上测试：

只要两个网口的MTU不一致,使用ping测试传输大于一端MTU的数据包就会失败。

例如：

172.17.31.55 设置eth的MTU为4200（ib的MTU自动为4096）：

ifconfig ens2f0 mtu 4200

172.17.31.59 的eth的MTU默认1500

在172.17.31.55上向172.17.31.59 ping 200 byte的包会成功，ping 2000 byte的包会失败：

ping -s 200 -c 1 172.17.31.59 #成功

ping -s 2000 -c 1 172.17.31.59 #失败

反过来也一样。

172.17.31.55 、172.17.31.59都设置eth的MTU为4200（ib的MTU自动为4096）：

ping -s 2000 -c 1 172.17.31.59 #成功

windows检查MTU size

ping -f -l 2000 182.200.31.59

-l size 发送缓冲区大小。

-f 在数据包中设置“不分段”标志(仅适用于 IPv4)

返回中提示需要拆分，说明MTU 小于2000

PS C:\Users\l24514> ping 182.200.31.59 -l 1500 -f

正在 Ping 182.200.31.59 具有 1500 字节的数据:
来自 182.200.31.254 的回复: 需要拆分数据包但是设置 DF。
来自 182.200.31.254 的回复: 需要拆分数据包但是设置 DF。
来自 182.200.31.254 的回复: 需要拆分数据包但是设置 DF。
来自 182.200.31.254 的回复: 需要拆分数据包但是设置 DF。

设置方法
设置：

# ifconfig eth2 mtu 4200

查看：

# ibv_devinfo -d mlx4_0

（eth2网口对应的 device是mlx4_0）

为什么以太网mtu默认值为1500?
https://www.zhihu.com/question/21524257/answer/118266374

理想状态帧越大传输效率越高。（MTU越大允许的帧越大）
MTU过大引起的副作用：
传送一个数据包的延迟也越大

对于上行链路，会有多个计算机的数据帧排队等待传输，如果某个数据帧太大的话，那么其他数据帧等待的时间就会加长，导致体验变差。

需要更大的缓存区（内存）
网络I/O控制器需要从Host端主存中的缓冲区中取数据，缓冲区的大小是有限制的，Host主存资源有限，一般无法分配太大的缓冲区，只能将数据碎片化，一小份一小份的放置，并用环形队列追踪组织起来。

并且MTU越大，数据包中 bit位发生错误的概率也越大

如果一次传送太大量的数据，一旦该数据中有一小部分被干扰，那么接收方的数据校验算法由于无法判断具体是哪里产生了错误以及如何修复错误，所以只能将这份数据全部丢弃，并通知发送方重传，这极度浪费了网络带宽资源

所以折衷的长度：1518 byte ! 对应的IP packet 就是 1500 byte：

https://www.zhihu.com/question/21524257/answer/118266374

其他相关内容
Path MTU Discovery (PMTUD)
PMTUD：

路径MTU发现(PMTUD)，用于确定计算机网络中使用互联网协议(IP)主机间的最大传输单元(MTU)的大小，通常目标是避免IP分片。PMTUD原定应用在IPv4的路由器上，然而所有现代操作系统都是在终端应用它。在IPv6中，这个方法只应用在终端之间的会话。对于IPv4包，路径MTU发现通过在传出包的IP头中设置Don't Fragment (DF)标志位来工作。然后，任何路径上MTU小于数据包的设备都将丢弃它，并返回包含其MTU过大的ICMPv4(类型3、代码4)数据包，从而允许源主机适当地减小其路径MTU。 [1]

探测网络中的MTU设置实践

《探测网络中的MTU设置》: https://www.jianshu.com/p/ee9c32b18005

概要:

1、MTU(Maximum Transmission Unit) 大小指的是一个以太帧(Ethernet Frame)能携带的最大数据部分(payload)的大小, 当MTU值设置为9000 Bytes的时候也叫做巨型帧(Jumbo Frame)

3、网络中的所有节点必须同时增大MTU，网络中小MTU的节点遇到上家发来的大于MTU的Frame（且没有切分标记），则直接丢弃。

MTU Size Issues
https://www.networkworld.com/article/2224654/mtu-size-issues.html

RDMA 信息常用命令
查看RDMA device列表

[root@rdma63 tcpdump]# ibv_devices

device node GUID

------ ----------------

mlx5_1 98039b03009a4296

mlx5_0 98039b03009a2b3a

查看device信息

[root@rdma63 tcpdump]# ibv_devinfo -v -d mlx5_1

hca_id: mlx5_1

transport: InfiniBand (0)

fw_ver: 16.29.1016

node_guid: 9803:9b03:009a:4296

sys_image_guid: 9803:9b03:009a:4296

vendor_id: 0x02c9

vendor_part_id: 4119

hw_ver: 0x0

board_id: MT_0000000010

phys_port_cnt: 1

Device ports:

port: 1

state: PORT_ACTIVE (4)

max_mtu: 4096 (5)

active_mtu: 1024 (3)

sm_lid: 0

port_lid: 0

port_lmc: 0x00

link_layer: Ethernet

[root@rdma63 ~]# ibv_devinfo --help

ibv_devinfo: unrecognized option '--help'

Usage: ibv_devinfo print the ca attributes

Options:

-d, --ib-dev=<dev> use IB device <dev> (default all devices found)

-i, --ib-port=<port> use port <port> of IB device (default 0: all ports)

-l, --list print only the IB devices names

-v, --verbose print all the attributes of the IB device(s)

查看网口映射关系

mellonx：

[root@rdma64 ibdump-master]# ibdev2netdev

mlx5_0 port 1 ==> eth18-0 (Up)

mlx5_1 port 1 ==> ib3b-0 (Up)

intel：

ibv_devices|awk '{system("echo "$1"\"-->\"`ls /sys/class/infiniband/"$1"/device/net`")}'

检查InfiniBand MTU
可以使用“ ibv_devinfo”检查“ active_mtu”值。

ibv_devinfo 显示所有RDMA网口的简略信息

ibv_devinfo -v显示所有RDMA网口的所有信息

ibv_devinfo -d mlx5_0显示网口mlx5_0的简略信息

ibv_devinfo -v -d mlx5_0显示网口mlx5_0的所有信息

更多：ibv_devinfo –h

[root@rdma63 ~]# ibv_devinfo -d mlx5_0

hca_id: mlx5_0

transport: InfiniBand (0)

fw_ver: 16.29.1016

node_guid: 9803:9b03:009a:2b3a

sys_image_guid: 9803:9b03:009a:2b3a

vendor_id: 0x02c9

vendor_part_id: 4119

hw_ver: 0x0

board_id: MT_0000000010

phys_port_cnt: 1

Device ports:

port: 1

state: PORT_ACTIVE (4)

max_mtu: 4096 (5)

active_mtu: 1024 (3)

sm_lid: 0

port_lid: 0

port_lmc: 0x00

link_layer: Ethernet

max_mtu: infiniband网口支持的最大MTU

active_mtu: infiniband网口实际使用的MTU

MTU设置建议和注意事项

对于使用大IO的应用程序，建议扩大MTU。

注意：如果您更改端口MTU，则所有链路上的网络元素（交换机和路由器）中的MTU也应该一同修改，否则大MTU端口发出的大帧遇到小MTU端口会发生数据丢弃，且没有反馈，问题难以排查。

（MTU：最大传输单元，最大接收单元MRU，即MTU >MRU时，接收方就丢弃数据）

一旦你修改了端口（port）的MTU后，InfiniBand的 active MTU将自动调整为适合该MTU的最大尺寸。

例如，一旦将端口MTU设置为4200，active_mtu将更改为4096。

但是，最好不要将端口MTU配置为9000，因为这会浪费内存。

建议的MTU值如下：

想让active MTU为4096-将端口MTU配置为4200

想让active MTU为2048-将端口MTU配置为2200

port: 2
state: PORT_DOWN (1)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
link_layer: InfiniBand

为什么以太网mtu默认值为1500?
https://www.zhihu.com/question/21524257/answer/118266374

理想状态帧越大传输效率越高。（MTU越大允许的帧越大）
MTU过大引起的副作用：
传送一个数据包的延迟也越大

对于上行链路，会有多个计算机的数据帧排队等待传输，如果某个数据帧太大的话，那么其他数据帧等待的时间就会加长，导致体验变差。

并且MTU越大，数据包中 bit位发生错误的概率也越大

所以折衷的长度：1518 byte ! 对应的IP packet 就是 1500 byte：

https://www.zhihu.com/question/21524257/answer/118266374

其他相关内容
Path MTU Discovery (PMTUD)
PMTUD：

探测网络中的MTU设置实践

《探测网络中的MTU设置》: https://www.jianshu.com/p/ee9c32b18005

概要:

1、MTU(Maximum Transmission Unit) 大小指的是一个以太帧(Ethernet Frame)能携带的最大数据部分(payload)的大小, 当MTU值设置为9000 Bytes的时候也叫做巨型帧(Jumbo Frame)

3、网络中的所有节点必须同时增大MTU，网络中小MTU的节点遇到上家发来的大于MTU的Frame（且没有切分标记），则直接丢弃。

MTU Size Issues
https://www.networkworld.com/article/2224654/mtu-size-issues.html

CentOS安装tshark抓包工具

准备在服务器上用tshark抓包，分析一下数据。直接yum install tshark却发现没有这个包。网上搜索一下，各种奇葩安装方式，又是安装apt？又是安装各种环境？我相信既然CentOS已经有了yum这么好的包管理工具，那么一定有更简单的方式。
最后只好在Google上直接用我这蹩脚的英文搜索一下。果然，一句how to install tshark on centos顺利解决了我的问题。
原来一直是自己对yum这个命令了解太少了，平时只会yum install,yum update :first_quarter_moon_with_face: 。那么到底故事如何，客官且听我细细道来。
当我试图直接安装时：

$ yum install tshark
已加载插件：fastestmirror
Loading mirror speeds from cached hostfile
没有可用软件包 tshark。
错误：无须任何处理
那么，该怎么办呢？原来yum提供了搜索功能。

$ yum whatprovides *tshark*
已加载插件：fastestmirror
Loading mirror speeds from cached hostfile
base/7/x86_64/filelists_db | 6.9 MB 00:00:00
epel/x86_64/filelists | 10 MB 00:00:00
extras/7/x86_64/filelists_db | 524 kB 00:00:00
updates/7/x86_64/filelists_db | 2.1 MB 00:00:00
1:bash-completion-extras-2.1-11.el7.noarch : Additional programmable completions for Bash
源：epel
匹配来源：
文件名：/usr/share/bash-completion/completions/tshark

wireshark-1.10.14-14.el7.i686 : Network traffic analyzer
源：base
匹配来源：
文件名：/usr/sbin/tshark
文件名：/usr/share/wireshark/tshark.html
文件名：/usr/share/man/man1/tshark.1.gz

wireshark-1.10.14-14.el7.x86_64 : Network traffic analyzer
源：base
匹配来源：
文件名：/usr/sbin/tshark
文件名：/usr/share/wireshark/tshark.html
文件名：/usr/share/man/man1/tshark.1.gz

我们可以看到wireshark包已经包含了tshark包。

接下来就是我们熟悉的步骤了==。

$ yum install wireshark
已加载插件：fastestmirror
Loading mirror speeds from cached hostfile
正在解决依赖关系
--> 正在检查事务
---> 软件包 wireshark.x86_64.0.1.10.14-14.el7 将被安装
--> 正在处理依赖关系 libsmi.so.2()(64bit)，它被软件包 wireshark-1.10.14-14.el7.x86_64 需要
--> 正在处理依赖关系 libcares.so.2()(64bit)，它被软件包 wireshark-1.10.14-14.el7.x86_64 需要
--> 正在检查事务
---> 软件包 c-ares.x86_64.0.1.10.0-3.el7 将被安装
---> 软件包 libsmi.x86_64.0.0.4.8-13.el7 将被安装
--> 解决依赖关系完成

...

已安装:
wireshark.x86_64 0:1.10.14-14.el7

作为依赖被安装:
c-ares.x86_64 0:1.10.0-3.el7 libsmi.x86_64 0:0.4.8-13.el7

完毕！