Mikrotik CCR2004-1G-2XS-PCIe 简单带宽测试

发布日期:分类:Linux & homelab Mikrotik CCR2004-1G-2XS-PCIe 简单带宽测试有 1 条评论

CCR2004-1G-2XS-PCIe是一个有趣的设备,准确的讲它是一个“PCIe网卡形式的路由器”,与普通路由器不同的是,它除了挡板上的两个SFP28 25G网口和一个RJ45千兆管理口这些“物理网口”,其还通过PCIe 3.0 x8有着4个直连主机的25G虚拟网络接口,在主机看来,这相当于4个固定直连到路由器上的“普通”网络接口;而与一些Smart NIC不同的是,CCR2004-1G-2XS-PCIe并不能为主机提供任何offload功能,RDMA和sr-iov等功能应该也是不支持的,它也没有内置交换机芯片,所有从主机到物理网口的数据都需要CCR2004-1G-2XS-PCIe的CPU来转发,换句话说,如果你只是把它当网卡用,那它还不如普通网卡,它的合理用途应当是组成一个服务器和路由器的All-in-one方案。不过无论是作为“集成路由器”还是“普通网卡”的用途都值得我们实践测试一下,这便是这篇文章接下来的部分。

由于没有25G环境,本文在10G内网下测试,CCR2004-1G-2XS-PCIe通过SFP+ DAC连接至CRS305 10G交换机上,交换机上的另一台机器使用x540双万兆电口网卡。CCR2004-1G-2XS-PCIe被安装在一台Core i9-10850k迷你主机(以下简称为host)的PCIe 3.0 x16槽上(CPU直连通道),系统为Fedora Workstation 36。

在host上的一些关于此设备的信息节选:

# lspci
01:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet
01:00.1 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet
01:00.2 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet
01:00.3 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet

# dmesg
[    1.971577] atl1c 0000:01:00.0: enabling device (0000 -> 0002)
[    1.994014] atl1c 0000:01:00.1: enabling device (0000 -> 0002)
[    2.014003] atl1c 0000:01:00.2: enabling device (0000 -> 0002)
[    2.034983] atl1c 0000:01:00.3: enabling device (0000 -> 0002)
[    2.057479] atl1c 0000:01:00.1 enp1s0f1: renamed from eth1
[    2.073979] atl1c 0000:01:00.0 enp1s0f0: renamed from eth0
[    2.090921] atl1c 0000:01:00.2 enp1s0f2: renamed from eth2
[    2.105991] atl1c 0000:01:00.3 enp1s0f3: renamed from eth3
[    8.700933] atl1c 0000:01:00.0: atl1c: enp1s0f0 NIC Link is Up<25000 Mbps Full Duplex>
[    8.703098] atl1c 0000:01:00.1: atl1c: enp1s0f1 NIC Link is Up<25000 Mbps Full Duplex>
[    8.705370] atl1c 0000:01:00.2: atl1c: enp1s0f2 NIC Link is Up<25000 Mbps Full Duplex>
[    8.707589] atl1c 0000:01:00.3: atl1c: enp1s0f3 NIC Link is Up<25000 Mbps Full Duplex>

# ethtool enp1s0f0
Settings for enp1s0f0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  Not reported
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 25000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
	Supports Wake-on: pg
	Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
	Link detected: yes

# ethtool -i enp1s0f0
driver: atl1c
version: 5.17.9-300.fc36.x86_64
firmware-version:
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

可以看出其在Linux下使用atl1c驱动,连接速度和功能正常,但lspci下型号识别是有问题的。

交换性能测试(“软交换机”模式)

这个模式下所有接口都在一个bridge中,在host上只启用第一个虚拟网口,一个SFP28口接入房间交换机。remote为房间交换机上的主机。测试线路的带宽上限是10G,这里使用iperf3进行测试,也就是大包测试,RouterOS的Fast Forward为默认的开启状态。

测试描述带宽CPU占用
#1单向host -> remote9.39 Gbits/sec15%
#2单向remote -> host9.41 Gbits/sec30%

表格中的CPU占用指CCR2004-1G-2XS-PCIe的,默认RouterOS是开启bridge的Fast Forward,手动关闭后的结果没有明显变化。

路由+NAT性能测试(“集成路由器”模式)

这个模式下,模拟常见的家用路由器环境,但WAN侧使用DHCP,通过一个SFP28接口接入房间交换机,从上级路由器获得地址,remote主机也在房间交换机上。其余接口在一个bridge中,为LAN侧。像普通家用路由器一样,LAN侧有自己的地址段,打开DHCP服务器,开启WAN上的NAT masquerade。

首先是开启Fast Path时的性能:

测试描述带宽CPU占用
#1单向host -> remote9.35 Gbits/sec21%
#2单向remote -> host9.37 Gbits/sec31%

然后是关闭Fast Path时的性能:

测试描述带宽CPU占用
#1单向host -> remote9.37 Gbits/sec28%
#2单向remote -> host2.80 Gbits/sec29%

可以看到在关闭Fast Path后,remote -> host,也就是WAN to LAN方向的性能不佳。虽然此时CPU占用率并未达到100%,但一共4个核心中,仅有一个核心使用率接近100%,估计是有单核瓶颈,此时的CPU占用情况如下:

作者:WuSiYu

学生,Web开发者,智能硬件&IOT爱好者

1条评论

发表评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注